Korrekte Möglichkeit, gemeinsame Eigenschaften zu verschieben

Question

Ich habe eine Reihe von Eigenschaften um 20 von denen, die ich brauche in zwei verschiedenen Einheiten (Klassen) für hierarchische überschreiben Einstellungen System.

Also, die einfache Idee, die ich mir vorstellen kann, ist, erstellen Sie eine abstrakte Klasse mit diesen 20 gemeinsamen Eigenschaften und erben die abstrakte Klasse in beiden Entitäten.

Aber das wird nicht funktionieren, da ich auch einige allgemeinere Eigenschaften habe, die allen Entitäten gemeinsam sind. Ich erben also schon alle Entitäten. Und diese 20 Eigenschaften sind nicht allen Entitäten gemeinsam (nur zwei - drei von ihnen). Daher kann ich diese 20 Eigenschaften in der vorhandenen abstrakten Klasse nicht hinzufügen.

Ich habe versucht, eine Schnittstelle zu erstellen und zu implementieren, aber dann habe ich vergessen, ich muss das gleiche in konkreten Klassen implementieren. Wenn ich sie also in konkreten Klassen definieren muss, hilft das nicht, mein Problem zu lösen.

Irgendeine Idee? Was ist der richtige Weg, das zu tun? In naher Zukunft kann ich einige gemeinsame Eigenschaften über wenige Entitäten haben. Was soll ich also tun, um Konsistenz zwischen allgemeinen Eigenschaften zu erhalten, ohne die gemeinsamen Eigenschaften in den einzelnen Entitäten erneut zu besuchen und neu zu schreiben?

Answer 1

Lassen Sie Ihre Klasse "allgemeine Einstellungen" von Ihrer Klasse "common entity" erben. Leiten Sie dann Ihre Einstellungsklassen von der gemeinsamen Einstellungsklasse ab.

class common_entity {} 

class common_settings : common_entity {} 

class settings : common_settings {} 

class entity : common_entity {} 

Answer 2

Vielleicht irre ich mich, aber manchmal neigen wir dazu, zu viel Wiederverwendbarkeit zu wollen.

finden Sie in diesem Beispielcode

public class Person 
{ 
    public string Name { get; set; } 
} 

public class Company 
{ 
    public string Name { get; set; } 
} 

Und nur weil wir denken, dass beide Klassen eine Name Eigenschaft teilen, sollten wir eine Basisklasse erstellen:

public class Entity 
{ 
    public string Name { get; set; } 
} 

public class Person : Entity 
{ 
} 

public class Company : Entity 
{ 
} 

ich definitiv eine Basisentität Klasse definieren würde weil jede Entität eine eindeutige Kennung besitzen sollte, aber nicht für eine Name. Und wenn eine Teilmenge von Entitäten eine Name besitzen sollte, würde ich eine interface definieren, die von konkreten Entitäten implementiert würde oder nicht. Später werde ich Objekte fragen, ob sie eine bestimmte Schnittstelle implementieren (d. H. obj is IWhatever oder var whatever = obj as IWhatever).

BTW, wie Sie bereits in Ihrer eigenen Lösung bemerkt haben, während einige Aktionen die Codewiedergabefähigkeit erhöhen könnten, können diese Ihr Design negativ beeinflussen.

einfach überprüfen, was Sie gesagt haben:

ich eine Reihe von Eigenschaften etwa 20 von ihnen haben, die ich in zwei verschiedenen Einheiten benötigen

So haben Sie zwei Klassen was sollte 20 Eigenschaften implementieren und Sie kratzen sich den Kopf, nur weil Sie eine interface definieren könnten und Sie müssten es in diesen beiden Klassen implementieren?

Gehen Sie für die interface Ansatz! Hat Visual Studio keine Schnittstellenimplementierungscodeerzeugung?

Denken Sie, dass eine gemeinsame Kritik an OOP ist, dass Sie mehr Code produzieren am Ende, während der zentrale Punkt der OOP ist, dass mehr Code bedeutet nicht weniger Wartbarkeit wenn Sie Ihren Code einfach und verständlich zu halten. Es geht nicht darum, weniger zu kodieren, sondern richtig zu codieren.