Object oriented design
Patterns of Enterprise Application Architecture by Martin Fowler was not exactly as i imagined. First of all it was written in early 2000s and you can feel that it got a little bit outdated. Back in 2003 I am sure it was a really great source of patterns and best practices but from current perspective it may be a bit less relevant.
The book has some really good parts and I think every engineer would benefit from skimming through it. Way too often I see engineers with huge haps in important areas as concurrency, distributed systems, decoupling etc. I think there is still quite a lot of relevant knowledge in the book.
I have been thinking a bit recently how to manage dependencies and how to structure Zend Framework based applications to make the code less coupled, more testable and less dependent on the global scope.
I don't mean to be negative but I am not too happy about the web application structure that most articles and books present. In Zend Framework world controller seems to be the place when things get done. Controller is the workhorse and this is where all the logic seems to be buried. It also seems to me that model in MVC is reduced to database integration but there is no services layer for some reason. Where ever you look you will see the same examples with controller doing all the work and models being simple Zend_Db_Table or Zend_Db_Table_Row instances. You will not see business logic focused classes, Controller or DB Model, thats all you can choose from.
To make it short and clear, I liked the book a lot. From a very begining it is clear that author has a vast experience in software design and development.
There are a few bits that really stand out.
First of all I loved the chapter showin pair programming and minimal effort principles. It is really fun to read and shows some very interesting observations.
Well, i am not sure what to think of this book. It is a bit uneven as it is a composition of many separate articles written by different authors.
First chapter was really poor. A lot of talk but no real value. How many times do we have to hear that architecture and design are important? Entire chapter is a very vague and buzzword filled blob.
Second chapter was actually very entertaining but again also bringing little value. Author describes two systems he used to work on. He brings a list of factors that made them fail / succeed. I like the chapter as it seemed a bit funny and had some good points.
I have had this discussion like a dozen times already so I thought I could write it all down.
In many cases it is not that big deal. The problem is that people seem to be blind and ignore the fact that accessors can cause design issues. Its more about principles and overall rules. You wont get swine flu and die if you keep on using getters and setters. So don't panic! But your code may be cooler and more coherent if you stop for a minute and consider should they be there.
I have read this book but to be honest i had to skip a page from time to time. It is not an easy read. I am not sure if i would recommend it to anyone either.
The beginning of the book is quite ok, maybe first 100 or so pages. But then the disaster strikes. Chapters about J2EE, design patterns and EJB are really hard to read. I am not sure is it the buzz words density or maybe the examples and over abstracting everything? At the end it is not a good part of the book. I would also not recommnd that book for design patterns study, it does not explain things but makes then more difficult ;-)
Final chapters are a bit more readable again, Messaging and internationalisation chapters are quite ok. Especially messaging seemed interesting to me.
About the author
Hi, my name is Artur Ejsmont,
welcome to my blog. I am a passionate software engineer living in Sydney and working for Yahoo!
If you are into technology, you can order my book Web Scalability for Startup Engineers on Amazon. I would love to hear what are your thoughts so please feel free to drop me a line or leave a comment.