DBTechCon – Spring 2011
DBTechCon was a blazing success last week. Feedback on the sessions was awesome. Thousands of people worldwide attended the more than 70 seasons on diverse topics. If you missed this Virtual Conference, you can register to view the sessions On Demand, or receive them on DVD. Click here to go find out more.
SOLID Code – Day 4
We have been discussing the different components of the SOLID acronym from Robert Martin, defining five basic principles of object oriented programming. As stated previously, these principles apply to any object oriented language, and even to some that are hybrid or non-object oriented languages.
The five principles of SOLID are:
• Single Responsibility
• Open/Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion
The goal for applying these principles to your software development practices is that you will write software that is stable, robust, and extensible over time. Today we continue this discussion on the second principle…the Interface Segregation Principle.
One of the primary goals of Object Oriented Programming is to break things down into objects that have very specific tasks (Single Responsibility Principle). The Interface Segregation Principle takes this goal a step further. With Interface Segregation, the intention is to keep your interfaces granular enough that you can make changes to aspects of your software not requiring a complete re-compile of large libraries.
The Single Responsibility Principle requires that all methods and properties of a class are dependent on a single purpose of that class. Interface Segregation will break that task down further reducing the impact of the number of software components impacted by changes over time.
Robert Martin gives an example of this principle with a description of a printer driver class that was extremely bloated. It had features for print, collate and staple all in the same class. While these are all functions of the printer for which drivers were being written, including them in the main class required compiling of a lot of code that would not be modified. Changing features for a staple finishing step would require compiling all the print code as well.
Robert recommended that the single print interface be split into multiple interfaces for different functions. This technique resulted in the reduction of code that would be modified for any of the individual features.
Are you finding this series helpful? Please let me know with a yes or no…drop a line on facebook, twitter or Email at btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
SelecTViews – Cloud security
With Stephen Wynkoop
What SPECIFIC steps can you start taking to assure success? Gazzang also on the show today, along with our Facebook question and upcoming events!
[Watch the Show]
Featured Article(s)
Troubleshooting with Dispatchers
If you look at your last Crisis and you don’t who the dispatcher is, do you think this is something that you might be able to add to your process?
Featured White Paper(s)
Upgrading to Microsoft SQL Server 2008 R2 from Microsoft SQL Server 2008, SQL Server 2005, and SQL Server 2000
More than ever, organizations rely on data storage and analysis for business operations. Companies need the ability to deploy… (read more)