The document outlines several design principles for software engineering including: The Single Responsibility Principle which states that a class should have one, and only one, reason to change. The Open-Closed Principle which states that software should be extendable without modifying existing code. The Liskov Substitution Principle which states that subclasses must be substitutable for their base classes.

1. Design principles

2. SRPSingle Responsibility Principle
A class should have one, and only one, reason to change.

3. OCPOpen-Closed Principle
You should be able to extend a classes behaviour, without modifying it.

4. LSPLiskov Substitution Principle
Derived classes must be substitutable for their base classes.

5. DIPDependency Inversion Principle
Depend on abstractions, not on concretions.

6. ISPInterface Segregation Principle
Make fine grained interfaces that are client specific.

7. REPRelease-Reuse Equivalency Principle
The granule of reuse is the granule of release.

8. CCPCommon Closure Principle
Classes that change together are packaged together.

9. CRPCommon Reuse Principle
Classes that are used together are packaged together.

10. ADPAcyclic Dependencies Principle
The dependency graph of packages must have no cycles.

11. SDPStable Dependencies Principle
Depend in the direction of stability.

12. SAPStable Abstractions Principle
Abstractness increases with stability.

13. Boy Scout Rule
Leave the code cleaner than you found it.

14. PoLAPrinciple of Least Astonishment
Related to the concept of developer habitability. If you (and the other fellow
developers of your team) are astonished by some specific solution, please discuss
this with the author (or follow the Boy Scout Rule).

15. Composition Instead of
Inheritance(Yo-Yo problem)
Inheritance implicates a problem towards testing. Only with sophisticated Build-In-
Tests (and unit tests) inheritance is good to handle.

16. Information Hiding
Principle Modularize
Around Secrets
Guidance for class design above basic data hiding. Relates also to hiding of
methods and especially algorithms building the value of that class.

17. SoCSeparation of Concerns
Group related stuff on every level of hierarchy: Method, Class, Package,
Component, Subsystem, ...

18. YAGNIYou ain't gonna need it
Another "meta-argument" besides the principle of least astonishment, which is
usable to argue against overcomplicated or too abstract/generic programming.

19. LoDLaw of Demeter
Good metric to follow, if it comes to "chain reactions" while modifying classes.