Design and development principles

SOLID

• Single responsibility principle: a class should have only a single responsibility. A class should have only one reason to change. e.g. DAO only focuses on the work for persistence, it should not contain business logic.  http://www.oodesign.com/single-responsibility-principle.html
• Open/closed principle: software entities should be open for extension, but closed for modification. Those changes in the existing code should be minimized, since it's assumed that the existing code is already unit tested and changes in already written code might affect the existing functionality in an unwanted manner. http://www.oodesign.com/open-close-principle.html
• Liskov substitution principle: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. Sub class must enhace functionality, but not reduce them.
• http://www.oodesign.com/liskov-s-substitution-principle.html  (//TODO not fully agree with these examples)
• http://www.codeproject.com/Articles/595160/Understand-Liskov-Substitution-Principle-LSP 
• http://lassala.net/2010/11/04/a-good-example-of-liskov-substitution-principle/
• kind of relating to single responsibility principle
• Interface segregation principle: many client-specific interfaces are better than one general-purpose interface.  http://www.oodesign.com/interface-segregation-principle.html
• Dependency inversion principle: one should Depend upon Abstractions. Do not depend upon concretions.Dependency injection (spring IoC) is the one following this principle.  http://www.oodesign.com/dependency-inversion-principle.html

Encapsulate what varies – when a logic is encapsulated in one class, when this logic is going to be changed, only this class is affected. The client class would not be affected. Factory design pattern is one example of this principle, which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.
Favor composition over inheritance – Composition allows to change behaviour of a class at runtime by setting property that is using interface polymorphism, while Inheritance adds functionality at compile time. Composition is also know as HAS-A relation and inheritance is also known as IS-A relation. The design pattern Strategy, Decorator use this principle. http://javarevisited.blogspot.ca/2013/06/why-favor-composition-over-inheritance-java-oops-design.html
Programming for interface not implementation -
Loose coupling -
Hollywood principle -
DRY – don’t repeat yourself means don’t duplicated code.  e.g. util static method, constant
KISS - Keep It Simple and Stupid
YAGNI - You aren't gonna need it. Always implement things when you actually need them, never when you just foresee that you need them. see here

https://en.wikipedia.org/wiki/Category:Programming_principles