OOP: How to add a method to an existing object?

[vincentthorpe]

How to add a method to an existing objects without modifying its parent class?
Hi community lm doing a little project, so l'll explain a bit first then l'll ask what l want to do:

* l have the following class Sprite:
- attribute
- method ()

SpriteClass
    imagePath
    col
    row
    count
    animation () // method
	
        [player object]
	    movement () // method

	[apple object]
	    generation () // method 

Suppose l have these instances of SpriteClass: player, apple

So what l want to do is:
how do l add movement() method to player object and generation() method to apple object... without putting those methods in my SpriteClass

because l dont fit appropiate to put those methods my class. thanks in forward.

[keskiverto]

Do you mean that you have:

SpriteClass player;
SpriteClass apple;

or:

Player foo;
Apple bar;

// where
class Player : public SpriteClass
class Apple  : public SpriteClass

[vincentthorpe]

As l said l have one class SpriteClass, and two instances of that class

SpriteClass player (imagePath, col, row, count); // within all parameteres constructor of course
SpriteClass apple (imagePath, col, row, count);

[Repeater]

You could create new classes that inherit from SpriteClass and add behavior to them (inheritance)

Alternatively, create a new player class that contains an instance of type SpriteClass, and similarly a new apple class that contains an instance of type SpriteClass (composition).

[vincentthorpe]

Thanks for the response. But creating two classes for both player and apple isnt a bit redundance ? because l only will have one object of that class. and not multiple objects

Is it possible to solve this without creating a new classes?

[Repeater]

Are you asking how you can change the behaviour of Spriteclass, without changing Spriteclass? It's impossible to change behaviour without changing Spriteclass in some way.

You could add a std::function member variable to Spriteclass. For one instance, you set it to some movement function, and for another instance you set it to some generation function.

This is a nasty antipattern, though.

You could give Spriteclass a value indicating what kind of thing it was; an apple or a player, and then have a function to call that changes its behaviour depending on what that value is set to. That's also truly hideous.

The C++ way to have different objects behave differently is for them to actually be different.

If you're only going to have one player, and one apple, then the function doesn't need to be a class function. You could just write your generation function and your movement function as free functions and just call them.

[keskiverto]

Redundant?

Quiz: How many classes do you see in this?

#include <iostream>

int main() {
  std::cout << "Hello world\n";
  return 0;
}

How many instances of those classes do you usually have in your programs?

[JLBorges]

> Is it possible to solve this without creating a new classes?

Yes. Write two non-member functions:

void move( SpriteClass& player ) ;
void generate( SpriteClass& apple ) ; 

And then, pass the player object to the first function and the apple object to the second.

Note that the behaviour of an object is more than what appears at first sight by just looking at the member functions of its associated class. For instance, std::cout << str ; is a definite part of the behaviour of the object of type std::string

This is sound advice:

If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions. - Scott Meyers in Dr. Dobb's

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197?pgno=1

[vincentthorpe]

@Repeater && @JLBorges
You both have right. l think the best solution is to create independient functions and to pass each

Because imagine apple object can move for itself. but player object can only move when l press the correponding keys. So it will look pretty ugly to put two movement() methods, and generation() in Sprite class. because player never will call generation method

Sorry l forgot to say l'll have one (controllable) player, and one apple. generates when the player touches.

Thanks for the response, as well.

[keskiverto]

Herb Sutter wrote about the interface of a class:
http://www.gotw.ca/publications/mill02.htm

An entertaining read.