Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

(Figured this was too subjective for SO, so posting here...)

I have some behavior that I can implement in various ways. At least two methods are shows in the code snippet below. Presume that the m_well data member is correctly set somehow at object construction time.

struct Behavior
{
    virtual bool behavesWell() { return true; }

private:
    bool m_well;
public:
    bool behavesMemberWell() { return m_well; }
};

struct OtherBehavior : public Behavior
{
    virtual bool behavesWell() { return false; }
};

Obviously the one relies upon virtual dispatch, and the other merely the return of a data member.

A third, non-shown method would likely have the non-virtual public member function not return a fixed data member, but instead call a virtual - lets leave that aside for the purpose of this please.

What would lead you to one or other other of these two methods of implementing functionality, such that a user of this class can interrogate an object's behavior?

share|improve this question
    
I did one minor edit - and here is another clarification - this is internal code, to be used by a single team at a single site - no "external" users. –  sdg Dec 14 '10 at 0:14
    
Suggestion: Altought, you can use "struct X {...}" as "public class", I suggest, to use "class Z { public: ... }" in order to identify classes from plain data structures, and get used to add scope modifiers. –  umlcat Mar 23 '11 at 18:53
    
@umlcat: can you elaborate on the distinction you are drawing between 'classes' and 'plain data' please? why do you think they are important? –  sdg Mar 23 '11 at 19:54
    
Right. From a programmer point of view, "plain data" means the programming is not thinking about adding unnecesary "overhead" code to the program. Its more conceptual idea, altought, some optimizers may remove the vtable... –  umlcat Mar 23 '11 at 23:12
    
@umlcat Most classes add no overhead with optimization turned on –  David Stone Mar 9 '13 at 2:14

4 Answers 4

We've got some classes that work that way - there is a type-of function that returns something different in different subclasses. The problem I have is that there's no good way to tell within the debugger, given a BaseClass *.

Use a member variable. The next guy to work on the code may thank you.

share|improve this answer
    
While you could go poking at the vtable member, all other things being equal, this is a good point. +1. –  Logan Capaldo Dec 14 '10 at 0:40

As far as I can see, you've got a couple of conflicting issues here, which may be clarified if you could tell us for what purpose you're doing this? Is the code going to be used by you/your team, or are you designing an API for consumption by others?

If you're just trying to design a good interface to your functionality, put yourself in the shoes of the clients of your functions - write some unit tests. If when writing the unit tests, anything seems awkward or non-obvious, your design needs improving.

If your class is meant for sub-classing, then you don't want public data members, or protected data members for that matter. Data members that are private can be changed at any time without breaking the sub-classes, whereas changes to protected members (potentially) break sub-classes and changes to public data members (quite likely) break client code. It may seem tedious to have a getter/setter pair of methods to manipulate a data member, but it's worth it if you want to keep the implementation flexible and not design yourself into a corner.

The virtual methods would indicate that you're considering handing the client of your class an interface which would be pure virtual. If this is the case, then you can't have data members in an abstract (pure virtual) class, so that leads you to virtual methods with virtual method calls to get/set data items.

share|improve this answer

In your example, I would use a data member. It's simple and straightforward.

I would use a virtual method where behavior of the function actually changes in the derived class. In your example, it's still just returning a boolean, even if the value is different. Methods to me should be accomplishing something -- computation or I/O or what have you -- not just being an obtuse interface for data.

share|improve this answer

The rule of thumb is that all your data members should be private. There are exceptions to this rule, such as simple POD (plain old data) structs that are only passed around or stored, but more often than not it makes sense to keep all data members private.

If you need to give other objects access read access to a data member, then you write a getter. If your class will not have any child classes derived from it, then there is no need to make the getter virtual. The only time you need to make any member function virtual, is when you want to allow a derived class to override it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.