Clean Code Made Simple - Part 2

Further to my last post Clean Code Made Simple - Part 1, in this post I'm going to continue introducing techniques from Robert C. Martin’s Clean Code book.

#6 Hiding Data

Which one of below code snippets do you think is better designed?

1)

interface Vehicle {
    public function getFuelTankCapacityInGallons();
    public function getGallonsOfGasoline();
}

2)

interface Vehicle {
    public function getPercentFuelRemaining();
}

In both of the above cases the second option is preferable. We do not want to expose the details of our data as much as possible. Rather we want to express our data in abstract terms. Serious thought needs to be put into the best way to represent the data that an object contains. The worst option is to blithely add getters and setters.

So in any situation where it's suitable to hide the data of an object, You may do it.

#7 Simple Design Rules

Kent Beck introduced these 4 rules as basic criteria to design programs better:

• Runs all the tests
• Contains no duplication
• Expresses the intent of the programmer
• Minimizes the number of classes and methods

In an effort to make our classes and methods small, we might create too many tiny classes and methods. we should also keep our function and class counts low. this is the forth rule of simple design rules by kent which is more important than other ones.

#8 Intention Revealing Functions

how do you think this code snippet can get better ?

public function getFlaggedCells() {

    $flaggedCells = new List();

    foreach ($cells as $cell) {
        if ($cell[STATUS_VALUE] == 1) {
            $flaggedCells->add($cell);
        }
    }

    return $flaggedCells;
}

We can write an intention-revealing function (call it isFlagged) to hide the magic numbers. It results in a new version of the function:

public function getFlaggedCells() {

    $flaggedCells = new List();

    foreach ($cells as $cell) {
        if ($cell->isFlagged())
            $flaggedCells->add($cell);

    return $flaggedCells;
}

#9 Writing Tests Leads to Better Designs

Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed. Fortunately, making our systems testable pushes us toward a design where our classes are small and single purpose. Writing tests leads to better designs.

#10 Separation of Concerns

What would you recommend the direction of arrows should be, to separate construction from use ?

Main             Application



Builder

Directions should be as follow:

            run
  Main  --------->  Application
   |
   | build and construct
  \|/
Builder

It simply means that the construction of our application should be separate from using it. These two steps are fundamentally separate and decoupling them gives us a better design and structure.

Okay. This is it for this part. You can join my Telegram channel to get notified of the latest posts. Also, you can follow me on Twitter and LinkedIn.