Design Patterns

As a Java Developer I realized how important is follow design patterns in our applications. I'm trying this book from Eric Freeman and it was really useful to me.

In my concern the two most popular design patterns are Strategy and Observer. Strategy Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy let's the algorithm vary independently from clients that use it.

In another hand we have observer pattern, basically Defines one to many dependency between objects so that when one object change state, all of its dependents are notified and updated automatically.

Design Patterns tell us how structure classes and objects to solve certain problems and it is our job to adapt those designs to fit our particular application. When you implements design patterns your code become more smart flexible and changeable. The only constant in software development systems as the life rule is the change. If we are thinking in develop a good code base and get ready for the work in the future like code maintenance you should implement this concepts.

Frameworks and libraries are also useful in software development, whit they you can create functionality more faster and easier but they are not design patterns; they provide specific implementations that we link into our code. Sometimes, however, libraries and frameworks make use of design patterns in their implementations. That's great, because once you understand you'll more quickly.

Design patterns don't go directly in your code, they first go into your brain. Once you've loaded your brain with a good working knowledge of patterns, you can start to apply them in to your new designs.

With this tools in the future you'll be able to design great applications and you'll feel like a good software architect.

Another great think about the book is define design principles as "A class should have only one reason to change" that introduces a term very common in oop is cohesion, that is a term you'll hear used as measure of how closely a class or a module supports a single purpose or responsability.

Every responsability of a class is an area of potential change. More than one responsability means more than one area of change. 

source: Head First Design Patterns