Chris Weldon of Improving on SOLID

What more might I say about SOLID I have not yet articulated here and here? Well, Chris Weldon of Improving offered some insights that were new to me when I heard them at Code Camp one week ago:

1. In the name of the open/closed principal, do not change the signature of an existing method that has had any significant life within your application. Why not? Well, one nightmare scenario may occur when your code base gets compiled to a .dll file that is deployed for others to use. In this scenario, a change in method signature can sabotage others downstream who long ago wrote code that expected something different! Even with less extreme division lines this can happen. Another party working in the same code base as you could be writing new code to interact with a method independent of you on the same day that you are changing its signature. If a method's signature DOES really need to change, use some overloading. Make a new signature for a method with the same name. Leave the deprecated method be. Even if you think you can get away with deleting it, such a move is not wise. Fear of changing a method's signature drives OCP. It's healthy.
2. In the name of the Dependency Inversion Principal, avoid ever having an interface with unused methods. If four classes use all three methods on a common interface and a fifth class uses only two, then the outlying method will have to be nonetheless supported in a ghetto way by the fifth class. Perhaps, a junk method that just throws an exception can sit as a placeholder in the fifth class for the unneeded method. Boo! This should smell to you. The fix is to break the interface with three methods into two separate interfaces so that the fifth class may utilize ONLY one of the two interfaces (cleanly). Perhaps the first four classes that needed all three methods can inherit from a new, third interface which then uses the other two. Chris recommended creating wrapper interfaces of this nature rather than having God interfaces exposing methods that are not always applicable.
3. Liskov bug: A parent has a Save() method. Most children use the method. The one child that does not merely overrides the Save() method so that it does nothing. Bad! Now we have a method with a misleading name. This mess should exposition that the child has the wrong parent.