Design Decisions/Tradeoffs of the Strategy Pattern

The benefit of using the strategy pattern is maintainability and extensibility of code as opposed to the reusability of code through inheritance offered by using standard OO design. The problem that Joe faced was that by relying so heavily on inheritance he either had to include excessive attributes/behaviors in the Duck superclass or he had to use duplicate code to create specific attributes/behaviors in every subclass of Duck. In the first scenario he would have to deal with shadowing unused attributes/behaviors every time he encountered a subclass that didn’t use them. In the second scenario he would need to update every subclass each and every time there was a change to an attribute or behavior being used by them. By using the strategy pattern Joe was able to encapsulate things that vary (such as behaviors) and simply reference their interface. This gave him the power to update behaviors and have the changes take effect everywhere the behavior is being used. This also gave him the flexibility to use these behavior interfaces anywhere he wished as they were not specific to any particular class. So even though the strategy pattern involves a bit more complexity when initially being set up, in the long run it makes updating and maintaining your program much easier and more efficient.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s