Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

To pattern or not to pattern?

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi:
Many a times we find that neatly designed text book architectures being pushed by the 'client' or 'architects'. Question is how does this affect other factors such as performance, scalability etc.
For example, an EJB Facade calls a Controller (Simple Java Class) that in turn calls a third party tool(through a Session Bean) for executing the business rules.(These EJB Classes are not LocalEJBs). This was argued as the best indirection in one of our projects (Facade->Controller->Rule Engine).
What do you think?
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One always has to be pragmatic.
The moment you start to use patterns for the sake of using patterns rather than because it serves a real purpose towards making the application more robust or easier to maintain and write is the moment you should step back and take a breather.
As an example of how pattern use can lead to pattern abuse, the following (note this was not a Java application but C++, the principles still hold):
A large desktop application with a database and background jobs.
It was decided to use a multi-layer model to build the system (though not a client-server architecture).
Effectively this led to a sorta MVC-like system with a database access layer, a business logic layer and a presentation layer.
All good and well, this is good design.
To further decouple the layers from changes in each other layer, it was then decided to implement each layer as a multi-layer system with a service access layer, a logic layer and a presentation layer.
To make decoupling even easier, it was decided that all access to objects in any other layer should be through factories only. This was then extended to have the factories themselves accessible only through "superfactories", factories whose sole purpose was the creation of other factories.
So we now have a 9 layer application with 2 layers of factories in between every pair of layers.
As a result the application is a perfect example of design techniques, a gem in the crown of what can be done using Rational Rose and other design tools.
It's also terribly slow and impossible to debug.
We had to pipe around the layers and open up holes in the architecture at several places just to have simple printjobs complete within reasonable time (read, printing 500 formletters using the proper paths through the architecture would take about 48 hours, hacking the database and printjob to work together outside the framework was required to bring that down to a more reasonable 4 hours which is still long but at least means the users can start a printrun on a separate machine in the morning and have the letters in the mail when they go home in the evening).
This is the ever present danger of overengineered software, software designed by people who have not touched code ever (or at least not since graduating university), instead working ONLY with diagrams and models, then insisting their designs are followed to the letter.
 
poornima karanth
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with you. In fact the MVC model is much abused, the model is replaced by n-layer architecture.
However the example that you have given is taking incredibly long time. The infrastructure (h/w and networking) might also be culprits, i guess.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My favorite way to approach patterns is when refactoring some code I think, this is starting to look kinda like pattern X. I go to the book for pattern X and it reminds me that if I'm going to wargle a brup, I _might_ need a framifier. If the fit is good enough, I might rename some classes to help future readers recognize the pattern more quickly. Patterns give me value, but I don't go to the book looking for one to implement next.
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think what Stan describes is an approach taken by many skilled patter-users. The trouble is that for it to work well, the practitioner needs to have at least a rough knowledge of some sort of pattern catalogue, in order to recognise incipient patterns.
Most abuses of patterns seem to originate from developers who are only familiar with a very small set of patterns. Iin the all-too-common example, a developer who has heard of Singleton, and is determined to use it in the next project
The difficulty seems to be how to most effectively get a broad, if shallow, knowledge of patterns across to new or inexperienced developers, so that the "grown up" approach of refactoring to patterns when appropriate seems a natural way to work.
 
Tomorrow is the first day of the new metric calendar. Comfort me tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic