OSGi Evangelism and OO Design Principles

OSGi adds a higher layer of granularity to OO abstraction, information hiding, design by contract, etc. I like this quote  from Modular Mind: "Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.". In this presentation, Module Systems and Architectures, on OSGI, Martin Lippert also shows another evolution that can be seen in OSGi:


Good Old Design Principles
DIP SOC LSP ADP TDA DRY AIP
ISP SCP OCP IHP SRP SDP

New Design Principles
Use services ---> Separate between interface and implementation
Use extensions ---> working but extensible

Here's a breakdown of Martin's shortlist of "good old design principles":

Class Design Principle

• Separation Of Concerns (SoC)
• Tell, Don't Ask (TDA)
• Don't Repeat Yourself (DRY)
• Dependency Injection Principle (DIP)
• Liskov Substitution Principle (LSP)
• Open Closed Principle (OCP)
• Single Responsibility Principle (SRP)
• Interface Segregation Principle (ISP)

Package Design Principles

Cohesion Principles: 

• Reuse/Release Equivalency Principle (REP)
• Common Reuse Principle (CRP) 
• Common Closure Principle (CCP)

Coupling Principles:

• Acyclic Dependencies Principle (ADP)
• Stable Dependencies Principle (SDP)
• Stable Abstractions Principle (SAP)

  Object-Oriented Reengineering - Principles of OOD - Radu Marinescu,
  OO Design Principles - Stefan Kluth,

OO Best Practices

• The O/R Impedance Mismatch and Inheritance vs Relational Databases
• (Prefer) Composition versus inheritance
• SRP The Single Responsibility Principle A class should have one, and only one, reason to change.
• OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
• LSP The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
• DIP The Dependency Inversion Principle (aka IoC) Depend on abstractions, not on concretions.
• ISP The Interface Segregation Principle Make fine grained interfaces that are client specific.
• (also in clean code smells) The LawOfDemeter specifies a style guideline: "Only talk to your immediate friends." one never calls a method on an object you got from another call nor on a global object.
• clean code (cc) Object/structure assymetry, data transfer object (DTO) active record is one example (don't put business logic in one)
• tell, don't ask
• Data professionals that claim that your object/component models must be driven by their data models