Rules of Thumb

Well, these aren't patterns, but just principles we should use when writing softwares, brought up by Russ Olsen in his Design Patterns in Ruby:

• Separate out the things that change from those that stay the same ... identify aspects of the system design that are likely to change, isolate them from the stable parts. Thus, when requirements change or bug fix comes along, even if we still need to modify the codes, the changes can be localized and the rest of the code can live on without changes.
  

• Program to an interface, not an implementation ... write code that uses the most general type possible. For example, by writing plane.fly & ship.sail, we are getting very specific, this results in tight coupling, the code using these objects needs to know the exact traveling mode. To loosen things up, we can generalize these vehicles by writing plane.travel & ship.travel instead, thus, the client code no longer needs to know the traveling mode, it just ask the objects to travel.
  

• Prefer composition over inheritance ... instead of saying an object is a kind of something, we say that it has something. We assemble the behaviors we need through composition, by supplying an object with objects that provide the needed functionalities.
  

• Delegate, delegate, delegate ... by preferring composition over inheritance, instead of being almighty (or inheriting from the almighty parent), an object can delegate the required functionality to another object.
  

• You ain't gonna need it (YAGNI) ... if you are not sure that you need something right now, postpone its implementation until you really need it. Why? Cos we tend to be wrong when we try to anticipate exactly what we will need in the future. And we should focus our time and energy implementing things that we definitely need right now.