According to Agile Software Development: Principles, Patterns and Practices, there are five object-oriented principles that help avoid rotting software:

1. Single-Responsibility Principle.  A class should have only one reason to change.  Originally called cohesion, it was defined as the functional relatedness of the methods within a class.  However, this is hard to apply.  By shifting the definition of cohesion to the relatedness of reasons for change, we get the much more pragmatic and applicable “a class should have only one reason to change.”  Now you can easily look at a class and see whether it violates this principle or not.
2. Open-Closed Principle.  Software entities should be open for extension, but closed for modification.  What this means is that changes of a certain kind, the dimension in which the design is closed, do not require changes to existing code, only additions of new code.  For example, if adding a new way to calculate taxes to a point-of-sale system, existing code should not need to be modified although new classes (code) may be added.
3. Liskov Substitution Principle.  Subtypes must be substitutable for their base types.  In Design by Contract terms, subtypes can only weaken the original precondition and strengthen the original postcondition.  In other words, the subtype must accept everything that the base type accepts (or more), and can only return the same range of values that the base type returned (or less).
4. Dependency-Inversion Principle.  Abstractions should not depend on details.  Details should depend on abstractions.  In most traditional n-tier models, the higher-level layers depend on the layer beneath it.  What happens is that the highest-level layers transitively depend on all the layers beneath them.  Instead of that, the DIP recommends inverting this dependency through an intermediate interface, thus breaking the transitive dependencies throughout the layers.
5. Interface Segregation Principle.  Clients should not be forced to depend on methods that they do not use.  Fat interfaces subject clients to changes in that interface to accommodate other clients’ needs.