Która klasa jest lepsza? [zamknięte]

Która klasa jest lepsza i dlaczego?

public class User
{
    public String UserName;
    public String Password;
    public String FirstName;
    public String LastName;
}

public class Employee : User
{
    public String EmployeeId;
    public String EmployeeCode;
    public String DepartmentId;
}

public class Member : User
{
    public String MemberId;
    public String JoinDate;
    public String ExpiryDate;
}

Lub 

public class User
{
    public String UserId;
    public String UserName;
    public String Password;
    public String FirstName;
    public String LastName;
}

public class Employee
{
    public User UserInfo;
    public String EmployeeId;
    public String EmployeeCode;
    public String DepartmentId;
}

public class Member
{
    public User UserInfo;
    public String MemberId;
    public String JoinDate;
    public String ExpiryDate;
}
Author: Sander, 2008-09-02
Source

11 answers

Na pytanie odpowiada się po prostu uznając, że modele dziedziczenia są relacją "jest-A", podczas gdy modele członkostwa są relacją "ma-A".

  • pracownik jest użytkownikiem
  • pracownik ma userinfo

Który jest poprawny? To twoja odpowiedź.

 49
Author: 1800 INFORMATION,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 04:46:20

Nie lubię żadnej z nich. Co się dzieje, gdy ktoś jest zarówno członkiem, jak i pracownikiem?

 17
Author: Brad Wilson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 04:39:28

Zadaj sobie następujące pytanie:

  • Czy chcesz modelować pracownikaCzy jest użytkownikiem? Jeśli Tak, wybierz spadek.
  • Czy chcesz modelować pracownika posiadającego informacje o użytkowniku? Jeśli Tak, użyj kompozycji.
  • czy funkcje wirtualne są zaangażowane między Użytkownikiem (info) a pracownikiem? Jeśli Tak, użyj dziedziczenia.
  • czy pracownik może mieć wiele instancji użytkownika (informacji)? Jeśli Tak, użyj kompozycji.
  • czy jest sens przypisywać obiekt pracowniczy do User (info) object? Jeśli Tak, użyj dziedziczenia.

Ogólnie rzecz biorąc, staraj się modelować rzeczywistość, którą symuluje Twój program, pod ograniczeniami złożoności kodu i wymaganej wydajności.

 15
Author: wilhelmtell,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 05:03:48

Myślę, że kompozycja nie zawsze jest lepsza od dziedziczenia (tylko zazwyczaj). Jeśli pracownik i członek naprawdę są użytkownikami i wzajemnie się wykluczają, pierwszy projekt jest lepszy. Rozważ scenariusz, w którym musisz uzyskać dostęp do nazwy użytkownika pracownika. Używając drugiego wzoru będziesz miał: 

myEmployee.UserInfo.UserName

Co jest złe (prawo Demeter), więc refakturowałbyś do: 

myEmployee.UserName

Który wymaga małej metody na pracownika do delegowania do obiektu użytkownika. Wszystko to jest unikane według pierwszego projektu.

 12
Author: liammclennan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 05:46:09

Ładne pytanie, chociaż aby uniknąć rozpraszania uwagi na right i wrong rozważyłbym pytanie o plusy i minusy każdego podejścia -- myślę, że to miałeś na myśli przez które jest lepsze lub gorsze i dlaczego. W każdym razie ....

Pierwsze podejście aka dziedziczenie

Plusy:

  • pozwala na zachowanie polimorficzne.
  • jest początkowo proste i wygodne.

Wady:

  • Może stać się skomplikowany lub niezdarny w czasie Jeśli dodaje się więcej zachowań i relacji.

Drugie podejście aka kompozycja

Plusy:

  • dobrze odwzorowuje scenariusze nie-oop, takie jak tabele relacyjne, programowanie strukturalne itp
  • jest proste (jeśli niekoniecznie wygodne), aby stopniowo rozszerzyć relacje i zachowanie.

Wady:

  • brak polimorfizmu, dlatego mniej wygodne jest używanie powiązanych informacji i zachowań

Listy jak te + wspomniane pytania Jon Limjap pomogą Ci podjąć decyzje i zacząć - wtedy znajdziesz to, co właściwe odpowiedzi powinny być; -)

 11
Author: maccullt,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:18:15

Można również myśleć o pracowniku jako o roli Użytkownika (osoby). Rola użytkownika może ulec zmianie w czasie (użytkownik może stać się bezrobotny) lub użytkownik może mieć wiele ról w tym samym czasie.

