Wie rein virtuelle geschütztes Eigentum

Question

Vorwort nennen:

ich eine Komponente haben, lässt es IView nennen. Diese Komponente wird von der BaseView-Klasse implementiert, die die meisten Funktionen enthält. Wir verwenden das Vorlagenmuster, um Logik an Inheretting-Klassen zu delegieren.

Das Problem:

Wir haben eine Eigenschaft namens IView.Visible, dass, wenn die Komponente anzeigt, sollte oder nicht sichtbar sein sollen. Diese Eigenschaft ist nicht virtuell, da es einige Logik in unserem BaseView beinhaltet.

Wir haben eine virtuelle geschützte Methode IsVisible erstellt, die von BaseView.Visible aufgerufen wird, um den endgültigen Wert von IView.Visible zu bestimmen.

Wir glauben, dass dieser Eigenschaftsname, IsVisible, nicht aussagekräftig genug für den Implementierer der abgeleiteten Klasse ist.

Es wurde vorgeschlagen, es in ShuldBeVisible umzubenennen, aber wir füllen immer noch, dass es einen besseren Namen gibt.

Was denkst du? Hast du einen besseren Namen? Gibt es eine gute Namenskonvention, die dieses Thema der Vorlagenmethoden behandelt?

---

Update: nur einen Punkt zu klären, die Visible und IsVisible Eigenschaften Nebenwirkung nicht auf der Komponente, die Visible-Eigenschaft verwendet den Wert von IsVisible zu entscheiden, ob der Wert von Visible wahr sein sollte , aber es ist nicht die einzige Überlegung und koppelt andere der inneren Zustände der Komponente, um das abschließende Urteil zu geben.

Answer 1

Ich habe noch nie auf dieser Namenskonvention besonders daran interessiert gewesen, aber das Framework Design Guidelines Buch schlägt die Verwendung von ‚Core‘ als Suffix für diese Art von Muster. Dieser Code wird von der Microsoft System.Windows.Forms.Control Klasse genommen

public bool CanSelect 
{ 
    get 
    { 
     return this.CanSelectCore(); 
    } 
} 

internal virtual bool CanSelectCore() 
{ 
    ... 
} 

Meine Sorge mit dieser Lösung besteht darin, dass Sie eine Methode unbekannter Komplexität mit möglichen Nebenwirkungen als eine Eigenschaft aussetzen, aber da kann man wühlen Durch den .NET-Framework-Code und sehen Sie, dass diese Konvention häufig verwendet wird, wenn Sie nach einem Standard suchen, der so nah wie möglich sein wird.

Answer 2

Es gibt kein 'richtig' oder 'falsch' in dieser Frage, nur 'besser' oder 'schlechter'.

Persönlich würde ich die Eigenschaft machen, die "einige Logik" eine Methode GetVisible() beteiligt, um klar zu machen, dass es eine Logik gibt (auch wenn es so einfach ist, dass es auch Eigenschaft sein könnte).

Die Eigenschaft, die die Information enthält, könnte nur sichtbar sein.

Dies sind wie verschiedene Mitglieder verstanden werden: Eigenschaft ist Daten (oder eine Illusion von Daten) und Methoden sind Logik.

Answer 3

Implementiert die Basisklasse die Eigenschaft oder soll sie von der erbenden Klasse implementiert werden, d. H. Ist sie abstrakt? Mein erster Gedanke ist, dass es so benannt werden sollte, wie es in der geerbten Klasse wäre. Wenn es kontrolliert, ob die Klassenausgabe sichtbar ist, dann scheint Visible der korrekte Name zu sein. Der Name sollte, zumindest in meinen Augen, nicht die Umsetzung, sondern den Zweck widerspiegeln.

Answer 4

Ich denke, "virtual protected" genügt den Zweck, es gibt bereits an, dass es irgendwann außer Kraft gesetzt werden kann und von untergeordneten Klassen zugegriffen wird.

Benennung sollte nicht zu groß sein, um wieder und wieder zu codieren und auch IsVisible ist Standard Art der Benennung. Auch sollte es unter korrektes Englisch fallen. ShouldBeVisible klingt wie eine Bedingung/Validierung und keine Eigenschaft.

Name des Mitglieds sollte nur den Zweck und nicht die Logik oder zu technische Details beschreiben, die nur Namen größer und größer machen.

Answer 5

Da die betrachtete Methode die Implementierung der Erbenklasse von Visible ist, würde ich mit dem schrecklich hässlichen, aber sehr beschreibenden Namen VisibleImplementation oder VisibleImpl gehen, wenn Sie müssen. Es macht dem Entwickler klar, dass er hier seine Logik implementieren muss, um die Komponente sichtbar zu machen oder nicht.

protected bool VisibleImplementation() { ... } 

Alternativ können Sie es den gleichen Namen Visible geben und es erfordert einen Booleschen Parameter zu nehmen, die angibt, ob es von der Basisimplementierung aufgerufen wird. Persönlich mag ich es nicht, einen Parameter einzuführen, nur um zwischen Methoden zu unterscheiden, aber manchmal muss man Kompromisse eingehen.

protected bool Visible(boolean fromBase) { ... }