For what its worth, here are the books I have read the first half of this year and my humble opinions on their content.

  • Object Models: Strategies, Patterns, and Applications
  • Manage It!
  • Object-Oriented Program Design: With Examples in C++
  • Prefactoring: Extreme Abstraction, Extreme Separation, and Extreme Readability
  • Building Object Applications that Work

Object Models: Strategies, Patterns, and Applications

Peter Coad

I was not planning to read this old book until I noticed its structure. The book is made up of a bunch of examples of domains and the models and thinking behind those models to represent each one. Pretty cool. It also starts off with some quotes reflecting this idea. E.G. Latin Proverb: The example educates. And another anonymous line: Educate right at the moment someone can apply it with success.

I love those two lines.

This is an older book and as can be imagined had no earth shattering realizations for me. However, when I read an older book on a topic I am very familiar with I am often just looking for a new slant on things or a hidden gem. In the end the 148 strategies listed for helping developers design a domain model may prove useful when stuck.

My favorite points from the book are:

  • Data maintenance is high in volume low in content and pretty uninteresting. His point was to separate maintenance and business and to not bother writing use cases or scenarios for this stuff.
  • Create a walk-able object model
  • Don’t automate things just because you can

My least favorite points from the book are:

  • Author’s model designs had highly mutable business objects
  • Author does not objectify collections

Manage It!

By Johanna Rothman

Manage it is a solid project management book that I intend to use as a reference book when I have to manage a project that is in a different environment that I am in now. The author points out many drivers and constraints on a project and how we deal with them.

My favorite points from the book are:

  • Don’t be afraid to create a project lifecycle specifically for your situation.
  • Like any good book suggesting an agile approach the author stresses constant feed back through the entire process.

Prefactoring: Extreme Abstraction, extreme separation, and extreme readability

Ken Pugh

The book walks through the process of designing and implementing a CD rental system with an imaginary client. We get to read the author’s line of thinking as decisions are made. Often the reasons for the decisions tie into a development guideline that the author reproduces in an appendix in the back of the book. There is nothing too groundbreaking in the guidelines; however I don’t think I wholeheartedly disagreed with any of them. The idea behind prefactoring is that there are certain guidelines you follow to keep you from having to refactor later.  Some were even favorites that I like to advocate like: don’t describe data with primitive data types, user the client’s language in code, separate policy and implementation, etc.

 

I would recommend this book to younger developers who have not done anything or very little with object designs. I think most developers who have already spent a few years trying to adapt object-oriented concepts to their business applications will have already developed their own matching list of guidelines.

 

Object-Oriented Program Design: With Examples in C++

 Mark Mullin

Because I just can’t seem to read enough OOP books.

Not necessarily recommended unless you are a geek like me who can’t seem to get enough different views on OO programming, or possibly if you are an old school C programmer who never moved to C++.

Most interesting point was that the author objectified subsystems. It looked odd at first, but I soon realized that his subsystems were my application services. The author’s Database object would essentially be the combination of factories and a data access layer.

 

Building Object Applications that Work

Scott Ambler

This half year I have read 5 books, 3 of which had to do with OO development. I have to ask myself why I keep reading OO books.  I am not so naïve as to be looking for a silver bullet OO technique, and none of the past 3 or 4 OO books have shifted my way of thinking. So, I guess I am still trying to formulate and document my own personal best-approach to OO development and the common business application. I am not sure I am completely satisfied with my approach and not sure I fully understand other’s approaches. However, this book has been on my wish list for awhile and a cheap user version finally showed up on Amazon.

Like many older OO books it stressed all the same things that have been repackaged lately with new cool names: iterative development (Agile), on going testing (TDD), user and business language (Domain Driven Design), etc.

My absolute favorite line out of the book it one that I have never articulated as clear as this book. Many developers are out there right now creating tomorrow’s legacy applications.  Amen. The reason I read so much and write so much about what I read and thoroughly think through my design choices is because I don’t want to be writing tomorrow’s legacy application. In 5 years I don’t want another developer looking at my code to decide to just start from scratch. Rather I want them to be able to easily maintain and extend my application.  Even if it means rewriting just a component, layer or even tier. But what I think is most common are developers just starting over.