Java - Designing Principles

We all are familiar with object oriented programming concept. But since OOP is very basic, let's not miss out on it.

Object Oriented Programming:
Object oriented programming is a concept in programming language showing the following characteristics -

• Inheritance - Child classes or subclasses is a specialized version of class that inherits the attributes and basic behaviour from their parent class and then may or may not add/alter attributes or behaviour. Inheritance basically defines "is a" relationship between classes.
• Abstraction - It is solving the complex reality by modeling classes appropriate to the problem, and then working at the most appropriate level of inheritance.
• Encapsulation - It conceals the functional details of the class from objects that send messages to it.
• Polymorphism - Polymorphism is the ability of one type to appear as another type. It can further be classified as runtime or compile time polymorphism.

Now before we get into principles, let's understand some definitions.

• Cohesion: The term cohesion is used to indicate the degree to which a class has a single, well-focused purpose. A component exhibits high cohesion when all its functions/methods are strongly related in terms of function.
• Coupling: Coupling is the degree to which one class knows about another class. Two classes are said to be loosely coupled, when changes in one never or rarely necessitate changes in the other.
• Association: Association is the relationship between classes. It may be binary (relationship between two classes) or N-ary (relationship between multiple classes).
• Aggregation: Aggregation (represented by hollow diamond) is a special type of association which defines "is a part of" relationship. E.g. an employee is a part of a team.
• Composition: Composition (represented by shaded diamond) is a stronger form of aggregation where the whole and the part have coincident lifetimes, and is very common that whole manages the lifecycle of the part.

Designing principles for Class Structure:

• Classes should be loosely coupled: Loosely coupled classes ensures less dependency and a change in the class will rarely necessitate a change in another class.
• Classes should be more cohesive: More cohesive the class is, better is the definition / purpose of the class.
• Open Closed Principle - Abstract class v/s interface: A program should be open for extensions but closed for modifications. Abstract classes gives us freedom to add new methods later without breaking the client, whereas interface gives us freedom with regard to base class. Interfaces should be considered immutable, but new methods can be added to separate base interfaces, which is extended by existing interface.
• Program to an interface, not an implementation - An interface ideally defines cohesive set of behaviour, which is decoupled from the implementation. Interfaces are generally published, and define the system. Implementation, on the other hand, may have other methods which may be public, but may not be published (as defined by Martin Fowler). E.g. to use java collection, client just needs to know the interfaces Set and List and need not worry about implementation details. Pattern based on this principle: Strategy
• Encapsulate the concept that is likely to change - Favour object composition over class inheritance to achieve polymorphism: Inheritance develops tight coupling between base class and subclass. Composition reduces coupling as you have smaller pieces plug into big, which defines the configuration of big. That gives flexibility. (In a way, composition uses inheritance but typically you implement a small interface and do not inherit from big classes.) It is prototypical example for the flexibility of composition over inheritance. Using inheritance here, one cannot easily change strategy objects. Pattern based on this principle: Strategy
• Dependency Inversion Principle: High level module should not depend upon low level modules, but both should depend upon abstractions. Abstractions should not depend upon details, but details should depend on abstractions.
• Interface segregation principle - Many specific interfaces are better than one general interface.

References:

http://www.artima.com/lejava/articles/designprinciples.html
http://www.hokstad.com/why-coupling-is-always-bad-cohesion-vs-coupling.html
http://javaboutique.internet.com/Case_Study/