Clean Code - Review Part I
As I have twittered already, I am reading “Clean Code” by Robert C. Martin right now. I expected the book to be a very fundamental one. Although there are a few parts I do not entirely agree with, I just rummaged throught chapter 11 “Systems” on my way home and was surprised how condensed Robert summarizes principles constructing software systems that I usually promote discussing such topics with colleagues.
1. Separate constructing a system frum using it
Detractors of the Spring framework very often claim, configuring a system construction using XML sucks because of lacking type safety et cetera. I don’t want to get into discussion do detailed, but Spring’s way of describing system construction is not tied to XML at all (see Spring JavaConfig). For Robert the startup process of an application actually a concern. A view I kinda like as such, as you then can easily argument in terms of Separation of Concerns as well as the Single Responsibility Principle.
2. Dependency Injection
DI is widely accepted these days, besides the myth that you always need a fully fledged container to use DI in your application. Robert shows some nice examples and points out that the conceptual idea is much more important that the tool you use.
3. Cross cutting concerns / AOP
Systems usually face logic that - coded in plain OO - is tangled though all the codebase. Adressing these issues with AOP leads to much more concise and extendable systems. Robert presents the concept from a very high level point of view and briefly introduces various AOP implementations, advising simple proxy based solutions like Spring AOP or JBoss AOP as suffient for most cases.
4. Incremental design
Robert emphasizes the importance of natural growth of designs. Big upfront designs often appear to be overengineered and too technical that does not abstract business domain on an appropriate level. Which leads us to…
5. Domain specific languages
I also don’t want to open this pandora’s box but clearly second the opinion that you have to find abstractions that are clean, simple and thightly wrapped around the domain to deal with, whether is a technical domain.
Summary
Robert boils down the chapter to the following paragraph:
An optimal system architecture consists of modualrized domains of concern, each of which is implemented with Plain Old Java Objects (or other) objects. The different domains are integrated together with minimally invasive Aspects or Aspect-like tools. This architecture can be test-driven, just like code.
I really just scratch the surface of what the chapter actually covers, but even this single chapter boils the topic down to its essences quite well. Nice to see all these concepts, priciples and attitudes distilled in a few pages.
If you like, check out the book @ Amazon.
