Asier's thoughts

Blogging about software development


Leave a comment

Clean Code Development: Orange Grade

Now that I have finished with the principles from the Red grade I can move on and start with the next grade of the clean code development: the Orange grade.

The principles are:

  • Single Level of Abstraction
  • Single Responsibility Principle
  • Separation of Concerns
  • Source Code Conventions

And the practices:

  • Issue Tracking
  • Automate Tests
  • Eager Reading
  • Code Reviews

I will go through each of the principles during the next weeks and jump to the next grade when finished. I will define the practices of each grade when I come back again in my next iteration through the grades.

+ info at clean-code-developer.com and here.

Advertisements


1 Comment

Favour composition over inheritance

The 4th principle from the red grade in the clean code development grade system says (from wikipedia):

Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behaviour and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

Inheritance is used in object-oriented programming as a way to reuse code through different objects.  We can define parent-children object structures, so methods an variables are passed from the parents to their children – the code is inherited. This is a powerful mechanism to avoid code replication – to be DRY-, but it has its drawbacks.

img73

The problem is that in a parent-children structure,  children are dependent of their parent. If a behaviour in a parent changes all its children’s behaviours will automatically change. Or if a new behaviour is added to the parent all the children will inherit that behaviour too. Sometimes this is not what we really want. Let’s see why.

I am going to use an example from the first chapter of the book head first design patterns.

head_first_design_pattern

In the example, the user wants to build an application which deals with different types of ducks. Every duck flies, swims, and quacks, so in order to reuse those behaviours a Duck super-type is created with the methods quack, swim and fly. Every duck in the system will inherit from the Duck class and therefore inherit those behaviours too.

intialDesign2_itwbm

The problem comes when a new type of duck is introduced into the system which is not supposed to fly: the RubberDuck. If we make this new type to inherit from Duck, we will make the rubber duck fly! That’s wrong.. But if we don’t use inheritance we will have to replicate the quack and swim methods! That’s not really DRY.. So what should we do??

The solution to this is to use composition for the code reuse instead of inheritance. Each of the behaviour that a duck could need -quack, swim, fly – will be separated into a new class –QuackBehaviour, SwimBehavour, FlyBehaviour. Then, each different duck type will use just the needed behaviours.

The code will look like this:

public abstract class Duck
{
 protected IFlyBehavior flyer;
 public virtual void DoFly()
 {
 this.flyer.Fly();
 }

}

public class MallarDuck
{
 public RubberDuck()
 {
 flybehaviour = new DoesntFlyBehaviour();
 }
}

public class RubberDuck
{
 public RubberDuck()
 {
 flybehaviour = new DoesntFlyBehaviour();
 }
}

public interface IFlyBehavior
{
 public void Fly();
}

public class FlyWtihWingsBehaviour: IFlyBehavior
{
 public void Fly()
 {
 // Flying coe
 }
}

public class DoesntFlyBehaviour: IFlyBehavior
{
 public void Fly()
 {
 // Do nothing
 }
}

The example in the book goes deeper and ends up using the Strategy Pattern. I recommend reading that first chapter and the rest of the book if interested. I quite like it, it does not just go about design patterns, but also about main oo principles and why these patterns exist. Also, the first chapter is free in amazon’s look inside or as a sample for the kindle!

In conclusion, inheritance it’s a good way of keeping our code clean and DRY, but it makes sub-classes coupled to their super-classes. Use composition instead  of inheritance if possible.

head_first_design_pattern - Copy

As it says in the book cover, do as Jim and cut down your inheritance!  😉

 

 


2 Comments

Beware of optimisation

In my short career as a developer I have heard many many times the word optimisation and I am already sick of it…

  • You have to optimise your code so it runs faster.
  • Do not use an ORM, just write SQL in your code. If  you use store procedures even better! You have to optimise!
  • We will add all of this extra attributes in our objects. We don’t need them right now, but we will do in the future. Is more effective doing it now that having to change the code in a later stage.
  • We need to create a caching system in our application so we optimise the times we access to the database.
  • etc.

At first you will think all of this is good. Why don’t we want to optimise? Optimisation is good, really. Makes our systems faster, better! Doesn’t it?

Well yes and no. We should be careful with optimisations, they add extra complexity to our systems, and we should aim for simplicity. Before optimising you should ask yourself: Do I really really really need that optimisation??

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

W.A. Wulf

If you want to optimise check first the benefit you will get from it.  You shouldn’t be optimising without measuring.  Use a profiler and measure it. Is it still worth it? If yes, go for it.

In my case, I try to avoid optimisation as much as possible, do that decision as late as possible. Don’t  worry, when you really need it, you will optimise!

Rules of Optimization by MA Jackson:

Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.


2 Comments

KISS – Keep It Simple Stupid

Second principle in the red grade, Keep it simple stupid or KISS.

From wikipedia:

The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided

Many times I have seen people overcomplicating things when it comes to software, as if complexity will make a system better. But it is just the opposite!

Complexity is the evil in software systems and ultimately a huge impediment in order to keep our code clean. We, as professional developers, have to avoid it at all cost. Keep everything as simple as possible. Build systems based in simplicity, with small classes and small methods, also avoid writing comments as much as possible – write a minimalistic code.

And don’t just focus in the code when it comes to the KISS principle. Do not add features to your software that you are not going to need, do the simplest work that could possibly work, design simple to use interfaces, beware of optimisationcreate the minimum documentation, and keep your processes simple following the agile/lean methodologies.

Simplistic software systems are easy to maintain, are easy to refactor and definitely easy to evolve. In this ever-changing world that we are living were markets, products, customers are changing constantly simplicity is a-must and a key to success.

As Leonardo Da Vinci once quoted and then became an Apple slogan in the 77

Simplicity is the ultimate sophistication

Also, as a personal advise do not embrace  simplicity just in software, embrace it in your everyday life! 🙂