By paddloPayday loans

Home > Learning Design Patterns > The Saturation Plan: One's Bound to hit the Target

The Saturation Plan: One's Bound to hit the Target

Color Saturation and Learning Saturation

Color Saturation and Learning Saturation

Saturating the Field
I was looking at John Lindquist’s fantastic video explaining the Strategy design pattern, and while I’ve been thinking about a slightly different tact for learning, it gave me an idea. Up to this point, Chandima and I have gone over lots of design patterns in varying levels of depth. However, what I think would help the developers on this blog learn design patterns would be to take just a few, one from each of the three main categories, and come at it from different angles. That is, saturate readers with lots of information and examples from just three patterns.

The Three Types of Patterns

The Gang of Four divide up design patterns into three types:

  • Creational
  • Structural
  • Behavioral

I realize that those names don’t mean jack unless they are viewed in terms of problem-solving. That is, what specific problems are addressed by each of these groupings of design patterns? So let’s start with a summary of the problems that design patterns address.

On pages 24-25 in their book, GoF discuss the common causes of redesign. What causes developers to tear apart a program and have to start over? Why can’t a class be re-used? Why can’t just a few things be changed to introduce something new? If you read those causes, you can better see the solutions to those problems. The following are the eight causes of redesign GoF specify that cause problems. Remember! This is a list of bad practices that Gang of Four have identified that prevent change and reuse of objects:

  1. Creating an object by specifying a class explicitly
  2. Dependence on specific operations
  3. Dependence on hardware and software platform
  4. Dependence on object representations of implementations
  5. Algorithmic dependencies
  6. Tight coupling
  7. Extending functionality by subclassing
  8. Inability to alter classes conveniently

Design Patterns are meant to address these various bad habits. For example, the Factory Method addresses the issue of creating an object by specifying a class explicitly. So you may be wondering—What’s wrong with that? How else could you create an object?

Most developers do not see the problem with explicit class creation. Simply stated, to do so can tangle you up in the particulars of the class. A commitment to a specific class leads to dependencies on the that class’ implementation. However, instead of committing to a class, commit only to an interface and use the other class through the interface. Then, if you want to make changes, you only have the interface, which cannot cause a dependency. Using the Factory Method, you create class instances indirectly through a factory. The factory creates the instance, and your Client uses the factory’s instance.

The Saturation Plan

To get this plan off the ground, I thought that a good place to begin would be with the Strategy pattern. The reason for choosing the strategy pattern is that because it specifically addresses more than one of the issues: Algorithmic dependencies and Extending functionality by subclassing. Everyone loves a good algorithm; but if a new one comes along that does a better job (like swapping in a Skip List for some other search algorithm), you don’t want to tear up your whole program to do so. You just want to tuck in the new algorithm where they old one was. Secondly, the Strategy pattern is one of the key patterns for using delegation. Any program that uses delegation over inheritance has fewer dependencies. Finally, the Strategy pattern is flexible so maybe developers can be weaned from the MVC long enough to get into a new pattern and move ahead in design patterns.

This is not an invitation to argue the best algorithm. For all I care, you can use a bubble sort—algorithms are not the issue. The issue is that we use and change algorithms so often that if we can do that with more flexibility; then redesign becomes easier. We’ll look at the Strategy pattern from so many different angles with several different posts, that you’ll be so inundated with it, you can’t help but understand it.

The Principles

OOP and design pattern principles are like cheat sheets to understand design patterns and become a better programmer. If you haven’t gone over them lately, they’re all here for you. Go over them, and you’ll be part of the discussion and get more out of the saturation plan.

Your Thoughts

The comment section is for feedback. I’m going to initiate the plan in the next couple of weeks, but if this is not something you feel will be of any benefit for you or you have a better idea, let me know.

