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>

Session 3 - The Open/Closed Principle

<Meh>

In this session, we look at the second SOLID principle, the Open/Closed Principle (OCP).

I always couple this and the SRP (Single Responsibility Principle) together because in most cases, you can't implement the one without other.

There's not much I can say that I didn't already say in the previous post. I've always felt the the SRP is driven by the OCP and depending on what the future of a class might look like, you'll apply the OCP and SRP accordingly.

I always make a point of showing my design to the resident architect (if I'm not in charge of architecture of a solution). The architects in the enterprise product space tend to know the next four to five steps for a particular system, product or department. It's important that when you create/refactor code to adhere to the OCP, that you you take that into consideration.

Most interesting thing about this session for me was the two different approaches to inheritance for OCP between Bertrand Meyer and Robert C Martin. Martin's is again very purest and in my humble opinion, the better approach. But you cannot deny the merit of Meyer's approach. It's very practical especially when you need to extend product code that was never designed to be extended.

We also take a quick look at C# 3.0's Extension Methods. It also is very handy when you need to introduce new methods to classes that weren't designed to be extended. Although with that and Meyer's approach, code management might be come an issue if the changes aren't implemented properly.

With OCP, like with any other principle, there are various risks when implementing it. The main risk that comes to mind is code coupling. With composition (using interfaces: http://en.wikipedia.org/wiki/Composition_over_inheritance), you get very good decoupling of code. With class inheritance, your classes are tightly coupled and testing individual classes becomes more difficult. This is again one of the many factors that need to be weighed when designing new code or extending existing code.

For this session, you can find the various stuff here:
Presentation: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-3-openclosed-principle
Code: https://github.com/sheepworx/training

Next up is Liskov's Substitution Principle

</Meh>

Session 2 - The Single Responsibility Principle

<Meh>

In this session, we'll be tackling the first of the 5 SOLID principles. Where I expected everybody to know the OO principles (Inheritance, Polymorphism, Encapsulation, Abstarction and Decoupling) that we discussed in the previous session, I'm pretty sure this will be new for most guys.

I only got to learn about SOLID about 6 or so years ago and it has drastically transformed the way I look at code and how I approach my code design. I feel that every developer should at the very least know SOLID. It's the core principles that most patterns are based on today and even if you don't know any patterns, if you've got SOLID under the belt, patterns will emerge naturally.


I found it particularly difficult to prepare for this session. Out of all the principles in SOLID, the SRP (Single Responsibility Principle) is the one that is most debated. Some find Robert C Martin's definition of it a bit too strict and I tend to agree with those people.

Part of code maintainability, along with things like loosely coupled code, reusable components, etc, is code cohesion. If your code is not easy to read and easy to follow or debug, then you've not accomplished much. Just as much time may be wasted trying to figure your code out than making redundant fixes. Ok yes, there are other things that you can do to "improve" cohesion, like proper use of namespaces, to mention one. Code comments is also a solution but lets be honest... code itself must be readable. If I'm going to have to read comments every time I need to tackle something, then it will take me ages to debug the code.

Putting that and things like proper variable naming aside, the only real way to make your code highly cohesive, is to refactor it to such an extent that it all still makes contextual sense. This is the general argument against uncle Bob's definition of the SRP. Instead of being technically pure, focus more on the context of the actual object.

You still want to follow DRY (Don't Repeat Yourself) but having a class violate the SRP by having multiple responsibilities for the sake of context is not the end of the world, I feel. It also depends on what those responsibilities are of course.

Anyways, the SRP for me is one of the most important and misunderstood principles. Your code can very easily turn into a maintenance nightmare if this principle is not implemented correctly. I always couple the SRP along with the OCP (Open/Closed Principle - will discuss this in our next session) because of the question that always pops up when I'm thinking of how far to take refactoring: What do I need to open for extension and what can I close for changes? That always guides how far I take something with the SRP. For ex, if you're writing a component that will never ever get reused and it makes to contextually keep everything together in one class, then I'll just make sure that everything is readable and logically separated enough for the key components to be testable, but that's it. Won't take it any further.

Knowing how far to take refactoring is the different between coding efficiently and running into recursive analysis cycles.

So, for those that have never dealt with the SRP, it's gonna be a little bit of a mind bend, but if you stick to the basics, you should be fine. And of course, practice practice practice.


Important things to consider when refactoring:
-refactor small bits at a time
-if you can't test the code, you've most likely sitting with a bad design

For this session, you can find the various stuff here:
Presentation: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-2-single-responsible-principle
Code: https://github.com/sheepworx/training


Let me know what you think

</Meh>

Session 1 - Introduction to Object-Orientation

<Meh>

I tried to keep this session as basic as possible so you'll have to excuse the stupid code examples. My audience is also a mixture of senior and junior devs although, I expect everybody that's attending the sessions, to at least know this already. This is merely a "recap".

Slideshow: http://www.slideshare.net/DeonMeyer/code-like-a-ninja-session-1-objectoriented-principles
Code Samples: https://github.com/SheepWorx/Training


The question when it comes to OO and refactoring/designing of code has always been... "How far do I take it?". Refactoring is good, but as the saying goes, too much of a good thing, even OO, can be a bad thing.

There will always be risks or concerns that will be allowed due to the usual constraints: time and money.

A good guide is usually anticipating the growth of the business. If you can anticipate what is most likely to change in the near future, then that should give you a good idea of how far to refactor something. Performance is also a good guide. OO is nice and all, but it can introduce a fairly complicated structure in your code and introduce a lot more overhead and instructions. What will you sacrifice more? Performance or maintainability?

For me, the GoF (Gang of Four) patterns are a good start. Industry standard design patterns in general are nice because they're a tried and tested method of solving a particular problem, while ensuring the code is loosely coupled, maintainable, testable, etc. I've always been taught that patterns come and go and yes, there is merit in knowing a few, but in the end it's not knowing the patterns, but thinking in terms of building patterns that matter.

Technologies change constantly, languages change and with that, patterns will change as well. If you can practice building your own patterns, I feel that skill is much more valuable than memorizing a few.

Anyways, I'm getting ahead of myself. This session is just about the basics. Next up after this will be the first of the 5 SOLID principles: The Single Responsibility Principle.

</Meh>

Intro[DUCK]tion

<meh>

I'm a software guy (have been a dev for about 11 years now). I love coding, I love designing software but above all, I love teaching... whenever I can (not sure if I'm any good at it, but I enjoy it nonetheless). I recently became a scrum master and as such, I felt responsible for skilling up my team (which consists of devs, testers, BA's and SA's). With that in mind, I recently started WTF (what the fudge) sessions with them.

I've been gathering and presenting sessions every now and then for the past 5 years now and I decided it's about time I start to put everything together on a blog somewhere.

This blog is it.

The next few posts (over the next 2 months) will be around Object-Orientation: Design Principles and Patterns. I'm presenting these session at my office so as I get finish them one by one, I'll upload the presentations here. I'll be storing my code and presentations on GitHub, so make sure you have an account.

</meh>