Software Design Principles

Software design principles represent a set of guidelines that helps us to avoid having a bad design.

The open –closed principle:

A module should be open for extension but closed for modification, can be extended, without requiring them to be modified. => able to change to module without changing source code, 2 ways:
a. Meyer’s Open/Closed Principle: the first principle, implementation of a class could only be modified to correct errors; new or changed features would require that a different class be created
b. Polymorphic Open/Closed Principle: the implementations can be changed and multiple implementations could be created and polymorphically substituted for each other.

The Liskov Substitution Principle

Subclasses should be substitutable for their base classes. Derived classes should be substitutable for their base classes. That is, a user of a base class should continue to function properly if a derivative of that base class is passed to it.

Dependency Inversion Principle

Depend upon Abstractions. Do not depend upon concretions, Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes.

The Interface Segregation Principle:

Many client specific interfaces are better than one general purpose interface. The essence of the principle is quite simple. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.

Release Reuse Equivalency Principle

The unit of reuse is the unit of release. Effective reuse requires tracking of releases from a change control system. The package is the effective unit of reuse and release.

Common Reuse Principle

Classes that aren’t reused together should not be grouped together.

Stable Dependencies Principle

depend on the direction of stability

Information hiding and encapsulation

Information hiding is the principle of segregation of design decisions

Low coupling

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements, Clear boundaries between tiers, program against interfaces, not classes.

High Cohesion

High Cohesion attempts to keep objects appropriately focused, manageable and understandable. High Cohesion is generally used in support of Low Coupling, High cohesion means that the responsibilities of a given element are strongly related and highly focused.

The Acyclic Dependencies Principle

The dependencies between packages must not form cycles.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s