DEV Community: Elyess Eleuch

Clean Code

Elyess Eleuch — Sun, 14 Feb 2021 18:46:04 +0000

Photo by Scott Umstattd on Unsplash
Today I wanted to talk about clean code since we closed last week our SOLID series, I thought it would be perfect if I continued writing about clean code.

What is Clean Code?

Clean Code is Code that can be read and directly understood. Reading code that turns out to be what we expected before reading it -> Simple and "Boring" code.

The only photo that illustrates what I mean(in my opinion :p)

"Wtf metric should be zero"

And what a code does is encapsulated inside functions, one of the most important aspects of it, in my opinion.

But since we are talking about functions, I want to briefly explain why we write functions:

To decompose abstraction on so many levels and split the logic.

Function Rules:

1 - Small:

By small I mean that the function ideally shouldn’t exceed 10 lines, 20 in worst cases.

The code should be small so that we can easily understand the intent of the function by just reading it.

This is important especially when we are talking about big projects, where we have a lot of modules. In these projects, it is important to keep track of the logic and code in small easy to understand blocks, so that we don’t end up in total chaos.

Another Point, Smallness implies that blocks within if statements, else statements and while statements should be ideally one line long ( most probably a function call --> and it should document the intent ).

2 - A function should do one thing: and should do it well!

But what does one thing mean: if the code in the function is at the same level of abstraction
(A level of abstraction is just a metaphor used to hide the tiny details of a subsystem. For example: let's say we have a part of our system that creates a list and then increments its values by ten. Creating the list is a level of abstraction and incrementing the value is another level.)
then the function is doing one thing.

Or like uncle Bob says

"if we still can extract more from a function then that function is doing more than one thing".

In my words, if a function is reduced to the lowest then it’s doing one thing.

3 - We should use descriptive names:

If it’s easy for us to name a function, in a way that we can document its intent, then our function is most probably well-written and easy to understand. If it’s the other way round, then you should probably review the function that you wrote.
But sometimes, to document a function, its name can be too long, is that okay? Some people ask. Well, my answer to that is that before in the old days, people had to name functions using only 4 letters. That’s why I would say we should embrace the possibility that we can name our functions the way we want. Let’s avoid abbreviations.

"It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward."- Louis Sachar

and that is if I want to optimize time, and not spend on thinking about function names, this would only slow me down in the next days when I try to figure what the names that I wrote stand for.

4 - Not a long number of arguments, the more arguments the more complication:

Personally, I would put it like this. Deliver only the needed arguments. And if the arguments are not on the same level of abstraction then the function we're calling is doing more than one thing.
Let's say I have a car that consists of 4 wheels, 5 chairs and a Steering Wheel.
Let's suppose that our chairs are composed of springs.

Then a call to the function car like this is to avoid :

Car(wheel, chair, spring, steeringWheel)

because I would initialize two things (not at the same level) the car which is the higher level and the chair (lower level).

I would rather call that function like this :

Car(wheel, doneChair, steeringWheel)

Please notice that we didn't deliver something that is not necessary there and that would break another rule that we could have respected.

Some People say: If we pass a boolean to a function then we're clearly stating that this function is doing more than one thing.
But this is not always true. Because sometimes we're maybe calling two different functions or just passing different params.

5 - No side effects:

What is meant with side effects is not what most people say, it doesn't have to be something hidden or unexpected, it can be but it is not the definition.

A side effect is something changing somewhere else. In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment. And this type of functions ( with side effects ) are not testable, because they don’t have arguments to be tested.

What do I mean by that?

String carString = "Wheel Chair";  
char[ ] carArray;  
public void carArray () { 
carArray = carString.toCharArray(); 
}

Now can we test this method? If yes? What would we test? With which arguments? The method doesn’t return anything, doesn’t accept arguments...

public char[ ] carArray () { 
return carString.toCharArray(); 
}

This one looks way better.

Conclusion:

Like I always say, these are not rules that we have to stick to, and make us judge each other. Sometimes bad code (not clean code) is necessary to keep some minimum level of understandability.

Before caring about code we should care about each other. Do not refactor if that makes the code more difficult to understand.

Sources:

https://en.wikipedia.org/wiki/Side_effect_(computer_science)#:~:text=In%20computer%20science%2C%20an%20operation,the%20invoker%20of%20the%20operation.
https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29
“Clean Code”, Robert C. Martin

Revisiting the D in SOLID

Elyess Eleuch — Sun, 07 Feb 2021 10:29:29 +0000

Photo by Pavel Nekoranec on Unsplash
This is a continuation of the SOLID. In the last post, I covered the I and now we will be continuing with the last D. So if you didn't check the last post, feel free to click on the link: https://dev.to/sightlessdog/revisiting-the-s-in-solid-adg

Dependency Inversion Principle

The Dependency Inversion Principle is based on the Open/Closed Principle and the Liskov Substitution Principle. And it basically states that high-level modules shouldn't depend on low-level modules.
Simply put, never depend on anything concrete, only depend on abstractions, which never depend on details but the other way round, details depend on abstractions.

As you see in the picture, inversion doesn't mean that the low-level module now depends on the higher-level one. Because in conventional application architecture, low-level components are designed to be consumed by the higher-level components.

time for a simple example, right?

public class SteelWheel {
//properties and methods
}

public class Car {

public Car (SteelWheel wheel) { 

}
}

As we can see our car class is forced to depend on a concrete implementation of wheel. And what does our principle say?

Never depend on anything concrete, only depend on abstractions
We did violate our principle, right?

Well, you may be wondering right now, oh, the car class looks good, why should I care this much?.
Mmmm, good question, but imagine this with me. You would want one day to change your SteelWheels to AlloyWheels. What would you do the car class?
I hope that you are getting my point, if you change later the car class, you would violate the open/closed principle.
The car class shouldn't care about the wheel being used.

public interface Wheel {
}

public class SteelWheel implements Wheel {
//properties and methods
}

public class Car {

public Car (Wheel wheel) { 

}
}

And that's how the low-level module and the high-level one depend on the abstraction.

Conclusion

I hope that this series was helpful. Wish you a good day!

Sources

https://en.wikipedia.org/wiki/Dependency_inversion_principle
Robert C. Martin “Principles of OOD”
Meyer, B. (1997): Object-Oriented Software Construction, 2nd edition
http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf

Revisiting the I in SOLID

Elyess Eleuch — Sun, 31 Jan 2021 11:34:16 +0000

Photo by Pavel Nekoranec on Unsplash

This is a continuation of the SOLID. In the last post, I covered the L and now we will be continuing with the L. So if you didn't check the last post, feel free to click on the link: https://dev.to/sightlessdog/revisiting-the-l-in-solid-116m

Interface Segregation Principle

The Interface Segregation Principle was defined by Robert C. Martin several years ago while consulting for Xerox. He helped them change their printing system which was difficult to develop.

He defines it as :

No client should be forced to depend on methods it does not use.

In other words, Changing one method in a class shouldn't affect classes that don't depend on it.
Or we can say larger interfaces should be split into smaller ones.

Example:

Let's suppose 10 people work at a restaurant, our restaurantWorker class would look like this.

public interface RestaurantWorker {
void washDishes(); 
void cook();
void serve();
}

Out of the 10 people, there is this guy who doesn't know how to cook (he can only wash dishes or serve). Then the method cook() is not really relevant to him.

But sadly we have to implement the method cook() right?

To fix this, we would have to separate our interface into smaller ones

public interface Waiter {
void serve(); 
}

public interface Cook {
void cook(); 
}

public interface DishWasher {
void washDishes(); 
}

public class theGuyNoCook implements DishWasher, Waiter {
public void washDishes() {

}

public void serve() {

} 
}

And now, we are free to implement only the relevant methods.

Conclusion:

The ISP is intended to keep away the strong coupling between the different parts of the system. And that's what makes the code we are writing easier to change, refactor and redeploy.

Sources:

https://en.wikipedia.org/wiki/Interface_segregation_principle
Robert C. Martin “Principles of OOD”
Meyer, B. (1997): Object-Oriented Software Construction, 2nd edition
http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf

Revisiting the L in SOLID

Elyess Eleuch — Sun, 24 Jan 2021 12:37:36 +0000

Photo by Pavel Nekoranec on Unsplash

This is a continuation of the SOLID. In the last post, I covered the O and now we will be continuing with the L. So if you didn't check the last post, feel free to click on the link: https://dev.to/sightlessdog/revisiting-the-o-in-solid-4i84

Liskov substitution principle

Let z be a property provable about objects x of type T. Then z should be true for objects y of type S where S is a subtype of T.

In a nutshell: A has a property A, if B is a subtype of A then B has also the property A and B should behave the way A is expected to behave. And that means any derived class (B) should be able to substitute its parent class (A) without the consumer knowing it.

Example:

Let's suppose we have a car Class and two other classes Ferrari and Bugatti. Both of the cars are just..cars...sooo..they should behave like a normal car would do, right?

public class Car {
    public int speed;

    public Car(int speed) {
        this.speed = speed; 
    }
}

public class Bugatti extends Car {
    public Bugatti (int speed) {
        super(speed);
    }
}

public class Ferrari extends Car {
    public Ferrari (int speed) {
        super(speed);
    }
}

And now let's suppose we want to customize a car by increasing its speed, usually, we would write a method inside the Car like this:

   public void increaseSpeed(Car car) {
        String message = "You increased the speed of " + car.getClass().getSimpleName()  + " from " + car.speed;

        System.out.println(message);
    }

Please notice that increaseSpeed takes any car as a parameter.
We didn't have to implement this method in each class (Ferrari and Bugatti) because they should behave the superclass (car) would. No Complications. And that's the Liskov Substitute Pattern. We replaced the car argument with one of the subtypes each time, and nothing has changed.
Now let's check our results:

You increased the speed of Bugatti from 200
You increased the speed of Ferrari from 210

Conclusion:

The Liskov Substitution Principle extends the open/closed principle by preventing breaking client code.

Sources :

Meyer, B. (1997): Object-Oriented Software Construction, 2nd edition
http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf
Robert C. Martin “Principles of OOD”
https://en.wikipedia.org/wiki/Liskov_substitution_principle
https://www.youtube.com/watch?v=rtmFCcjEgEw
https://www.baeldung.com/solid-principles

Revisiting the O in SOLID

Elyess Eleuch — Sun, 17 Jan 2021 11:33:35 +0000

This is a continuation of the SOLID. In the last post, I covered the S and now we will be continuing with the O. So if you didn't check the last post, feel free to click on the link: https://dev.to/sightlessdog/revisiting-the-s-in-solid-150e

Open/Closed Principle:

“An entity should be open for extension, but closed for modification”

Bertrand Meyer,
OO Software Construction

Open for Extension: A module will be said to be open if it is still available for extension.

Closed for modification: This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding).

