StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h2>Patterns are complex</h2> <p>All design patterns should be used with care. In my opinion <a href="http://www.industriallogic.com/xp/refactoring/catalog.html" rel="noreferrer">you should refactor towards patterns</a> when there is a valid reason to do so instead of implementing a pattern right away. The general problem with using patterns is that they add complexity. Overuse of patterns makes a given application or system cumbersome to further develop and maintain.</p> <p>Most of the time, there is a simple solution, and you won't need to apply any specific pattern. A good rule of thumb is to use a pattern whenever pieces of code tend to be replaced or need to be changed often and be prepared to take on the caveat of complex code when using a pattern.</p> <p>Remember that <a href="http://www.codinghorror.com/blog/archives/000380.html" rel="noreferrer">your goal should be simplicity</a> and employ a pattern if you see a practical need to support change in your code.</p> <h2>Principles over patterns</h2> <p>It may seem like a moot to use patterns if they can evidently lead to over-engineered and complex solutions. However it is instead much more interesting for a programmer to read up on <em>design techniques and principles</em> that lay the foundation for most of the patterns. In fact one of my <a href="http://oreilly.com/catalog/9780596007126" rel="noreferrer">favorite books on 'design patterns' stresses this</a> by reiterating on what principles are applicable on the pattern in question. They are simple enough to be useful than patterns in terms of relevance. Some of the principles are general enough to encompass more than object oriented programming (OOP), such as <a href="https://stackoverflow.com/questions/56860/what-is-the-liskov-substitution-principle">Liskov Substitution Principle</a>, as long as you can build modules of your code.</p> <p>There are a multitude of design principles but those described in the <a href="http://en.wikipedia.org/wiki/Design_Patterns" rel="noreferrer">first chapter of GoF book</a> are quite useful to start with.</p> <ul> <li><em>Program to an 'interface', not an 'implementation'.</em> (Gang of Four 1995:18)</li> <li><em>Favor 'object composition' over 'class inheritance'.</em> (Gang of Four 1995:20)</li> </ul> <p>Let those sink in on you for a while. It should be noted that when GoF was written an <a href="http://en.wikipedia.org/wiki/Interface_(computer_science)" rel="noreferrer">interface</a> means anything that is an abstraction (which also means super classes), not to be confused with the interface as a type in Java or C#. The second principle comes from the observed overuse of inheritance which is <a href="https://stackoverflow.com/questions/1740706/object-oriented-programming-class-design-confusion/">sadly still common today</a>.</p> <p>From there you can read up on <a href="http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx" rel="noreferrer">SOLID principles</a> which was made known by Robert Cecil Martin <a href="http://en.wikipedia.org/wiki/Robert_Cecil_Martin" rel="noreferrer">(aka. Uncle Bob)</a>. Scott Hanselman interviewed Uncle Bob in a <a href="http://www.hanselman.com/blog/HanselminutesPodcast145SOLIDPrinciplesWithUncleBobRobertCMartin.aspx" rel="noreferrer">podcast about these principles</a>:</p> <ul> <li><strong>S</strong>ingle Responsibility Principle</li> <li><strong>O</strong>pen Closed Principle</li> <li><strong>L</strong>iskov Substitution Principle</li> <li><strong>I</strong>nterface Segregation Principle</li> <li><strong>D</strong>ependency Inversion Principle</li> </ul> <p>These principles are a good start to read up on and discuss with your peers. You may find that the principles interweave with each other and with other processes such as <a href="http://en.wikipedia.org/wiki/Separation_of_concerns" rel="noreferrer">separation of concerns</a> and <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="noreferrer">dependency injection</a>. After doing <a href="http://en.wikipedia.org/wiki/Test-driven_development" rel="noreferrer">TDD</a> for a while you also may find that these principles come naturally in practice as you need to follow them to some degree in order to create <em>isolated</em> and <em>repeatable</em> unit tests.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload