Ist es jemals gültig, ein Objekt von einer Basisklasse in eine Unterklasse zu konvertieren?

Question

In meiner Anwendung habe ich (wie in vielen anderen Anwendungen) eine Entität namens Contact, die eine beliebige Person darstellt. Auf seiner grundlegendsten Ebene wird dies zur Darstellung von Geschäftskontakten verwendet. Es kann jedoch auch verwendet werden, um Mitarbeiter des Unternehmens zu vertreten. und es gibt auch ein paar besondere Arten von Angestellten (sagen wir mal, es gibt eine namens Manager)

Ich versuche, dies als eine Vererbungsbeziehung zu modellieren, die Sinn macht. Mitarbeiter haben Namen und Adressen wie Kontakte, sowie eine Reihe von arbeitsbezogenen Attributen. Manager verfügen auch über eine Reihe managerspezifischer Attribute.

Die Schwierigkeit kommt, wenn ein Mitarbeiter zu einem Manager befördert wird. Ist es in Ordnung, die Basisklasse Employee in die erbende Klasse Manager zu konvertieren? Es fühlt sich falsch an. Ich denke, ich würde es mit einem spezialisierten Konstruktor unter Manager tun.

Nebenbei unterstützt NHibernate diese Art von Verhalten? Ist es so einfach wie den Mitarbeiter zu bekommen, den Manager vom Mitarbeiter zu erstellen und dann den Manager zu speichern?

Answer 1

Solange Ihr Geschäftsmodell mit Ihrer Domain übereinstimmt, machen Sie das Richtige.

aber es klingt für mich wie man so etwas haben sollte:

Manager Promote(Employee employee) 
{ 
    var manager = new Manager(); 
    //promote your employee to a manager here 
    return manager; 
} 

innerhalb einiger Workflow-Prozess von einer Art.

In Bezug auf NHibernate, es klingt wie Sie Ihre ORM-Logik mit Ihrer Geschäftsdomäne mischen. Die Beförderung eines Mitarbeiters zu einem Manager ist ein Geschäftsdomänenkonstrukt und gehört daher zu Ihrem Geschäftsmodell. Wie NHibernate jedoch Ihre Mitarbeiter und Ihre Manager in Ihre Datenbank einbindet, hat nichts mit Ihrem Geschäftsmodell zu tun, außer wie Sie sie abbilden. Dies hat jedoch nichts damit zu tun, wie man einen Mitarbeiter für einen Manager werben kann.

Answer 2

Ich hätte persönlich eine Basisklasse mit all den grundlegenden Dingen und einer Liste von Rollen.
Jede Rolle hat ihre eigenen Eigenschaften und Funktionalitäten.
Die Vorteile sind zweifach:

• Es ist einfach, eine Rolle zu/von einer Person
• Es Ihre Mitarbeiter mehrere Rollen haben können zu geben oder zu nehmen, ohne dass Sie ‚Klassen Kombination‘
machen müssen

Wenn Sie gehen mit einzelner inherritance mit inherritance gehen wird bald Sie mit Klassen wie „ManagerProgrammer“ machen, „ProgrammerStockManager“, „ProgrammerSupport“

Answer 3

ich mit der Zusammensetzung über inheri gehen würde tance in diesem Fall. Wenn Sie bei der Vererbung bleiben, wechseln Sie den Unterricht mit jeder Beförderung oder Herabstufung und jedes Mal, wenn Sie einen Kontakt einstellen oder ein Mitarbeiter verlässt und ein normaler Kontakt wird.

Es ist einfacher zu sagen, Kontakte haben Rollen. Sie können einem Kontakt eine Managerrolle hinzufügen, um sie zu bewerben, und die Rolle entfernen, um sie auszulösen.

Answer 4

G'day,

Wenn Sie feststellen, Sie haben eine abgeleitete Klasse von einem Typ in einen anderen abgeleiteten Typ zu konvertieren, dann ist das ein Geruch, der anfängliche Design-Probleme hat.

Mein Gefühl hier ist, dass Sie ein Manager-Objekt falsch darstellen.