Share
  1. Jim Bachalo
    September 19, 2010 at 7:10 am | #1

    Hi Bill
    look forward to your next article on the Strategy pattern. I was wondering
    what your opinion is on the use of dependency injection, ie in frameworks
    like Robotlegs , or, just about every app written for the iPhone.
    Sine DI breaks one of the main rules of OOP, encapsulation, perhaps a blog
    post suggesting better alternatives might benefit the flash community?
    All the best
    jim bachalo

  2. September 19, 2010 at 7:43 am | #2

    Hi Jim,

    Thanks for allowing me to post this in our comments section because I believe that several of our readers may be interested in Dependency Injection (DI).

    First, of all, my introduction to DI was through Miško Hevery’s discussion of its use in Unit Testing. So I’ve always (wrongly) associated it with Unit Testing. However, the basic concept is best illuminated by Martin Fowler in his discussion of Inversion of Control.

    Second, some types of DI may break encapsulation, but I don’t think that they all do or even if any do when applied correctly. Let me give you an example of a common type of DI:

    ?View Code ACTIONSCRIPT
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    
    package
    {
    	class BillzClass
    	{
    		private var someObj:Object;
     
    		public function BillzClass(goodStuff:Object)
    		{
    			this.someObj=goodStuff;
    		}
    	}
    }

    The constructor function depends on the object goodStuff (there’s your dependency injection) being assigned to the variable someObj. Because someObj is a private variable, it’s encapsulated in the class. While it is dependent, I don’t see where it breaks encapsulation.

    However, I’m glad you brought it up because while I use DI all the time, I’ve never really thought about it as DI. Maybe I am breaking encapsulation in ways I have not realized. In Fowler’s discussion of DI in the context of Inversion of Control, he talks about it as it is not a special case but rather very common. (He notes that declaring that one’s class uses DI is like saying, My car is unique because it has wheels.) According Fowler,

    Using dependency injection can help make it easier to see what the component dependencies are.

    Thus, it makes testing easier–at least according to Miško Hevery.

    It turns out that DI is nowhere as simple as I had assumed, and to top that off, you will find different types of DI. If anyone reading this blog would like to add to this discussion, you’re more than welcome. In the meantime, I’m going to see if I can find out more about DI and see if it can help us better understand ActionScript 3.0 Design Patterns.

    Thanks again for bringing up this important topic.

    Kindest regards,
    Bill

  3. September 21, 2010 at 7:43 am | #3

    Hi Bill,

    Nice idea with this saturation plan. I usually find my self questioning what’s going on, or will go on, with a program. How to classify or design a code within a category? Do I see/want a creational, behavioral or structural code pattern ahead of me? Usually I get a right rate of WTF/m (http://www.osnews.com/story/19266/WTFs_m) unless a programmer uses a well implemented design pattern.

    As for the chosen pattern, Strategy, I like the fact that it is a behavioral but … well, basically I’m already bored of it. I don’t know why but I cannot see the “beauty” of it as it’s so simple and obvious (maybe that’s it?!). Anyway, maybe you’ll come up with some nice example/argument that will open my eyes.

    Nice to “read” you again.
    Cheers!
    Bill_BsB

  4. September 21, 2010 at 7:58 am | #4

    Bill_BsB,

    In a way, I’m really glad you’re already saturated with the Strategy pattern because you can help out (as you have in the past) with questions and comments. Your example of a human object that includes a heart leaves the developer no chance of including Zombies in his/her mix of characters is the kind of examples I’m talking about.)

    Also, I’m hoping to discover things about some of these patterns that I really haven’t considered as much as I should. For example, what exactly is a Family of Algorithms? If you don’t know right off the top of your head, there are still some mysteries left in the Strategy pattern for you. Likewise, what about the Context? For me, it’s clear as a bell in the State pattern, but it’s got a lot of fuzzy edges in the Strategy pattern–at least for me.

    So hang in there for the saturation–even if you’re already saturated!

    Kindest regards,
    Bill

  1. September 16, 2010 at 9:52 pm | #1
  2. September 20, 2010 at 1:58 am | #2

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>