Now that the dust has settled from the recent Software Engineering 101 event we put on in Cleveland, I figured I would repost some of the material I talked about. This means some of connections that I vocalized and supplement the material from the slides I used for Software Engineering 101.
Object Oriented Principles, Practices, and Patterns
My first talk of the day was on Object Oriented Principles, Practices, and Patterns in which I start by discussing some common principles of object oriented programming: abstraction, encapsulation, inheritance, polymorphism, and I added composition in for good measure, which of course isn’t on its own a principle, but I feel deserves to be mentioned as its own entity at that point.
I covered an assortment of good practices for software developers to follow. Since Steve Smith was following my talk with one on SOLID, so I didn’t take the opportunity to discuss the Open/Closed Principle, which states that your code should be open to extension and closed to modification. This means that you can add to the behavior of your code by adding new code and not modifying what you already have.
In my patterns section I covered two of my favorite design patterns: the Strategy Pattern and the Template Method Pattern. These two are great for discussing with people. They’re very similar yet very different; one encapsulates the structure of an algorithm and allows for modification of the details of the steps while the other focuses on allowing for different algorithms to be used interchangeably. Each uses polymorphism, abstraction, encapsulation, and inheritance. They’re simple to explain and demonstrate, and they’re also very powerful. This makes them great examples.
Combining Everything
When we combine these principles and some design patterns we can achieve some great things. The strategy pattern is one of my favorite patterns, because it is very useful and improves maintainability greatly. I use it often. It uses, abstraction, encapsulation, composition, polymorphism, and either inheritance or interface implementation. On top of that it also helps follow the Open/Closed Principle, increasing the ease for changing the behavior of an application when the requirements change.
In my talk I was asked a great question, “if I don’t know design patterns, how will I know what I don’t know.” In other words, how can you possibly select the correct design problem to solve a problem. I recommended reading learning plenty just so you’ll be more prepared. There are plenty of books, and you don’t always need “the best” solution. Usually a good solution to the problem is enough. Steve Smith chimed in with a great answer though, he suggested practicing coding katas, which will often solve problems using design patterns or at least good, worthwhile practices.
Comments