Technology Cafe

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

Boundaries are the points when your code meets with code written by others- where you have little control on what they deliver. e.g. when you use a third party software like PCMiler for distance time lookups.

It’s good to buffer these boundaries with Adapters so that your dependency on third party software isn’t widespread and when the third party software changes- you have one place to go and make the change.

Robert also talks about “Learning Tests”- these are special tests written to test the third-party software. They can be used to validate later releases.

Also boundaries are not limited to third-party software – they can also refer to sub-components developed by an independent and a separate team.

For reviews of other chapters- please see this post.

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

In this chapter, Robert points out the important difference between Objects and Data Structures. Former are classes with expose a well defined behaviour- hiding the data, while the latter are all about data and have no behavior to offer.

Data abstraction is simply not about making all the members private and provide access to them via public setter\getter. This doesn’t hide the data . It simply exposes the data via the setter\getters !!!

This is perhaps the most misunderstood concept behind OOP. For eons- people have related encapsulation to simply making all members as private . No sir. It takes more than that.

Interaction between objects should be a series of commmands- each asking the other to do something. Kind of “Tell. Don’t Ask” . By asking for – you are basically asking the other class to expose it’s internals to you.

It also increases the chatiness between classes.

For review of other chapters- please see this post.