Classes & More Classes

[LB]

Mathhead200 wrote:

You just asked "why" someone would want to do it, implying there is no good reason. However, you never explained why it could be bad...

LB wrote:

It sure can't change the base class' private variables, why should it be able to change the behavior of the functions that deal with them?

I don't understand where you're confused?

Mathhead200 wrote:

Also notice that, there is no need to store the width and height as properties like that in the derived class.

I don't, I assign to them. because the interface does not define a way to change the width and height and neither does the derived class, it does exactly the same as your original example. To completely protect the width and height variables from deriving classes, you can use private inheritance and only publicly expose the functions you want to expose.

[ne555]

If you respect Demeter's Law and Tell, don't ask you will not need accessors.
The behaviour will be encapsulated, and the code will be more maintainable.
http://pragprog.com/articles/tell-dont-ask
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

@Mathhead200: If you don't listen to reason, ¿then what?
inheritance is evil, xP http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=3

[LB]

ne555, thanks for the great reading. This really sheds a light on the bad practices out there being taught. I'm glad that I haven't yet done much OO or I may have already contracted these bad habits...

[Mathhead200]

No, I meant there was no need to store the width and height in ANY variables. By creating the variables you force TwoByTwo to inherit them, regardless of whether they are private or not. It's waisted memory.

Okay... Give me an example or explain (not in the form of a question please) why declaring a getter or setter method as virtual is bad. That is, when does it cause unwanted behavior.

Also, you don't have to completely abandon the parent class's method to override it. You can invoke it within the overriden method. Example:

class P {
 public:
    virtual double f(double x) = 0;
    virtual double m(double x) { return f(x); }
};

class C {
 public:
    virtual double m(double x) { return P::m( x >= 0 ? x : -x ); }
};

[ne555]

¿Are you saying that the links are teaching bad practice?

[LB]

@ne555: no, I am saying that they are teaching good practice and to me exposing bad practices I have seen.

@Mathhead200: I know how to invoke a specific version of an overridden member function.

Here is a minimal example:

struct Entity
{
    virtual signed int getX() const = 0;
    virtual signed int getY() const = 0;

    virtual ~Entity(){}
};

class Enemy: public Entity
{
    signed int x, y;
public:
    virtual signed int getX(){ return(x); } //notice that these
    virtual signed int getY(){ return(y); } //are virtual funcs

    virtual void Attack() = 0;

    virtual ~Enemy(){}
};

class Goomba: public Entity
{
    boolean direction;
public:
    //why would you want to override getX and getY at this point?
    //If you do, you're obviously not going to be able to access x and y from Enemy,
    //so ANY definition would give unwanted behavior

    virtual void Attack(){}

    virtual ~Goomba(){}
};

[Mathhead200]

L B wrote:

//why would you want to override getX and getY at this point?
//If you do, you're obviously not going to be able to access x and y from Enemy

But yes you can! x and y are not accessed directly (i.e. by name) they are accessed via the methods getX and getY. I can't think of a really good reason you would need to reimplement the accessor methods, but that doesn't mean there won't come a time when you will think of a reason, and you'll wish you could.

Edit: Thanks for the links ne555, good reading.

[LB]

There is no reason to re-implement them. A deriving class should NEVER need to change the result of the original functions, because if they do then that is a design flaw. Obviously the code I posted is flawed too because x and y should be protected, but they were for examples. And besides, ne555 linked to a nice article about telling and not asking and thus making this discussion rather pointless, as this situation would never arise. Well, I've made a mess, and I hope with this I have cleaned it up: if you end up in a situation where you need tor redefine function behavior that should not change, you're doing something very, very wrong.

[Mathhead200]

Well I still thoroughly disagree, but I believe we have hijacked this forum... I'm willing to drop it at this point.

[BReynolds]

@ne555

Thank you for the links. I have read bit's of them and plan to read the rest.

@L B

Thank you for your comments, and all the insight you have given.

@Mathhead200

I can't think of a really good reason you would need to reimplement the accessor methods...

Unless you or somebody else can I won't be doing it.

@At all of you

I don't care if you did hijack the forum, It was very good reading for me. Thank you.