The principle provide some guidelines: take an object and for any method in that object the principle tell us that we should only invoke methods that belong to:

• the object itself
• object passed in as a parameter to the method
• any object the method creates or instantiates
• any component of the object

In evidence:

Software developers have known for years that software that changes frequently should be decoupled from software that changes infrequently. When applied to individual programs and systems this principle is sometimes called The Common Closure Principle. When it is applied to the information management of an enterprise, it is called SOA.

Great…

Every object in your system should have a single responibility, and all the object’s services should be focused on carrying out the single responsibility.

This is a simple test that can help to understood if an object violates the SRP.

For each method in your class write the ‘test phrase’:

The class_name method_name itself.

If exist a phrase that has no sense, probably your object is non SRP compliant and you need to refactor your design.

Avoid duplicate code by abstracting out things that are common and placing those things in a single location…

…and also doing it in a way that won’t create more problems down the lines. Rater that just tossing code that apperas more than once in a single class, you need make sure each piece of information and behavior in your system has a single, clear place where it exists. Your system always know exactly where to go when it needs information or behavior,.

DRY is about having each piece of information and behavior in your system in a single, sensible place.

Classes should be open for extentions but close to modification.

Once you have a class that works, and is being used, you really don’t want to make changs to it unless you have to. But remember, CHANGE is the great constant in software development. With the OCP, we allow for change through extention, rather that having go back and modify your existing code.

It’s really a combination between encapsulation and abstraction. You are finding the behavior that stays the same away into a base class, abstracting into a base class (so you locks the code from modification), but when you need modification you can extend creating a subclass. That’s where encapsulation come in: you are encapsulating what varies(behavior in the subclass) away from what stays the same, the common behavior in the base class.

So,  abstract common behavior and encapsulate what change!!!

Great software always does what the customer wants it to. So even the customer think of new ways to use the software, it doesn’t break or give them unexpected results

The object-oriented programmers says:

Great software is code that is object oriented. So there is not a bunch of duplicate code, and each object pretty much controls its own behavior. It’s also easy to extend because your design is really solid and flexible

The design-guru programmer says:

Great software is when use tried and true design patterns and principles. You have kept your object loosely coupled, and your code open for extension but close to modification.

So, the steps are:

1 Make sure your software does what the customer wants it to do.

2. Apply basic OO principles to add flexibility.

3. Strive for a maintainable, reusable design.

One of the most beautiful Alpi Graie’s valley, in Valle d’Aosta.

I have climbed to rifugio Benevolo. A very beatiful day with my friends, even if in the afternoon rains.

“Depending on how you look at it, Funambol is a Silicon Valley company with offshore development in Italy, or an Italian company with an offshore headquarter in the US (we do strategy, marketing, product management, biz dev, sales and operations here). Technically, the first is more close to reality…”

Great!