This is a discussion on Pattern to add variation to class within the Software Patterns forums, part of the Testing category; Hello, I am trying to modify a class that needs a lot of if/then/else statements inside some of ...
|
|||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Pattern to add variation to class
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 |
|
|||
|
Re: Pattern to add variation to class
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 |
|
|||
|
Re: Pattern to add variation to class
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. |