Gehen Sie zurück zu den Grundlagen und denken Sie in OO-Termen, wo Ihre Basisklasse (Kontakt) die gemeinsamen Elemente von Employee und Manager-Objekten enthält. Alle abgeleiteten Objekte sind nur Spezialisierungen der Basisklasse.

In diesem Fall ist kein Manager eine Instanz eines Mitarbeiters?

Sowohl die Manager- als auch die Employee-Klasse sollten über ein reportsTo-Datenelement verfügen, das ebenfalls vom Typ Employee ist.

Der einzige Unterschied, den ich im Moment sehen kann, ist, dass ein Manager-Objekt jetzt eine Sammlung von Mitarbeiter-Objekten hat, die ihre eigenen directReports sind. Dies sollte wahrscheinlich als Zeiger auf einen Container von Employee-Objekten implementiert werden.

Ich kann mir keine Spezialisierung im Verhalten vorstellen, die ein Employee-Objekt von einem Manager-Objekt trennen muss.

Hmmm, vielleicht machen Sie die Basisklasse Person, die Kontaktdaten enthält.

Edit: Sorry, von Ihrem Kommentar Ich glaube, ich war nicht klar genug. Was ich beschrieben habe, führt nicht zu zwei separaten Klassen, die beide direkt von Ihrer Contact-Klasse abgeleitet sind, so dass Sie während der Laufzeit eine Instanz eines Mitarbeiters in einen Manager ändern müssen, was Ihre ursprüngliche Frage war.

Das heißt, ich denke nicht, dass Sie zwei abgeleitete Klassen haben sollten, einen Mitarbeiter und einen Manager, die direkt von Ihrer Kontaktklasse erben.

Sind nicht beide diese Arten von Menschen, die von einer Firma beschäftigt sind? Warum zwischen einem Manager und einem Mitarbeiter unterscheiden? Ist ein Mitarbeiter nicht länger ein Mitarbeiter, wenn er ein Manager wird?

Mit zwei abgeleiteten Klassen, einem Manager und einem Mitarbeiter, ist IMHO völlig falsch. Haben Sie versucht, Dinge in Bezug auf "isa" und "hat ein" Beziehungen zu brechen. Dann können Sie sehen, dass Ihre Grundstruktur falsch ist.

Um einen Mitarbeiter zu sagen "isa" Kontakt macht einfach keinen Sinn. Wahrscheinlicher ist, dass ein Mitarbeiter "isa" Person und eine Person "eine Reihe von Kontaktdaten hat.

Vielleicht leiten Sie die Manager-Klasse als Spezialisierung eines Mitarbeiters? Ein Mitarbeiter "isa" Person. Ein Manager "isa" Mitarbeiter, der "isa" Person ist.

HTH

prost,

Answer 5

Ja, es ist gültig.In Bezug auf die Implementierung könnten Sie:

• Statische Methode auf Manager: public static Manager Promote(Employee employee) { ... }
• Specialized Konstruktor auf Manager-
• Fabrik oder Serviceklasse

Ich denke, jeder dieser Ansätze eine gut wäre, Lösung. Ich persönlich mag die spezialisierte Konstrukteurslösung, da sie die reale Welt gut repräsentiert: Sie erstellen einen neuen Manager aus einem vorhandenen Mitarbeiter.

Answer 6

Kontakt ist ein Attribut von Employee. Arbeiter (Ihr Mitarbeiter) ist eine Rolle, Manager ist eine Rolle. Arbeiter und Manager sind beide noch Angestellte, haben aber Rollen. Rolle ist eine IS IN-Beziehung, Mitarbeiter ist eine AM A-Beziehung und Kontakt ist eine HAS A-Beziehung. Mitarbeiter hat einen Kontakt (1-1 Beziehung) Ein Kontakt pro Mitarbeiter (1-M, wenn sie zwei Telefone usw. haben, aber ich schweife ab) Mitarbeiter IS IN Rolle (MM Beziehung) Viele Mitarbeiter viele Rollen Mitarbeiter ist A (M-1 relatiohship) - Viele Angestellte, alle vom Mitarbeitertyp.

Sie ändern also die Rollen.