Erben Sie Mitglieder aus mehreren Klassen

Ich habe gelernt, mit OOD zu entwerfen und mit einem Szenario festzuhalten.

Ich habe eine Klasse User , die eine abstrakte Klasse Person erweitert. Die Klasse Person hat ein Mitglied mit dem Typ Address . Benutzer haben nur Benutzername und Passwort und Adresse einige Zeichenfolgenfelder.

Nun möchte ich eine Klasse Client hinzufügen, die eine Person oder eine Organisation sein kann (die hinzugefügt werden soll). Client wird auch einige Daten haben.

Ich habe über Schnittstellen nachgedacht, aber sie können nur Methoden haben. Kann mir jemand helfen, was das richtige Design sein wird?

Ich folge keinem Muster und Codieren mit C# .NET.


Aktualisieren

I think I could not explain the scenario properly. Sorry for that. Please, have a look on the diagram. Here, the Client class is what I want to add. Incomplete class diagram of my scenario

0
Schnittstellen sind nicht auf Methoden beschränkt, sie können auch Eigenschaften für Getter Setter und Events haben. Ich würde hier Schnittstellen bevorzugen
hinzugefügt der Autor Saghir A. Khatri, Quelle
"Ich habe über Schnittstellen nachgedacht, aber sie können nur Methoden haben." Nein, sie können auch Eigenschaften und Ereignisse haben ... Es ist mir nicht ganz klar, was Sie zu modellieren versuchen ...
hinzugefügt der Autor Jon Skeet, Quelle
@SergeyBerezovskiy Dies ist die Klasse Client , die von Person oder Organization übernommen werden kann.
hinzugefügt der Autor Raihan, Quelle
Außerdem denke ich, dass Organisation auch eine Adresse hat. Also sollte Adresse auf Client und Person und Organisation auf Client verweisen ?
hinzugefügt der Autor CompuChip, Quelle
Aus Ihrer Frage kann ich keine Klasse auswählen, die von mehreren Klassen geerbt werden sollte
hinzugefügt der Autor Sergey Berezovskiy, Quelle
Muss der Client ein Benutzer sein? Wenn So Client vom Benutzer erben muss, verschiebe die Adresse an den Benutzer und so wird es nun auch Adresse haben. Vielleicht sollten Sie hinzufügen müssen überschreiben Lese-Eigenschaft "UserType" zu Benutzerklasse, die in Unterklassen überschrieben wird. Unterklassen definiert, welche Art von UserTypes sie sind.
hinzugefügt der Autor Mino, Quelle

1 Antworten

Versuche mit der Komposition zu arbeiten. Eine Person und eine Organisation sind nicht unbedingt ein Benutzer, obwohl sie beide eine Adresse oder ein Benutzerkonto haben können. Tatsächlich haben sie wahrscheinlich mehr als eine von beiden.
Wenn Sie mehr in Bezug auf HAS A und weniger in Bezug auf IS A denken, können Sie mit mehr wartbaren Entscheidungen kommen. Zum Beispiel können Sie eine haben

class Address {
  public string street {get; private set;}
  public string city {get; private set;}
  public AddressTypes AddressType {get; private set;}//an enum to differentiate 
                                                     //"home address", "legal address"
  ...
}

Wenn Sie nun die Tatsache modellieren müssen, dass sowohl Person als auch Organisation Dinge sind, die Adresse haben müssen, können Sie eine Schnittstelle erstellen

interface IAddressable {
   IEnumerable
{get;} }

und lassen Sie sowohl Person als auch Organisation implementieren. Das Gleiche kann mit einer Account -Klasse geschehen, die Benutzername und Passwort enthält.

Nun müssen Person und Organisation nicht User s sein, aber sie können HABEN Accounts, Adressen und alles, was Sie sonst noch brauchen. Und Sie können sie zwingen, diese Dinge über Schnittstellen zu haben, wie oben gezeigt.

Wie für Client kann ich Ihr Problem sehen. Sie sind versucht zu sagen, dass "eine Person (oder eine Organisation) ein Kunde ist". Aber in Ihrem Entwurf "eine Person IST bereits ein Benutzer" und Sie können nicht Person von zwei verschiedenen Basisklassen erben.

Beachten Sie jedoch, dass eine Person nicht notwendigerweise ein Client ist. Ich bin nicht sicher, was ein Client genau in Ihrem Modell ist, aber nehmen wir an, es ist jemand mit einer Adresse und einem Konto, der eine Person oder eine Organisation sein kann (und Sie wollen wissen, ob es das eine oder das andere ist). Sie können dies auf verschiedene Arten tun, aber eines könnte sein:

abstract class Client : IAddressable, IWithAccount {
  //implement IAddressable and IWithAccount
}

class PersonClient : Client
{
    public PersonClient(Person person)
    {
       //make the Client's address refer to the Person's address
       //make the Client's account refer to the Person's account
    }
}

class OrganizationClient : Client
{
    public OrganizationClient(Organization organization)
    {
       //make the Client's address refer to the Organization's address
       //make the Client's account refer to the Organization's account
    }
}

die Vorteile sind:

  • Sie müssen Ihren vorhandenen Code nicht ändern, um eine Rolle (Client) als Basisklasse bestehender Entitäten (Person, Organisation) anzupassen.
  • Wenn Ihr Unternehmen beispielsweise States als Clients hat, können Sie einen StateClient hinzufügen, ohne die vorhandenen Teile zu ändern
0
hinzugefügt
Danke für eine gute Beratung. Ich habe die Klasse Benutzer nur für die Benutzer des Systems hinzugefügt. Sie müssen keine Person sein. Aber sie können persönliche Daten haben.
hinzugefügt der Autor Raihan, Quelle
Person ist eine abstrakte Klasse. Wie kann ich das instanziieren?
hinzugefügt der Autor Raihan, Quelle
Wenn ich alle Kunden erreichen möchte, gibt es ein Problem mit Ihrem Design. Ich muss PersonClient.GetAll() und OrganizationClient.GetAll() aufrufen.
hinzugefügt der Autor Raihan, Quelle
@Raihan Ich bin mir nicht sicher, ob ich deine Frage verstehe, aber du brauchst eine konkrete Klasse, die von Person erbt, wenn es eine abstrakte Klasse ist.
hinzugefügt der Autor Paolo Falabella, Quelle
@Raihan mein Code war nur ein Beispiel. Sie können Client zu einer nicht abstrakten Klasse machen, wenn Sie es so brauchen. Und wenn die Arten von Clients in der Zukunft nicht erweitert werden, können Sie im Client eine Enumeration angeben, die den Typ des Clients angibt, wie ich es für AddressType in der Address-Klasse anstelle von PersonClient und OrganizationClient-Unterklassen getan habe
hinzugefügt der Autor Paolo Falabella, Quelle