Yes, design patterns are!

Lately they seems to be some kind of critique of design patterns (like singletonitis, even a discussion in comp.object). I agree that's some pattern abuse is occurring.

I just read Cedric's defense of design patterns

Mainly about this presentation from M. J. Dominus ”Design Patterns aren't” (http://perl.plover.com/yak/design/samples/slide001.html).

I believe that Dominus's presentation (or the title) misses the purpose of the GoF design patterns. They are object oriented design patterns and Alexander's patterns are architectural design patterns, (architectural in the sense of building, not software). They refer to a different design..

So, yes: design patterns, are!

What they are? Common solutions to OO design problems (not a library of C++ templates!).

New languages (or not so new) with greater flexibility make some of the GoF patterns unnecessary, because they're solved by the language itself and the problem doesn't appear.

Granted, lot of people will jump directly to apply the pattern without understanding what are the forces behind that particular pattern leading to apply the pattern in the wrong context. Maybe that's a downside of the popularity of the GoF patterns: people just apply the patterns without bothering to learn OOAD. A pattern should be the “missing piece of the jigsaw” that when put in place unifies all the forces harmoniously.

For me, one of the greatest value of the design patterns was to show the usefulness of the patter format to capture reusable knowledge: naming common solutions for recurring problems and the implications of that particular solution. As an example, (software) architectural patterns are an easy way to convey an architectural style by just mention the pattern name (e.g. layers, pipes and filters, blackboard, etc.)

Along the success of the GoF book, a whole pattern movement emerged for software and now we have architectural patterns, high level design patterns, low level design patterns, technology specific design patterns (like the J2EE patterns), analysis patterns, even business modeling patterns.

I somewhat agree that people went overboard with the patterns and need to stop overusing them and get past the 25 patterns of the book. (Every book now seems to need “patterns” in the title... and “agile” too... if I have to title a book I would name it “Agile Patterns of Refactoring Driven Design with UML”)

So, in spite of the criticism I really see value in patterns.

My restatement of "No silver bullet"

(this is my interpretation today)
The essence of software development is capture the domain information and translate it to a computer for execution.
("simple" enough, eh?)
"The most radical possible solution for constructing software is not to construct it at all" (Frederick P. Brooks)

Learning Ruby

I've been trying to learn Ruby since a long time but never seemed to have the time or the right tutorial. It looks a nice way to get into the dynamic languages way of thinking (and clean some of the java stuff in my brain), and a very fun language to program.
Yes, I toyed with the online ruby interpreter try ruby!, played with Ruby on Rails on my computer, and read some tutorials, but I didn't got enough momentum. I have a good idea of block, closures, mixins, everything-is-an-object, etc, but I want to see them in action ( and the whole idea of DSL in Ruby looks VERY promising).
Guess is harder when you don't need to use it daily, but having missed the opportunity to learn Smalltalk, I feel that Ruby will be a better choice now.
At least, my search led me to get back in touch with an old friend.
On the other hand, Java seems to be acting like a huge borg, assimilating and digesting everything that seems to be useful to program, probably with ugly results but I'll enjoy using them anyway.
But while waiting for the results of part II and III of SCEA, I felt ready to try again, and I found a wonderful guide:
"Why’s (Poignant) Guide to Ruby", I just read the first 2 chapters, and I loved it (is a lot to say, because I already knew the stuff covered!). For me, it felt somewhat similar to "Head First" series, but with a lot less caffeine :-), really like the style.
I'll tell you at the end if I finally learned Ruby, and what I'm going to do to not forget it, but meanwhile, I'm enjoying the read...

JSF code snippet: Page scope with Tomahawk save state component

