views:

234

answers:

5

foreword:

I have a component, lets call it IView. This component is implemented by BaseView class which holds most of it's functionality. We are using the template pattern to delegate logic to inheretting classes.

The problem:

We have a property named IView.Visible, that indicates if the component should or should not be visible. This property is not virtual since it involves some logic in our BaseView.

We have created a virtual protected method IsVisible which is invoked from BaseView.Visible to decide the final value of IView.Visible.

We feel that this property name, IsVisible, is not descriptive and clear enough to the implementor of the derived class.

It's been suggested to rename it to ShouldBeVisible, but we still fill that there is a better name.

What do you think ? Do you have a better name ? Is there a good naming convention that covers this topic of template methods ?


Update: Just to clarify a point, the Visible and IsVisible properties don't have side effect on the component, The Visible property uses the value from IsVisible to decide if the value of Visible should be true, but it is not the only consideration and couple other of the internal states of the component to give the final verdict.

A: 

There is no 'right' or 'wrong' in this question, only 'better' or 'worse'.

Personally I would make the Property that "involves some logic" a method GetVisible() to make clear that there is some logic (even if it is that simple that it could be property as well).

The property holding the information could be just Visible.

This are like different members are understood: Property is data (or an illusion of data) and methods are logic.

Stefan Steinegger
A: 

Does the base class implement the property or is it intended to be implemented by the inheriting class, i.e. is it abstract? My first thought is that it should be named as it would be in the inherited class. If it controls whether the class output is visible then Visible would seem to be the correct name. The name shouldn't, at least in my mind, reflect the implementation rather the purpose.

Lazarus
The inheriting class is to implement the IsVisible property, which is not public, but protected. The question is about the IsVisible, and it's relation to Visible.
Alex Shnayder
A: 

I think "virtual protected" does suffice the purpose, it already specifies that it can and will be overridden sometime and its accessed by child classes.

Naming should not be too big in order to code again and again and also IsVisible is standard way of naming. Also it should fall under correct english. ShouldBeVisible sounds like it is some sort of condition/validation and not a property.

Name of member should only describe the purpose and not the logic or too technical details, that will just make names bigger and bigger.

Akash Kava
A: 

Since the method under consideration is the inheriting class' implementation of Visible, I would go with the horrible ugly, but very descriptive name, VisibleImplementation or VisibleImpl, if you must. It makes it very clear to the developer that this is where he is to implement his logic for making the component visible or not.

 protected bool VisibleImplementation()  { ... }

Alternatively, you could give it the same name Visible and require it to take a boolean parameter, indicating if it being called from the base implementation. Personally, I dislike introducing a parameter just to distinguish between methods, but sometimes you have to make compromises.

 protected bool Visible( boolean fromBase ) { ... }
tvanfosson
+1  A: 

I've never been especially keen on this naming convention, but the Framework Design Guidelines book suggests the usage of 'Core' as the suffix for this type of pattern. This code is taken from the Microsoft System.Windows.Forms.Control class

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

internal virtual bool CanSelectCore()
{
    ...
}

My concern with this solution is that you are exposing a method of unknown complexity with possible side effects as a property, but since you can rummage through the .NET framework code and see that this convention is used quite often if you are looking for a standard this may be as close as you'll get.

Martin Harris