Session 6 (Technically 8) - Design Patterns: Structural Patterns

<Meh>

Two posts in one evening... spoiling my 4 or 5 readers (^_^)

Anyways, in this session, we continue with design patterns, namely Structural Design Patterns

Firstly, there are a lot and funny enough, if you didn't recognize any of the creational patterns, you'll definitely recognize a few here. Patterns like the Proxy Pattern (I call it the Wrapper Pattern).. the Facade should be recognizable as well (you'll notice it focusses a lot on the SRP).

In this session, we take a look at the Adapter, Composite and Decorator patterns.

Adapter: getting two classes that don't share the same interface to talk to each other
Composite: If you don't know how to build a tree hierarchy... this is how you should build it
Decorator: Wrap separate pieces of functionality into separate classes so that you can add and remove them with ease... decorating the default or original object.

The decorator for me was very exciting. I had never seen this pattern before but had taken a stab at implementing something similar a few times back in the day. It reminded me a lot of the abstract method pattern, although both serve different purposes, they're both extremely easy to use and they give your application a level of flexibility one can only dream of.

The the code sample, you'll see me build a travel package with various options. When I was coding this, I the following in mind:

You work at a travel agency or even a ticketing company and you need to build a system that will compile a product based on user input selections. In my example, I demo how you can build full package or a partial one. Ok, I do hardcode the selections (by specifying the classes myself) but you can obviously make this dynamic as well with reflection and what not.

That being said, that's just one of the many places where this pattern applies.

Enough from me, time to look at the code: It can, as always, be found here:
Presentation: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-8-structural-design-patterns
Code: https://github.com/SheepWorx/Training/tree/master/StructuralPatterns

</Meh>

Session 5 (technically 7) - Design Patterns: Creational Patterns

<Meh>

I'm already starting to slack on this whole blog business.. not a good sign.

Apologies to the 4 or 5 people that follow this blog. I've been completely inundated with work and haven't had the energy to do this in the evenings or over the weekends lately... but I got some strength again today, so here goes.

Creational Design Patterns.. for this I used the Gang Of Four Design Patterns site as my primary source of info.

So far we've been tackling the base principles that, I feel, every developer worth his salt, should know. Now we get to the practical implementation of those principles... design patterns.

Each design pattern solves a very specific pattern. I was always taught that it's not too important if you don't know all of the patterns... as long as you think in line of patterns. Meaning with each problem presented you ask the famous questions: "What can be reused? What can be extended? What should never change?" etc. That thought process will naturally lead you to some sort of pattern.

In this session we addressed the Factory Method and Abstract Factory pattern. Both patterns are very good evangelists of the Open/Closed principle, especially the Abstract Factory.

Anyways, have a read through the code and the presentation. They, as always, can be found here:
Presentation: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-7
Code: https://github.com/SheepWorx/Training/tree/master/FactoryPattern

</Meh>

Session 4 - Liskov's substitution Principle, Interface Segregation Principle and the Dependency Inversion Principle

<Meh>

In this session, I shared Liskov's substitution Principle, Interface Segregation Principle and the Dependency Inversion Principle.

The last two principles are very straight forward so I'll stick with the LSP for this entry.

This principle, although very simple, is sometimes extremely difficult to implement properly. It comprises both the OCP and the SRP and in most cases, is violated when using inheritance and is, again in most cases, solved by using composition.

It always starts with a great idea: why don't I create a base class that can encapsulate all the common functionality to everything that will inherit it. A noble idea, but sometimes very misguided.

What I've found is that if you're the kind of person who loves base classes and think that everything can be solved using base classes, you've most likely violated this principle in horrific ways. Why? Simply because inheritance is not always the answer. As simple as that. The LSP clearly shows when inheritance is not suitable to solve a particular problem.


One of the things that also makes this principle a tricky one is that it can be violated before it gets violated. One of the most important things when it comes to good code, is cohesion. How easy is it to understand the code. A good developer knows how to properly show his intent in the code that he writes. Now, in this case, the intent, not just the code, can be a violation of the principle. The trick is to identify when you're starting to go down a path that will eventually lead to violating the principle.

In order to identify whether your intent is true or not, I've reworked the original definition.
Orig: functions that use reference to base classes must be able to use objects of derived classes without knowing it.
My version: you must be able to apply the same code in a function, where that function references the base object as a parameter, to all super instances of that base class without having to make distinction between them

for ex: I have a base DAL class. I use this sucker to persist my entities to the database. Now, for new entities, I need to update the createdDate property and for existing entities, I need to update the updatedDate property. Now, following the original definition, this code is fine. Following my definition, it's not. Why? Because you're distinguishing between whether the entity is new or now.

Now, you may ask, surely that does not actually violate the rule.. and you're right. It doesn't... not yet in any case. Lets have a closer look at what we did. We introduced a business rule. A business rule into the base class. Is it starting to make more sense? What's the intention of the LSP? It's to keep your base class clean and less prone to change. Do you know what changes? Business rules.

The moment we start introducing business rules into our base class, we run the risk of making something that should be very stable, very brittle and when your base class is brittle, everything that implements it, is as well.

That, I feel, is the true intention of the LSP. To keep your base classes stable by removing everything that might cause it to change.

You can now see why the example violates the rule and also why it's sometimes so difficult to spot these violations. The sad thing is that for the most part, you won't spot the violation until its too late and you're sitting with a maintenance nightmare.


Anyways, enough of that. Below are the links to the various slides and what not

Presentations:
http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-4-liskov-substitution-principle
http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-5-interface-segregation-principle-34406317
http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-6-dependency-inversion

Code:
https://github.com/SheepWorx/Training/tree/master/LiskovSubstitutionPrinciple
https://github.com/SheepWorx/Training/tree/master/InterfaceSegregationPrinciple
[no code sample for DIP since we kinda covered it in the SRP. Refer to the 2. ExposingUtilsAntiPattern code sample there]

Next up we'll be tackling some design patterns, starting with the Factory Pattern (Abstract Factory and the Factory Method).

</Meh>