Technology Cafe

This is review of the 12th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

You don’t design good software. A good design emerges by itself…
This chapter re-iterates Kent Beck’s four rules of simple design

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

Having  good set of test cases is of utmost importance. Once you have a reliable set of test cases- you can fearlessly bring changes to the application. because you know that you can test what you are changing

Most software erodes by the plain fear of unknown impact of such changes. And once you have test cases- this fear goes away or at least diminishes…

The last rule mentioned is to minimize number of classes and methods. Ina way this is in contrast to SRP which advocates a separate class for every responsibility. But its also essential to keep in mind a necessity to keep number of classes and methods low.  Dogmas like- every class to be accompanied with an interface – should be rejected . Have interface whenever needed and maybe often. But a rule saying every class must have an interface is totally unreasonable.

For review of other chapters- please see this post.

This is review of the 10th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin

In this chapter- we now move on to bigger blocks- Classes

Robert goes through the design principles behind classes. Mostly the SOLID principles he advocates in many of his works.

Single Responsibility Principle
Open Closed Principle
Greater cohesion between classes
Dependency Inversion Principle.

The most important message was- be ready for change. Software is ever evolving. And so do all the blocks of your software
If you see a class- loosing cohesion- maybe it’s the time to break it into smaller components.
You observe a class is getting modified for newer features again and again- maybe you need to redesign it to open it for extensions.

You don’t have to get the whole picture right – from the beginning. The important part is to understand when is tge time to refactor your units of software

By programming against abstractions- you avoid a close binding with implementations- making it easier for newer changes to be brought in

For review of other chapters- please see this post.