Phil Japikse explains SOLID software principles - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion- and how to apply them using design patterns.
Phil Japikse is a Microsoft MVP and also holds MCSD, MCDBA, CSM, and CSP certifications. He has spoken at Code Camps and Days of .NET and is the Lead Director for the Cincinnati .Net User’s Group. Phil works as the Patterns and Practices Evangelist for Telerik (www.telerik.com). You can follow Phil on twitter via www.twitter.com/skimedic and read his blog at www.skimedic.com/blog.
Code PaLOUsa is a conference designed to cover all aspects of software development regardless of technology stack. It has sessions revolving around Microsoft, Java, and other development platforms; along with session on higher levels that are platform agnostic. The conference schedule will feature presentations from well-known professionals in the software development community.
Barbara Liskov is a "she"
Barbara was referred to as a "he" several times during this talk.
2. "make a method do ONE thing well" is ambiguous. A method which calls 2 methods that each do ONE thing well, will do TWO things, unless you define doing the 2 things as doing 1. Maybe for you it's clear what you mean, sorry, for me isn't.
3. instills a fear of change which shouldn't really exist, the changes are the only constant thing, right?
5. the liskov principle is a nice one, nobody actually implements it as it's stated (possibly Eiffel, with the postconditions). Overriding shouldn't be allowed in case the principle is enforced (the behavior of a method between child and parent classes differs, hence they can't really be "substitutable").
6. there is a good undertone of "think before you apply".
7. the rest is ok, but again, unconvincing.
Just my 2 cents.
4. "no plans survive the first battle", the same applies to all the "smart, beautiful, elegant" APIs I ran into, after a while (think years) they became ugly, tired, useless and in general obnoxious.
IMO in both cases someone tries (too hard) to extract some smarty-pants "principles" from a fairly down-to-earth example, and, in doing so, lose or hide the meaning.
Double Checked Locking might be broken
Re: Double Checked Locking might be broken
For Java, one should keep in mind that this double checked locking for Singleton creation might be broken.
Uh, that was solved almost 8 years ago with Java 5.