Dziedziczenie jest znacznie lepsze, gdy istnieje prawdziwa "jest" relacją, na przykład jabłko-owoc. Ale bądź bardzo ostrożny: okrąg-Elipsa nie jest rzeczywistą relacją" jest", ponieważ cirlce ma mniej "wolności" niż elipsa (okrąg jest stanem elipsy) - patrz: Elipsa Okręgu problem .

 7
Author: Marcin Raczyński,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-08-21 19:59:28

Prawdziwe pytania to:

  • Jakie są zasady biznesowe i historie użytkowników za użytkownikiem?
  • Jakie są zasady biznesowe i historie użytkowników stojące za pracownikiem?
  • Jakie są zasady biznesowe i historie użytkowników za członkiem?

Mogą to być trzy zupełnie niepowiązane ze sobą podmioty, a to zadecyduje, czy twój pierwszy czy drugi projekt zadziała, czy też inny zupełnie inny projekt jest w porządku.

 5
Author: Jon Limjap,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 05:43:14

Żaden nie jest dobry. Za bardzo zmienny stan. Nie powinieneś być w stanie zbudować instancji klasy, która jest w stanie nieprawidłowym lub częściowo zainicjalizowanym.

To powiedziawszy, drugi jest lepszy, ponieważ faworyzuje kompozycję nad dziedziczeniem.

 4
Author: Apocalisp,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 04:47:39

Określenie wymagań / specyfikacji może pomóc w uzyskaniu "najlepszego projektu".
Twoje pytanie jest w tej chwili zbyt "subject-to-reader-interpretation".

 3
Author: Gishu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 07:43:01

Oto scenariusz, o którym powinieneś pomyśleć:

Skład (drugi przykład) jest korzystniejszy, jeśli ten sam użytkownik może być zarówno pracownikiem, jak i członkiem. Dlaczego? Ponieważ w przypadku dwóch instancji (pracownika i członka), które reprezentują tego samego użytkownika, jeśli dane użytkownika ulegną zmianie, nie musisz ich aktualizować w dwóch miejscach. Tylko instancja użytkownika zawiera wszystkie informacje o użytkowniku i tylko ona musi zostać zaktualizowana. Ponieważ zarówno klasy pracownicze, jak i Członkowskie zawierają tę samą instancję Użytkownika, będą one automatycznie zawiera zaktualizowane informacje.

 2
Author: Jonathan,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-02 07:54:57

Jeszcze trzy opcje:

  1. Niech klasa User zawiera dodatkowe informacje zarówno dla pracowników, jak i członków, z nieużywanymi polami pustymi (ID konkretnego User wskazuje, czy użytkownik był pracownikiem, członkiem, jednym i drugim, czy czymkolwiek innym).

  2. Mieć User klasę, która zawiera odniesienie do ISupplementalInfo, Gdzie ISupplementalInfo jest dziedziczone przez ISupplementalEmployeeInfo, ISupplementalMemberInfo, itd. Kod, który ma zastosowanie do wszystkich użytkowników, może pracować z obiektami klasy User, a kod który miał odniesienie User może uzyskać dostęp do dodatkowych informacji użytkownika, ale takie podejście uniknie konieczności zmiany User, jeśli w przyszłości wymagane będą różne kombinacje dodatkowych informacji.

  3. Jak wyżej, ale niech klasa User zawiera jakiś zbiór ISupplementalInfo. Takie podejście miałoby tę zaletę, że ułatwiłoby dodawanie właściwości w czasie wykonywania dla użytkownika(np. dlatego, że {[13] } został zatrudniony). Przy użyciu poprzedniego podejścia, można by trzeba zdefiniować różne klasy dla różnych kombinacji właściwości; przekształcenie " członka "w" członka+klienta "wymagałoby innego kodu od przekształcenia "pracownika"w" pracownika+klienta". Wadą tego drugiego podejścia jest to, że trudniej byłoby chronić się przed zbędnymi lub niespójnymi atrybutami (użycie czegoś takiego jak {14]} do przechowywania dodatkowych informacji mogłoby działać, ale wydawałoby się trochę "nieporęczne").

Chciałbym faworyzować drugą podejście, ponieważ pozwala na przyszłą ekspansję lepiej niż bezpośrednie dziedziczenie. Praca z kolekcją obiektów, a nie pojedynczym obiektem, może być nieco uciążliwa, ale takie podejście może być lepiej niż inne, zdolne do radzenia sobie ze zmieniającymi się wymaganiami.

 0
Author: supercat,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-11-26 17:28:59