The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
The Pragmatic Craftsman
:: Simplicity from complexity : by Stanley Kubasek ::
Excellent article about SOA. The article should be called Pragmatic SOA 101 — hype free.
ResourceSOA best practices (need an IBM account), Mark Lorenz
Design Patterns (GoF)
by Ralph Johnson, Richard Helm, Erich Gamma, John Vlissides
ISBN 0201633612
Date Read 10/2006
My Rating
A classic.
I have read several books on patterns. This is the best. You’ll get sound design principles as well. You will become a better designer if you read this book. If you can finish it — you might want to take it slow…
This is not an easy book. I had tried reading it couple times but could never finish it. It was boring to me. I was getting distracted by the C++ code that this book has as sample code. But now, after finally reading it from start to finish, I can see that this book has great value.
This book is the definite guide to the most important patterns, the GoF patterns. These guys invented — or first reported — these patterns. Other books, which claim to simplify them and make them easier to remember (ie. Head First Design Patterns), don’t come close to this book. Some of them are helpful, though, and you might want to start with them before you read this book — learning patterns is hard.
There are several approaches in how you can read this book. The authors say you can just select a pattern you are interested in and just read it. I think the best way to read this book is to start with the indroductory chapter, which contains a lot of great advice on design in general; get to know the patterns referenced in these chapters; and then read one of the three major sections: creational, structural, or behavioral. The author refer to patterns in each section, so I think it’s good to read the whole section. It is also good to have other examples of the patterns to look at — you can find many by searching the web.
The GoF patterns are the most important and most widely used patterns. Every architect/senior developer needs to know them. This book is a must have.
Adding new responsibilities to a class is a fairly common thing in coding. We do that when we get a request from a business person. We do that also when we refactor parts of a project. It’s an everyday activity you can say.
But here’s a question? How do you determine where to put the responsibility? What is the best place?
By the Information Expert pattern, you should add it to the class that has the information. It’s almost like in real life, you ask people that have the necessary tools and knowledge to do a job.
What is the Information Expert pattern? It is discussed in Applying UML and Patterns book. It is part of the GRASP patterns, which describe fundamental principles of object design and responsibility assignment. We hear a lot about GoF patterns but, in my opinion, not enough about GRASP patterns.
This pattern is simple and results in objects that do things related to the information they have.
However, if you applied this pattern everywhere, you would end up with a class that knows how to load its information, persist to db, etc. That’s not good. You are violating a lot of patterns by doing that (high coupling, low cohesion, too many responsibilities, and many more). Or, as author says, you are violating “basic architectural principle: design for a seperation of major system concerns. Keep application logic in one place (such as the domain software objects), keep database logic in another place (such as a seperate persistence services sybsystem), and so forth.”
What major benefits does the Information Expert give you?
“Information encapsulation is maintained, since objects use their own information to fulfill tasks. This usually supports low coupling, which leads to more robust and maintanable systems.”
“Behavior is distributed across the classes that have the required information, thus encouraging more cohesive ‘lighweight’ class definitions that are easier to understand and maintain. High cohesion is usually supported.”
So next time you are asking somebody to do something for you, see if he has the required information. If not, find somebody else that does. You want the job done well, right? Use an Information Expert for such a job. 
ReferenceApplying UML and Patterns by Craig Larman, p221
It’s one of my favorite and most-referred to books. It’s one of 10 Books Every Java Software Engineer Must Own.
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal
ISBN 0471958697
Date Read 9/2006
My Rating
This is one of the best design patterns books. I am not the only person that’s saying that. Check out Amazon.com reviews, check out recomendations from Martin Fowler. If you’re into architecture, this is a must read. (As a side benefit, you’ll enjoy reading it.)
By reading this book, you’ll not only gain design patterns knowledge, you’ll get an excellent discussion about architecture in general, and a great OO design discussion.
This book is broken up into eight different sections. The three sections that I enjoyed the most (major part of the book) are architectural patterns, design patterns, and patterns and software architecture discussion.
In the architecture patterns section, the authors have an excellent discussion about the Layers pattern, the Broker pattern, MVC, and Presentation Abstraction Control. I especially enjoyed the Layers and the Broker pattern. (My understanding of the Layers pattern was a little different before reading this book.)
In the design section, I found the following especially valuable Whole-Part, Master-Slave, Forwarder-Receiver, and Client-Dispatcher.
The discussion about software architecture in general and about object-oriented design in chapter 6 is one of the best. It’s always good to refresh your mind how your project should be structured, the qualities it should have. Always valuable.
This is a must read if you’re into architecture and design. You will become better at it by reading (and implementing) the patterns cointained in this book. One of my most valuable books.
How have things changed in a matter of a year or two. That’s music to my ears, , but these things change quickly. I do believe, however, that as software engineers we have a bright future ahead of us.
According to the latest U.S. government statistics, the future of the IT job market looks bright. As the U.S. Bureau of Labor Statistics points out, five of the top ten fastest growing jobs between 2004 and 2014 will be within the technology industry. In some cases, these jobs are growing at a pace of 40-55% over the next ten years, clearly outpacing the growth of jobs in other industries. The five fastest-growing IT jobs include: network systems and data communications analyst, computer applications software engineer, computer systems software engineer, network and computer systems administrator, and database administrator.…fast growing IT job is computer applications software engineer, which has an expected growth rate of 48.4% over the next ten years. Firms of all sizes will require the services of developers who can write and customize software in response to constantly changing consumer and industrial needs.
I’ve been inthe dark as far as the Decorator pattern is concerned. I knew, inprinciple, how it works, but I can see that my understanding was veryincomplete. Plus, I never had a chance to useit. While reading the Head First Design Patternsbook, Idiscovered something basic that: when you wrap an object several timesand then call a method on it, it will be called as many times as it waswrapped. The trick? Keepa reference to the object — you’re creating a chain.
<font
Let me gothrough this step by step. By example. This is thebook’s example, the Starbuzz Coffee decorator.
<font
A simpleinterface.
<fontpublic interfaceBeverage {
<fontpublic String getDescription();
<fontpublic BigDecimal getCost();
<font}
We have severalcoffee types, Dark Roast being one of them.
<fontpublic classDarkRoast implementsBeverage {
<font public BigDecimal getCost() {
<font return newBigDecimal(“1.55″);
<font }
<font public String getDescription() {
<font return“Dark Roast”;
<font }
<font}
When orderingcoffee, you can pick a coffee type (Dark Roast, Latte, etc), and youcan also add on to the coffee. For instance, you can add a whip creamon top, or add a shot of expresso to it. Which, of course, adds to theprice. You could extend Beverage with all of the types, but that’s toomany classes. Here’swhere the decorator pattern comes into play.
Here’sthe solution. You define the AddOnDecorator and extend it with thedifferent add ons.
<font/** It’sjust an empty class */
<fontpublic abstractclassAddOnDecorator implementsBeverage { }
<font
<fontpublic classExpresso extendsAddOnDecorator {
<fontBeveragebeverage;
<fontpublic Expresso(Beverage beverage) {
<font this.beverage =beverage;
<font}
<fontpublic BigDecimal getCost() {
<font return newBigDecimal(“0.25″).add(beverage.getCost());
<font}
<fontpublic String getDescription() {
<font return beverage.getDescription()+ “, with Expresso”;
<font }
}
<font
<fontpublic classWhip extendsAddOnDecorator {
<fontBeveragebeverage;
<fontpublic Whip(Beverage beverage) {
<fontthis.beverage =beverage;
<font }
<fontpublic BigDecimal getCost() {
<fontreturn newBigDecimal(“0.10″).add(beverage.getCost());
<font }
<fontpublic String getDescription() {
<fontreturn beverage.getDescription()+ “, Whipped”;
<font}
<font}
<font
<fontpublic classStarbuzzCoffee {
<fontpublic staticvoidmain(String[] args) {
<fontBeveragedarkRoast = newDarkRoast();
<fontdarkRoast= newExpresso(darkRoast);
<fontdarkRoast= newWhip(darkRoast);
<fontSystem.out.println(darkRoast.getDescription()+ ” costs “
<font+darkRoast.getCost());
<font}
<font}
WhenI first looked at the code, I was confused. I thought that newWhip(…) would just override it,right?
Thisis what gets printed: Dark Roast, with Expresso, Whippedcosts 1.90
You get the beverage you want(DarkRoast), you pass it to the Expresso wrapper, which in turn passesit to the Whip wrapper.
Firstthe Expressowrapper is called, itreceives the dark roast beverage. Then the dark roast is passed againto the Whip wrapper. If you look closely (and this isa little confusing), when an Expresso is instantiated, it receives the beverage andmakes a local copy (so it is never lost). Essentially, a chain is made.When the action on the final object is made, the chain is traversed andthe beverage object is passed around. That’s how this patternworks. (Wow, I learn something (basic) every day. )
The Decoratorpattern is cool. It rocks. It lets you keep adding functionality and still keep the objectscohesive (as you’re not bloating the objects). No coupling as well.Nice.
Reference
Head First Design Patterns, the example above was taken from the book
Great dose of advise. Hundred one points, to be exact.
ReferenceLessons from Project Management: 101 ways to organize your life, Project Management Source blog
I hesitated posting this… The last thing I want is more red tape. However, after reading about code reviews in several sources, I am convinced that the reward is worth the price. The bottom line, code reviews improve code quality. While no silver bullet, they force us to write better code — knowing that somebody else will evaluate it makes us do it.
I have never been part of a company where code reviews worked effectively, but at the same time, if implemented properly into the development process, they have the potential to improve the quality code in a significant way.
What’s more, they enable cross-training programmers, mentoring, and enforcement of code conventions. Code reviews allow us to make sure that new people are “adopting” to “our” way of doing things, if there are any. They’re the extra guard to protect the most-valued property: code.
A lot of the prominent IT gurus, like Grady Booch, Jerry Weinberg, Cedric Otaku (those are sitting on top of my mind now), are big proponents of code reivews. I believe Weigers even wrote a book on the subject.
What prompted me to write this is an excellent blog entry by Cedric Beaust, Why Code Reviews Are Good For You, http://beust.com/weblog/archives/000393.html. He explains why it’s good and the different types of reviews. The following sums it up nicely:
“I strongly believe that projects that work without any peer review will end up with code of significantly worse quality, regardless of how talented or experienced the developers are. It doesn’t matter how good you are, you can’t produce top quality code all the time. We all get sloppy at time, and code reviews are here to address these times.”
I think we should consider implementing non-blocking code reviews. Let’s be honest, we all check in code that is sometimes sloppy, we could all use a little incentive to do better, and a lot of times we write code that only we can understand. Code reviews would be an improvement in this area.
How do we implement it? Good question. I believe that there should be some communication system in place. But the bottom line, each line of code should be looked at by somebody else and suggestions how to make it better should be requested of each reviewer (no heart feelings).
At my current job we have JIRA and SVN integrated, doing code reviews would be simple. Every SVN check in has to have a ticket ID. Before a ticket can be closed and the project released, every change has to be reviewed by somebody else and commented on. Before it can be closed, the reviewer would have to approve that the changes have actually been implemented.
We all strive to write good quality code whether we do code reviews or not, but it does not always happen. Knowing that our code would be reviewed would force us to do it every time.
ReferenceWhy Code Reviews Are Good For You, Cedric Otaku
RelatedCode Reviews, very good java.net article
Patterns of Enterprise Application Architecture
by Martin Fowler
ISBN 0321127420
Date Read 8/2006
My Rating
Excellent patterns book. Written in a pragmatic language.
Fowler talks about patterns that relate to domain logic, remote services, data source and more. Even though you probably heard a lot of the patterns discussed in this book (if you’ve been following patterns), you will learn from this book.
Fowler presents the patterns in an interesting way. He tells you how he used it, what worked and did not work for him. He gives you a lot of insight, which in the pattern world, is very important I think as it gives you the context you can use the pattern. It’s good to see what problems he went through, the issues with the potential solution. This book gives you exactly that.
The book has two sections, the first, around 100 pages, is where he discusses the patterns and tells you when to use it. The section about layering the architecture is excellent. The overall section is quick to read. After reading this section, you basically read the whole book.
The second section is the pattern reference where all of the patterns are listed.
The best thing in the book is the author’s pragmatic language and very good, simple examples
This is an important book in my architecture/design library. I plan to re-read this book every year or so, in addition to having it on a side as a reference.
Programming Pearls
by Jon Bentley
ISBN 0201657880
Date Read 7/2006
My Rating
This is an important book, no doubt about that. For me, however, this was not an easy read. I never got into the book. Maybe my approach was wrong, maybe if the examples were written in a different language than C, maybe… I don’t know.
What I liked about the book is the principles that usually followed at the end of chapters. Those had the most value for me and those alone are worth reading the book.
Why do others give this book such a high rating? I think the real benefit is in trying to actually do the problems at the end of each chapter. I did not do them (and thus I probably did not gain too much out of it). Personally, I think they’re a little bit too low level. They’re very good if you’re trying to learn data structures and algorithms.
