Book Review: Clean Code: Chapter 11. Systems

 Technology  1 Response »
Apr 082009
 

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

In this chapter we go higher up and look at the software as a system- in whole. Just like clean code is important – so is the cleanliness of the system

In this chapter, Robert talks about Separation of concerns,  Dependency Injection and Cross cutting concerns.He also draws contrast between the EJB architecture (EJB1 to EJB3) and  Spring.

The biggest strength of Spring is- that when you never code for Spring. Spring adopts you rather than you adopting Spring.

AOP and AspectJ are also discussed along with Java Proxies. There are pretty powerful mechanisms to implement separation of concerns.

Its infeasible to design the whole system upfront. What works is small steps- keep room for improvement as things grow.

Robert concludes this chapter with a very sagely advice-

Use the simplest thing that can possibly work

For review of other chapters- please see this post.

 Posted by Rajiv Narula at 8:26 pm  Tagged with: , ,

Book Review: Clean Code: Chapter 10. Classes

 Technology  1 Response »
Apr 032009
 

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.

 Posted by Rajiv Narula at 5:05 pm  Tagged with: , ,
 Newer Entries
© 2011 Technology Cafe Suffusion theme by Sayontan Sinha