Pattern to add variation to class

[fabiogr]

Hello,

I am trying to modify a class that needs a lot of if/then/else
statements inside some of the public methods. I looked at the Strategy
and State patterns, but my main problem is that some of the methods I
thought about moving to the State/Strategy classes have dependencies
on non-variated methods, that is, the context class.

My intent is to pick class A

class A
{
public:
M1();
M2();
M3();
}

and move let's say M2() and M3() to the new classes (variated
methods).

Please let me know what do you think.

Thanks,

Fabio

[EventHelix.com]

Using a state pattern should help.

In the state machine class declare the states to be friends. That
way you can access the private methods and variables of the state
machine.

I know friend is not recommended but in this case it does not
break encapsulation by using friends. Here a private class is being
declared a friend.

The declarations are as shown below:

class State_Machine
{
private:
class State_A
{
};
friend State_A;
...
};

See the following article on hierarchical state machines:

http://www.eventhelix.com/RealtimeMa...ateMachine.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Case Diagrams in PDF

[avalanche@texoma.net]

Here's a bit of an example. Let's assume that M1 does some
operations, calls setName(), and then does more operations. Let's
assume that setName() has to be called where it is called.

class A {
private:
setName();
public:
M1() {
.... do stuff .... (1)
setName();
.... do stuff .... (2)
}
}

To allow the first and second "do stuff"s to be interchangable but
ensure that setName() gets called between "do stuff" executions, you
could break your algorithm up into smaller pieces. For example:

class A {
private:
setName();
public:
final M1() {
doStuff1();
setName();
doStuff2();
}

doStuff1() { ... do stuff ... }
doStuff2() { ... do stuff ... }

}

This would allow you to subclass A and write your own doStuff1() and
doStuff2() methods. The reason I made M1() final was to ensure that
doStuff1(), setName(), and doStuff2() got called in the correct order.
This approach allows you to customize functionality of an A by
subclassing.

I'm sure there are more ways to achieve the same results.