Design Patterns in Ruby [Digest 1] About Patterns

 

The following tips are really essential

 

the patterns for patterns:

1) Seperate out the things that change from those stay the same

A key goal of software engineering is to builld a system that allow us to contain the damage.

To make all changes local rather than change them everywhere.

It requires to identify and modulize the parts those most likely to change.

Hmmm... Seperate the changes parts from the stable parts. but how to do?

 

2) Program to an interface, not a implementation

It does not mean to program to the "interface" itself but to program to most general type you can.

Abstract important methods from class is a good idea, but it not enough

Ruby (a language that lacks interfaces in the built-in syntax sense)

actually encourages you to program to your interfaces in the sense of rogramming to the most general types.

 

3) Prefer composition over inheritance

Inheritancewill bind two classes with common implementation core.

The superclass changes will effect the subclasses behavior.

The interior of superclass will be exposed to subclasses, which might be forgotten.

If our goal is to build systems that are not tightly coupled together, to build systems
"where a single change does not ripple through the code like a sonic boom, breaking the glassware as it goes, then probably we should not rely on inheritance as much as we do."

 

Take the Vehicle and Car example: (It is not every vehicle need start and stop engine)

class Vehicle
  # All sorts of vehicle-related code...
  def start_engine
    # Start the engine
  end
  def stop_engine
    # Stop the engine
  end
end

class Car < Vehicle
  def sunday_drive
    start_engine
    # Cruise out into the country and return
    stop_engine
  end
end

  

So it goes to:

class Engine
  # All sorts of engine-related code...
  def start
    # Start the engine
  end
  def stop
    # Stop the engine
  end
end

class Car
  def initialize
    @engine = Engine.new
  end
  def sunday_drive
    @engine.start
    # Cruise out into the country and return...
    @engine.stop
  end
end

 

4) Delegate

class Car
  # same as above
  def start_engine
    @engine.start
  end
  
  def stop_engine
    @engine.stop
  end
end

 

The composition and delegate gracefully replace the inheritance.

But it bring in some dull methods, and some minor performance cost.

In ruby the built-in lib support delegate to remove dull mothods.

 

Last rule is wrote by the writer:

 

You aint gonna need it

"This design principle comes out of the Extreme Programming world and is elegantly summed up by the phrase You Ain’t Gonna Need It (YAGNI for short). The YAGNI principle says simply that you should not implement features,
or design in flexibility, that you don’t need right now. Why? Because chances are, you ain’t gonna need it later, either."

 

"If you are not sure that you need it right now, postpone implementing the functionality until you really do need it."

 

The principle of the rule is that is the simple realization that we tend to be wrong when we try to anticipate exactly what we will need in the future

 

In the end , the last paragraph I love the most:

 

"The proper use of design patterns is the art of making your system just flexible enough to deal with the problems you have today, but no more. Patterns are useful techniques, rather than ends in themselves. They can help you construct a working system, but your system will not work better because you used all 23 of the GoF design patterns in every possible combination. Your code will work better only if it focuses on the job it needs to do right now."