JSF code snippet: Page scope with Tomahawk save state component
By default, JSF backing beans can be only in session or request scope. Having a "page" scope is very useful, so the state is maintained between requests, but is discared when you abandon the page (and not kept in the session). You can easily achieve this by using the UI save state component from MyFaces Tomahawk project.
The bean saved by saveState must be serializable (if you have a dataModel don't forget to declare it transient) and declared of request scope in faces-config.xml

In the jsp
< t:saveState id="saveState" value="#{BackingBean}" />

In web.xml
< context-param>
< param-name> javax.faces.STATE_SAVING_METHOD < /param-name>
< param-value>client < /param-value>
< /context-param>

< filter>
< filter-name>extensionsFilter < /filter-name>
< filter-class> org.apache.myfaces.component.html.util.ExtensionsFilter < /filter-class>
< /filter>


In faces-config.xml
< navigation-rule>
< from-view-id>/myScreen.jsp < /from-view-id>
< navigation-case>
< from-outcome>cancel < /from-outcome>
< to-view-id>/myScreen.jsp < /to-view-id>
< /navigation-case>
< /navigation-rule>
< managed-bean>
< managed-bean-name>BackingBean < /managed-bean-name>
< managed-bean-class>myPackage.BackingBean < /managed-bean-class>
< managed-bean-scope>request < /managed-bean-scope>
< /managed-bean>

The navigation rule to the same screen on cancel has the nice effect of clearing the saved values. That makes implementing a "Clear" button just that easy.

JSF code snippet: No data found message for a table

A short one: display a message when there's no results to display in the dataTable

< h:dataTable value="#{BackingBean.tableModel}"
... rest of the dataTable configuration
>
..... dataTable columns ...
< /h:dataTable>
< h:panelGrid width="100%" rendered="#{BackingBean.tableModel.rowCount == 0}">
< value="#{msgs.noResults}">
< /h:panelGrid>



The datatable will render only the column titles, and then the panel grid with the message will be rendered

UPDATE: I just noticed that while posting, the JSF tags got completely messed up, should be fixed now

JSF code snippet: parent-child lists

(I'm extracting a collection of JSF code snippets from my projects to keep them in a easily accessible place)
Here is an example of parent-child drop downs with multiple child selection, and the list of childs is not rendered until a parent is selected...

In the JSF page:

code:

...
< h:selectOneMenu id="parent" immediate="true"
value="#{BackingBean.selectedParent}"
valueChangeListener="#{BackingBean.changeParent}"
onchange="submit()" />
< f:selectItems value="#{BackingBean.parentsList}" >
< /h:selectManyListbox>
...
< h:selectManyListbox id="childs"
value="#{BackingBean.selectedChilds}"
rendered="#{BackingBean.parentId !=-1 }"
size="4" >
< f:selectItems value="#{BackingBean.childsList}" />
< /h:selectManyListbox>
...

In the backing bean:

code:


...
public void changeParent(ValueChangeEvent event)
{
Long parentId = (Long) event.getNewValue();
selectedChilds=new Long[0];
childList = getChildList(parentId);
}
...

My recipe for OOAD with UML

How do you go from requirements to coding?
Everybody has different alternatives. Working on my SCEA assignment, I'm using OOAD with UML.
I choose to have an intermediate point: I'm not formally doing the OOA first (only in my head) and the OOD doesn't have much detail.
Ingredients:

• Enough Use cases
• A Busines domain model (small)
• Some Aditional requirements
• Pen and paper (could be relpaced with a whiteboard)
• A working brain (hard to find, I usually manage without it ;-) )
• Plenty of coffee
• A beer

Read the use cases and requirements, stir that in your head for a while Get a piece of paper and draw the "map of the world" (existing components, outside systems, etc) to give your brain something to think about.
Create a very basic class diagram based on the domain model
Select one of most the complex use case and create a sequence diagram for it:

• Put the actors involved
• Choose the interface/style required to interact with them (web, Thick client, Messaging, etc.)
• Use the identified objects from the class diagram to fulfill the requirements from the use case
• Each object will have their responsibilities in the use case context.
• You will need to add more objects and/or split existing ones to better distribute those responsibilities
• Drink a cup of coffee
• Write your assumptions

Once you fulfilled the requirements of the use case, let the sequence diagram cool for a while.
Dump all the classes you identified in the class diagram and mix them with the existing ones.
Think how you can better organize it (if smells like refactoring, you’re good, but don’t expect any “code smell” we’re far from the code). Once you’re satisfied with the result, go back to the sequence diagram and adjust it so it conforms to the new class structure. If your class diagram grows too big (maybe # of classes >7+-2) organize it in layers: put one layer of services classes, one layer of domain classes, one layer of application classes, etc.
Once the class diagram is ready, group those classes in components of the component diagram (you can add lollipop notation for the interfaces, is a nice touch)
Rinse and repeat for the other use cases.
When you’re done, you can serve the components inside deployment units in a big deployment diagram.
Now you can take a break and drink the beer!

DISCLAIMER: as with most recipes, the real process is completely different