we can achieve that by using a pattern, where high-level modules don't know anything about low-level details. The code is not rigid because nothing would recompile if we add new things, and the code is not fragile because you cannot break the code or let’s say the architecture doesn't let you break things.

Let's use an example for this, everything would be easier to understand.
let's suppose we have a cone class that looks like this

And to make things more complicated, let's say we want to calculate it's volume, then the volume calculator class would look like this

Easy, right?

But wait for a second, there's another client who doesn't have a cone but has Cube and wants to calculate the volume.

An approach would be to do the logic in the calculator class

And as you can notice, this class (VolumeCalculator) isn't closed for modification. In order to extend it, we had to change it.

Now using the open/closed principle

We would at first define a high-level module like Shape

And then we would define our concrete shapes separately and by extending the abstract class.

And finally, our Volume Calculator would look like this

And that's how we opened our class for extension by closing it for modification.

Sources :

Meyer, B. (1997): Object-Oriented Software Construction, 2nd edition
http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf
Robert C. Martin “Principles of OOD”
https://www.youtube.com/watch?v=zHiWqnTWsn4&t=2707s
https://www.youtube.com/watch?v=rtmFCcjEgEw
https://www.baeldung.com/solid-principles

Revisiting The S in SOLID

Elyess Eleuch — Mon, 11 Jan 2021 21:09:32 +0000

to start with, this is how I understood it. If you want to add something to it, feel free to contact me. I would be happy :).

WHAT IS SOLID?

Single Responsibility (S)
Open/Closed (O)
Liskov Substitution (L)
Interface Segregation (I)
Dependency inversion (D)

SOLID principles were first defined by Robert C. Martin in his book Design Principles and Design Patterns. Then the acronym SOLID was introduced by Michael Feathers.

Martin’s and Feathers’ design principles encourage us to create more maintainable, understandable, and flexible software.
But today we will be talking about the Single Responsibility Principle.

The problem that they address :

The main problem that they tackle is working with legacy code.
But wait for a second, what is the problem with legacy code?

Here you go :

Re-reading code multiple times to get the part you need to change
Hard to understand what a method does *(Big giant methods that do everything ) *(or weird old names that do not refer to the logic of the method anymore)

With the legacy code, we spend more time reading than writing code

Simply:

It is most of the time bad code. And what leads to that?

The strategy that many of the startups adapt:

Constantly adding new features
No formal process
No time to worry about code structure ( daily releases, very dynamic)

And like uncle Bob says: Bad code slows us down, we want to be quick right, but not quick in a sloppy way.

A developer should behave like a surgeon, steady, confident but have the deadline in mind.

Single Responsibility Principle:

“A class should have one, and only one reason to change”

In other words, don’t put functions that change for different reasons in the same class.

We want to create small classes with very specific names that are responsible for only one thing.

Example: We have a car that has model, speed and interior components as properties.

Our class would look like this:

And let’s suppose we want to print out the properties:

Notice here we don’t want to declare the printer methods inside the car class, but that would violate our principle.

The Car class shouldn’t change because we want to output the text to some domain.com but only because the properties of the car changed.

Benefits: Easier Testing, fewer dependencies

Sources :

Meyer, B. (1997): Object-Oriented Software Construction, 2nd edition
http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf
Robert C. Martin “Principles of OOD”
https://www.youtube.com/watch?v=zHiWqnTWsn4&t=2707s
https://www.youtube.com/watch?v=rtmFCcjEgEw
https://www.baeldung.com/solid-principles