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."
"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."
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."