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>