Unterklasse oder nicht Unterklasse

Question

Ich habe drei Objekte; Aktion, Problem und Risiko. Diese enthalten alle eine Anzahl allgemeiner Variablen/Attribute (zum Beispiel: Beschreibung, Titel, Fälligkeitsdatum, ausgelöst durch usw.) und einige spezifische Felder (Risiko hat Wahrscheinlichkeit). Die Frage ist:

1. Sollte ich 3 separate Klassen Aktion erstellen, Risiko und Ausgabe jedes die Wiederholungsfelder enthält.

2. erstellen Elternklasse „Abstract_Item“ diese Felder und Operationen auf ihnen enthalten, und dann Aktion haben, Risiko- und Problemunterklasse Abstract_Item. Dies würde sich an DRY Prinzipal halten.

Answer 1

Ja, das ist zu Trockenanhaftmenge haben in der Regel eine sehr gute Idee außer, wenn die Klassen sehr, sehr unterschiedliche Nutzungen (dh beide Äpfel und Autos kann rot sein, noch würde ich beide nicht ableiten aus eine Basisklasse namens ProbablyRed). In Ihrem Fall würde ich jedoch definitiv für eine Basisklasse gehen, da die Implementierungen, die Sie beschreiben (Action, Issue, Risk), alle eine Art Geschäftsregel mit sehr ähnlicher Semantik zu sein scheinen.

Answer 2

Sie scheinen dies selbst zu beantworten. Wie du sagst, DRY.

Answer 3

Die abstrakte Elternklasse klingt wie der Weg zu gehen. Es wird es auch ermöglichen oder erleichtern (abhängig von Ihrer Sprache), Funktionen zu implementieren und zu verwenden, die auf eines der drei Elemente einwirken. Zum Beispiel könnten Sie eine Funktion "Eine Liste aller durch die Benutzer ausgelöst werden" erhalten.

Answer 4

Eine weitere Facette kann sichtbar werden, wenn Sie sich die Anwendungsfälle anschauen, die sich wahrscheinlich mit verschiedenen Untergruppen der Eigenschaften befassen.

Wenn zum Beispiel "label", "Fälligkeitsdatum" und "ausgelöst" in einer todo-ähnlichen Anwendung verwendet werden und andere Eigenschaften von "Aktion" und "Risiko" vorherrschen, sollten Sie eine Aggregation von sagen wir mal Aufgabe (Etikett, Fälligkeitsdatum, ...) und Thema, die Dinge wie Aktion, Issue eine polymorphe Referenz oder was auch immer, eines Tages meine Perspektive wird kommen

Answer 5

Lassen Sie uns sagen, wenn Sie haben die Vererbung verwendet. Über einen Zeitraum haben Sie neue Attribute, die nur für Action und Ausgabe aber nicht Risiko sind. Wie gehst du damit um? Wenn Sie sie unter Eltern setzen, dann erbt Risk Sachen, die irrelevant sind (Liskov Substituon Prinzip klopft?). Wenn Sie dann in Aktion und Risiko getrennt setzen, dann brechen Sie DRY, den ersten Grund, warum Sie die Vererbung begonnen haben. Point ist Inherence für die Wiederverwendung ist schlecht. Wenn es kein "ist-a" gibt, dann benutze es besser nicht und wenn du Zweifel hast, gibt es kein echtes "ist-a".

Meine Präferenz

Es gibt auch andere Wege zur Erreichung DRY wie im folgenden Beispielcode gezeigt.Mit diesem Zusatz von neuen Eigenschaften mein ein anderer sein Common2, ist das Hinzufügen von neuen Verhalten CommonBehavior2, wenn sie nicht für alle 3 Klassen gelten; wenn sie dann ändern Sie einfach bestehende Gemeinsame und CommonBehavior

public class Common implements CommonBehavior 
{ 
    String Description; 
    String title; 

    public void f() {} 
} 

public interface CommonBehavior 
{ 
    void f(); 
} 

public class Action implements CommonBehavior 
{ 
    private Common delegate; 

    pubic void f() 
    { 
    delegate.f(); 
    } 
} 

auf eine ähnliche Frage auf meine Antwort Schauen Sie auch mit einem anderen Beispiel aus der Praxis Design pattern to add a new class

Answer 6

Ich glaube, ich habe die gleiche Frage hier beantwortet

When to create a class vs setting a boolean flag?

Answer 7

Keine Unterklasse von jus t weil Objekte Daten oder Operationen teilen. Betrachten Sie die Zusammensetzung als Standardmethode, um DRY zu folgen.

In Ihrem speziellen Fall, erstellen Sie nur eine übergeordnete Klasse, wenn Ihre Objekte tatsächlich verwandt sind, das heißt, es ein semantisches ist „ist eine“ Beziehung zu der übergeordneten Klasse. Zum Beispiel, wenn Aktion, Problem und Risiko alle Ticket-Objekte sind.