The only thing that stays the same, in our field of Computer Science, is change itself. Do not try to predict what will happen in the future; instead know that the future will bring change, and that you will need to adapt to it.

Design systems which are capable of change, and you will be much more ready for the future.

Always:

• Program by Intention – “begin by focusing on motivation or desire”
• Analyze the the varying objects and forces in your system, encapsulate them
• Favor aggregation/delegation over inheritance
• Seek the Open-Closed principle – “open to extension, closed to modification.”
• Design to interfaces – “couple to interfaces, not implementation”
• Encapsulate the constructor – use Object.getInstance()
• Encapsulate variation – “what is hidden from you, can be changed”
• Think about how you test a design, when you create it.
• When choosing between two designs with similar cost/risk, consider how easy/difficult it would be to refactor from each to the other, should the need arise.

Think:

Think about the forces of the problem (Do we want to use this pattern / design?)

1. Contextual forces – How will the environment around you and your product affect your system/design?
2. Implementation forces – Will this design work? Is it worth it? Is there a better way?
3. Consequences – What will the results of our actions be? What are the trade-offs?

Think about how you test a design, when you create it. When choosing between two designs with similar cost/risk, consider how easy/difficult it would be to refactor from each to the other, should the need arise.

“Good coupling is Intentional, bad coupling is unnecessary or Accidental“

Never:

• Never allow Redundancy – “Redundancy is DEBT; you always pay for it later”
• Never use ‘new Object()’ notation – Use dependency injection / factories / encapsulation.

Coupling Forces:

1. Identity – One type coupled to the fact that another type exists.
2. Representational – One type coupled to the interface of another.
3. Inheritance – Coupling to a superclass. Changes propagate downward.
4. Subclass – Knowledge that an object is part of a polymorphic set… “knowing the implementation of another.”

About the author: Lincoln Baxter, III is a Senior Software Engineer at Red Hat, Inc., working on JBoss open-source projects. This blog represents his personal thoughts and perspectives, not necessarily those of his employer. He is a founder of OcpSoft, the author of PrettyFaces: bookmarking, SEO extensions for JSF, and an individual member of the JavaServer™ Faces Expert Group. When he is not swimming, running, or playing Ultimate Frisbee, Lincoln is focused on promoting open-source software and making web-applications more accessible for small businesses, individuals. His latest project is ScrumShark, an open-source, agile project management tool.