Design Paterns Articles

design-patterns - Key Principles of Software Architecture
Code Smell
Patterns and Practices
Portland Pattern Repository

Active Record
Dependencies Injection

Design Patterns help, but like everything else, over using it, thus abusing it may lead to unmaintainable code (code that are hard to understand).

Know the alternatives and judge the trade-offs of using one alternative over another.

If a system has business benefits, delaying those benefits cost money. However, you don't want to make decision now that will hamper future growth. But if you add flexibility now and get it wrong, the complexity added for flexibility's sake may actually make it harder to evolve in the future and may delay deployment and thus delay the benefit. Although such systems may be small, most enterprises have a lot of them so the cumulative effect of an inappropriate architecture can be significant.

Only build feature that are requested by the customers. Validate the ideas with customers or with the rest of your teams. Don't just bake the feature into the system just because you think that the customer will need it. At least, validate the idea with the rest of your team.

Choosing an architecture means that you have to understand the particular problems of your system (or requirements) and choose an appropriate design based on that understanding. It is about choices and alternatives. Even when you choose a particular pattern, you'll have to modify it to meet your needs. You cannot build enterprise software without thinking.
Use layers and APIs. Divide your application into sub-components or services so that each sub-component and service can be individually tested and exposed. The result is that you have high quality software (testing each individual sub-component is easier than testing the whole entire complex software), and your services can be re-used outside of your own main application.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License