Welches Klassendesign ist besser?[geschlossen]

Question

Welches Klassendesign ist besser und warum?

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;
}

ODER

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;
}

Answer 1

Die Frage lässt sich einfach beantworten, indem man erkennt, dass Vererbung eine „IS-A“-Beziehung modelliert, während Mitgliedschaft eine „HAS-A“-Beziehung modelliert.

• Ein Mitarbeiter ist ein Benutzer
• Ein Mitarbeiter HAT EINE Benutzerinfo

Was ist richtig?Das ist Ihre Antwort.

Answer 2

Mir gefällt beides nicht.Was passiert, wenn jemand sowohl Mitglied als auch Mitarbeiter ist?

Answer 3

Stellen Sie sich Folgendes:

• Möchten Sie einen Mitarbeiter modellieren? IST Ein Benutzer?Wenn ja, wählen Sie die Vererbung.
• Möchten Sie einen Mitarbeiter modellieren? HAT a Benutzerinformationen?Wenn ja, verwenden Sie Komposition.
• Gibt es virtuelle Funktionen zwischen dem Benutzer (Info) und dem Mitarbeiter?Wenn ja, verwenden Sie die Vererbung.
• Kann ein Mitarbeiter mehrere Instanzen von „Benutzer (Info)“ haben?Wenn ja, verwenden Sie Komposition.
• Ist es sinnvoll, einem Benutzerobjekt (Infoobjekt) ein Mitarbeiterobjekt zuzuordnen?Wenn ja, verwenden Sie die Vererbung.

Versuchen Sie im Allgemeinen, die Realität, die Ihr Programm simuliert, unter den Einschränkungen der Codekomplexität und der erforderlichen Effizienz zu modellieren.

Answer 4

Ich glaube nicht, dass Komposition immer besser ist als Vererbung (nur normalerweise).Wenn Mitarbeiter und Mitglied tatsächlich Benutzer sind und sich gegenseitig ausschließen, ist das erste Design besser.Stellen Sie sich das Szenario vor, in dem Sie auf den Benutzernamen eines Mitarbeiters zugreifen müssen.Mit dem zweiten Design hätten Sie:

myEmployee.UserInfo.UserName

was schlecht ist (Gesetz von Demeter), also würden Sie Folgendes umgestalten:

myEmployee.UserName

was eine kleine Methode für Employee erfordert, um sie an das User-Objekt zu delegieren.All dies wird durch den ersten Entwurf vermieden.

Answer 5

Schöne Frage, aber um Ablenkungen zu vermeiden Rechts Und falsch Ich würde darüber nachdenken, nach den Vor- und Nachteilen jedes Ansatzes zu fragen. Ich denke, das ist es, was Sie damit gemeint haben, was besser oder schlechter ist und warum.Ohnehin ....

Der erste Ansatz, auch bekannt als Vererbung

Vorteile:

• Ermöglicht polymorphes Verhalten.
• Ist anfänglich einfach und bequem.

Nachteile:

• Mai mit der Zeit komplex oder ungeschickt werden Wenn Weitere Verhaltensweisen und Beziehungen werden hinzugefügt.

Der zweite Ansatz, auch bekannt als Komposition

Vorteile:

• Lässt sich gut auf Nicht-Oop-Szenarien wie relationale Tabellen, strukturierte Programmierung usw. abbilden
• Ist unkompliziert (wenn auch nicht unbedingt bequem). schrittweise Beziehungen und Verhalten erweitern.

Nachteile:

• Kein Polymorphismus, daher ist es weniger praktisch, verwandte Informationen und Verhaltensweisen zu verwenden

Listen wie diese + die Fragen Jon Limjap Die oben genannten Informationen werden Ihnen bei der Entscheidungsfindung und beim Einstieg helfen – dann können Sie herausfinden, was das ist Rechts Antworten hätten sein sollen ;-)

Answer 6

Sie können sich Mitarbeiter auch als vorstellen Rolle des Benutzers (Person).Die Rolle eines Benutzers kann sich im Laufe der Zeit ändern (der Benutzer kann arbeitslos werden) oder der Benutzer kann mehrere Rollen gleichzeitig haben.

Vererbung ist viel besser, wenn es sie gibt real „ist eine“ Relation, zum Beispiel Apfel – Frucht.Aber seien Sie sehr vorsichtig:Kreis – Ellipse ist keine reale „ist ein“-Beziehung, da der Kreis weniger „Freiheit“ hat als die Ellipse (Kreis ist ein). Zustand der Ellipse) - siehe: Kreis-Ellipse-Problem.

Answer 7

Die eigentlichen Fragen sind:

• Welche Geschäftsregeln und User Stories stehen hinter einem Benutzer?
• Welche Geschäftsregeln und User Stories stehen hinter einem Mitarbeiter?
• Welche Geschäftsregeln und User Stories stehen hinter einem Mitglied?

Dabei kann es sich um drei völlig voneinander unabhängige Einheiten handeln oder nicht, und das bestimmt, ob Ihr erster oder zweiter Entwurf funktioniert oder ob ein anderer, völlig anderer Entwurf angebracht ist.

Answer 8

Keiner von beiden ist gut.Zu viel veränderlicher Zustand.Sie sollten nicht in der Lage sein, eine Instanz einer Klasse zu erstellen, die sich in einem ungültigen oder teilweise initialisierten Zustand befindet.

Allerdings ist die zweite Variante besser, weil sie die Zusammensetzung gegenüber der Vererbung bevorzugt.

Answer 9

Die Angabe Ihrer Anforderungen/Spezifikationen kann dabei helfen, das „beste Design“ zu finden.
Ihre Frage unterliegt im Moment zu sehr der Interpretation durch den Leser.

Answer 10

Hier ist ein Szenario, über das Sie nachdenken sollten:

Composition (das zweite Beispiel) ist vorzuziehen, wenn derselbe Benutzer sowohl ein Mitarbeiter als auch ein Mitglied sein kann.Warum?Denn bei zwei Instanzen (Mitarbeiter und Mitglied), die denselben Benutzer repräsentieren, müssen Sie die Benutzerdaten nicht an zwei Stellen aktualisieren, wenn sie sich ändern.Nur die Benutzerinstanz enthält alle Benutzerinformationen und nur diese müssen aktualisiert werden.Da sowohl die Employee- als auch die Member-Klasse dieselbe User-Instanz enthalten, enthalten beide automatisch die aktualisierten Informationen.

Answer 11

Drei weitere Optionen:

1. Habe den User Die Klasse enthält die Zusatzinformationen für Mitarbeiter und Mitglieder, wobei nicht verwendete Felder leer sind (die ID eines bestimmten User würde anzeigen, ob der Benutzer ein Mitarbeiter, Mitglied, beides oder was auch immer war).

2. Einen haben User Klasse, die eine Referenz auf eine enthält ISupplementalInfo, Wo ISupplementalInfo wird vererbt von ISupplementalEmployeeInfo, ISupplementalMemberInfo, usw.Code, der für alle Benutzer anwendbar ist, könnte damit arbeiten User Klassenobjekte und Code, der eine hatte User Die Referenz könnte Zugriff auf die ergänzenden Informationen eines Benutzers erhalten, aber dieser Ansatz würde eine Änderung vermeiden User wenn in Zukunft unterschiedliche Kombinationen von Zusatzinformationen erforderlich sind.

3. Wie oben, aber mit User Klasse enthält eine Art Sammlung von ISupplementalInfo.Dieser Ansatz hätte den Vorteil, dass das Hinzufügen von Eigenschaften zur Laufzeit zu einem Benutzer (z. B.weil ein Member wurde eingestellt).Bei Verwendung des vorherigen Ansatzes müssten unterschiedliche Klassen für unterschiedliche Kombinationen von Eigenschaften definiert werden.Die Umwandlung eines „Mitglieds“ in ein „Mitglied+Kunde“ würde einen anderen Code erfordern als die Umwandlung eines „Mitarbeiters“ in einen „Mitarbeiter+Kunde“.Der Nachteil des letztgenannten Ansatzes besteht darin, dass es schwieriger wäre, sich vor redundanten oder inkonsistenten Attributen zu schützen (mit etwas wie a Dictionary<Type, ISupplementalInfo> zusätzliche Informationen zu speichern könnte funktionieren, würde aber etwas „sperrig“ erscheinen.

Ich würde eher den zweiten Ansatz bevorzugen, da er eine zukünftige Erweiterung besser ermöglicht als die direkte Vererbung.Das Arbeiten mit einer Sammlung von Objekten anstelle eines einzelnen Objekts kann etwas aufwändig sein, aber dieser Ansatz ist möglicherweise besser als die anderen in der Lage, sich ändernde Anforderungen zu bewältigen.