What are the SOLID Principals?

1. The Single Responsibility Principle suggests that a class should have one reason to change. This does not mean that a class should have one method with just a few lines of code. It means that the class should correspond to one concept such as Person or Street Address. Assuming that a class has a good name in keeping with ubiquitous language, then a class that holds Manager in its name or is similarly named something vague with a name bridging several concerns is in violation of the Single Responsibility Principal. It is alright to have an "And" in a name occasionally, such as an object named "Street Address And Landline Phone Number." The two concepts need to fit together to justify an "And." (This description comes from Anne Epstein.) The name-based auditing for sanity checking if a class is in violation of the Single Responsibility Principle is only going to work if classes are named explicitly which is a must.
   
    
    
2. Update on 8/17/2012: This description is terrible! Instead see this and this and this. The Open/Closed Principle suggests that one should "close-off methods" on a class (by making them private) that do not need to be exposed beyond the class such as internal calculations of properties that occur when one changes a getsetter. Methods which are public invite being used by other classes so methods which are public should only be so intentionally. Some requests need to go in a "front door" and be accessed within the class itself, beyond the eyes of the rest of an application. Don't reveal too much.
   
    
    
3. The Liskov Substitution Principle (named for a Barbara Liskov) suggests one should not inherit from a parent if doing so requires significant polymorphism (overriding) for as much is a code smell. A square should not inherit from a rectangle as a parent. A square may be a rectangle "in real life" but it is not a rectangle as shaped in classes. Making a square inherit from a rectangle parent class would be an example of a violation of the Liskov Substitution Principle. A rectangle will have separate getsetters for both width and height, but such does not make sense for a square which cannot have differing lengths for width and height. (This example comes from Justin Pope.) A square that inherits from a rectangle would have to override the width and height getsetters to make a change to one enact a change to the other and would "smell."
   
    
    
4. The Interface Segregation Principle suggests that it is better to have numerous interfaces that correspond to the numerous classes they empower in lieu of one or two large interfaces. Also, an interface should only expose the methods needed on a class, not every method it can.
   
    
    
5. The Dependency Inversion Principle suggests that developers should loosely couple dependencies to classes, handing them in, in lieu of having classes call for them.
   
    
    
6. The Law of Demeter is sometimes included as a sixth SOLLID principle while in other lists of SOLID Principals it does not appear. It suggests that classes should only have knowledge of other classes which are closely related. It is often best logically to have two classes speak through an intermediary rather than to make a direct association as a proliferation of direct associations without regard to boundaries creates a spaghetti mess of crisscrossing dependencies which will ultimately make an application unmanageable.