SOLID : Design Principles

Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in "Agile Software Development: Principles, Patterns, and Practices". 

According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

• Rigidity - It is hard to change because every change affects too many other parts of the system.
• Fragility - When you make a change, unexpected parts of the system break.
• Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

Following 2 characters should be taken care during designing any software:

• High Cohesion - How focused are the responsibilities of the modules you are designing.
• Low Coupling - The degree to which modules rely on other modules.

Principles Of Object Oriented Class Design (the "SOLID" principles)

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.

ISP: The Interface Segregation Principle Make fine grained interfaces that are client specific.

DIP: The Dependency Inversion Principle Depend on abstractions, not on concretions.

Although the above design principles are good and helpful, but they should be used intelligently otherwise this may lead to problems.

The other principle , that is of a great importance is YAGNI (You ain't gonna need it).

According to YAGNI:

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now opens the possibility of conflicting with a necessary feature later.[clarification needed]
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work correctly, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards feature creep.

But then futuristic thinking is also a must while designing a software.
So, you should always take design decisions intelligently.