• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

overdoing patterns

 
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would love to win this book. The question I have is doesn't it seem like we are going a little pattern crazy. I mean the project I am on right now, patterns is a great buzzword but we have factories, singleton, business delegate, session facade, and so on and so forth and then we have Impl classes implementing everything. When is it too much?
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use patterns carefully.
Patterns does increase the complexity of the system but does maintenance easier. Some patterns increase overhead (For e.g. Business Delegate) but does isolate business service architecture from the client tier.
Use patterns prudently.
A novice will find it difficult to understand the benefits of the patterns.
Like Sun site says
It is important remember that patterns do not guarantee success. A pattern description indicates when the pattern may be applicable, but only experience can provide understanding of when a particular pattern will improve a design.
[ August 26, 2003: Message edited by: Pradeep Bhat ]
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Pradeep, I would dare to say that most design patterns do not decrease performance in any significant way. An extra method call costs close to nothing.
Regarding Stefan's question, I think "too much" is when you refactor code into a design pattern without evaluating the costs and benefits of the work.
 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with you. Patterns are being overused as the be all to end all.
A lot of patterns cause performance degredation also. Some add more maintenance issues due to keeping additional classes - Proxy pattern. (I think the proxy pattern is a very useful one)
There are over a thousand documented patterns at this point. When I was doing the OMT method one of the important design tenants was when something in a class is subject to change a lot over time isolate it into a separate class.
With that in mind consider the number of patterns that have been created and given a separate name that just implement this good design practice! Some patterns are just renamed variations of other patterns. the J2EE patterns are not general solutions since they use J2EE components only in their solutions. So they would not be useful for someone doing embedded systems work in C++.
I know, I know they are not supposed to be used by these people....
I also think that the J2EE patterns are very useful in learning how to solve specific problems in the J2EE world. Note the word specific, if every solution is a pattern we are going to end up with an awful lot of J2EE patterns!
Noel
P.S. I would also like to receive the book.... :roll:
 
Author
Posts: 367
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use a pattern when it solves a problem. I recommend keeping your design simple at first. Your session facade probably is helping you, but your business delegate probably isn't. (based on my experience)
Your factory might be making your life easier when it comes to extension, but if you are just creating factories for the sake of factories then you are needlessly complicating things. Every pattern has it's place. Some are almost always a a win, some (like my favorite whipping dog, the singleton) are almost never a good thing outside of the narrow context they were conceived in. It just depends.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pradeep, I would dare to say that most design patterns do not decrease performance in any significant way. An extra method call costs close to nothing.


I hate BD because the extra layer adds nothing but one more layer of coding.
The idea "It hides the EJB layer" is not so great! My personal opnion ofcourse!
There are projects where it will be useful and I haven't come across them!
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Your session facade probably is helping you, but your business delegate probably isn't. (based on my experience)


I completely agree with you!
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd be interested to hear about particular patterns that degrade performance somehow significantly because I can't think of any. (I could browse the bookshelf but I'm too lazy to do that...)
Most design patterns are based on an added layer of indirection in the form of interfaces, factories, and so on. This does increase the number of source files you need to manage. However, this added maintenance cost is paid off by the easier maintenance of those parts of the code in question that need to be changed. If the scale starts to tip, remove the indirection.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was just wondering how many appreciate Business delegate design pattern ?
Has any one found BD to be useful in real projects. I mean real.
Suppose my session facade interface changes so will my BD interface. This means the client code has to change as well.
It does hide the EJB layer (Lookup and exception hidden). My question how big is this advantage?
Comments are welcome! Thanks in advance.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

It does hide the EJB layer (Lookup and exception hidden). My question how big is this advantage?


JNDI lookups, home caching, narrowing, exceptions... All of this is moved from the client code into the delegate. Isn't this already an advantage in terms of cleaner code? Maybe not always but sometimes at least. For every pattern there is a use. Whether the use matches the current problem is the key.
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I'd be interested to hear about particular patterns that degrade performance somehow significantly because I can't think of any. (I could browse the bookshelf but I'm too lazy to do that...)


I'm with Lasse on this one. It really isn't appropriate to say that such and such Design Pattern increases or decreases performance because a Design Pattern does not imply anything about its implementation.
For example, a simple Decorator pattern could be implemented numerous ways in Java... using inheritance and extending the class, using composition and implementing a common interface, or using dynamic proxies. Each implementation will have different performance characteristics and trade offs.
 
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would also love to win this book.
 
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reading all of the above, has proved one thing alone for me. I really do need to get some reading done as I have no idea about most of the patterns you guys are discussing.
It seems in our field, there are endless innovations and one has to just keep learning new technologies to survive, which is not a bad thing.
My question is: I am restructuring a webapp at the moment which I did using Model 1 MVC, in a really bad way, since there was tonnes of sriptlets in the code. I have now gone on to using model 2 MVC as the app is growing very fast.
A question that I am faced with at the moment is should I extend the development time by looking into design patterns, whether or not to use EJBs, stick to my own controller servlet or use Struts etc or simply roll out the Model 2 MVC based app and then re-visit parts of it.
Any comments from the experienced folks will be more than welcome.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Spending time for analysis does not necessarily lengthen development time. I would say "analyze but stop frequently to evaluate whether further analysis will be worth the investment".
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would suggest spending more time during analysis will be better to avoid problems during developement.
[ August 27, 2003: Message edited by: Pradeep Bhat ]
 
Author
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is in response Pradeep's question on the usefulness of Business Delegate (BD) pattern. We have been using BD in several projects for many years now.
As Lasse put it above, you have to judge when a pattern is useful or not based on your own requirements in your project. However, in addition to encapsulating remote business tier components (such as Session Facades), BDs have other usefulness in our applications:
1. BDs translate exceptions thrown by the business tier container (e.g. RemoteException) into more meaningful user friendly exceptions. This improves ease of use of business tier.
2. In large projects, BDs shield the Web/HTML/JSP/Taglib/UI programmers (who may not be EJB programmers) by providing a simpler object interface. This improves productivity.
3. In some cases where it makes sense, BDs can cache certain data making it unnecessary to re-invoke the business tier component. This can improve performance.
4. In cases of failure on the business tier (e.g EJB session timeout, etc.), BDs can recover by implementing retry logic as long as the problem is recoverable. This can improve availability.
Having said that, you have to weigh how useful the above features are against introducing the BD in your application as it will be another layer of objects between your client and the business tier. In most cases, this tradeoff (i.e. an extra layer) is outweighed by the benefits offered by the BD pattern.
Hope this helps reducing your hatred towards the BD :-)
 
Chris Mathews
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another thing that I like about Business Delegates is that they are easy to mock. Therefore, you can get the UI team up and running on the mock BDs before the EJB layer is completed. Once the EJB layer is complete you swap out the mocks for the real thing and you are golden.
Of course, this requires a bit of an extra investment but is usually well worth it. Kyle Brown recently wrote an article that discusses a similar technique for plain DAOs. Check it out here.
 
Stefan Bell
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks everybody, i like to hear others thoughts on this matter.
Deepak finally hit the hammer on the head as to why we use the Business Delegate with #2. It is a good way to split up the front end word from the back end work. And I would love that book.
Stefan
 
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:
[QB]Patterns does increase the complexity of the system but does maintenance easier. Some patterns increase overhead ...[QB]


Howdy wranglers,
I never thought Patterns would stir up such a brawl. Tossing in my hat, though...
Patterns DO NOT increase the complexity of a system! (I've always wanted to use the "no no" Graemlin.) That is a complete misunderstanding.
Each Pattern describes a specific type of problem it seeks to address based on past experiences. One or more solutions are methodically described so as to enable others to create solutions to similar problems using the same essential structures and concepts that have been discovered and shown to have general success in the past.
However, there is truth to everyone's uneasiness about using Design Patterns when perhaps they are inappropriate. In my travels, I find that
software developers who do not know about Design Patterns (or even UML, in some cases) generally react to UML designs that happen to enjoy the simplifications allowed by Patterns. They're reaction is to say that it complicates things/ The uninformed developers can put up quite a struggle against following designs they don't understand. Heck, I've done it a time or two. A design based on Design Patterns may seem complicated if you don't know what all those names and concepts refer to; they aspects of the problem they are solving for you because of other people's experiences. But that is not a shortcoming of the Design Patterns or their practitioners.
No harsh feelings, mes amigos!
John
 
Stefan Bell
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with John about patterns causing complications. It just isn't true. I have been using patterns for over a year now and I was totally confused about the patterns but the more I use them especially on this project, it actually makes it less complicated. But I do believe that they are being overused and in some instances not used properly. I don't really need 10 layers to write a sortFilter.
 
Faisal Khan
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Should the issues related to design patterns be almost entirely left to the architect or are they just as important for developers?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Should the issues related to design patterns be almost entirely left to the architect or are they just as important for developers?


In ideal world, the architect can leave the use of design patterns (Proxy, Iterator, Facade, etc.) to the hands of developers and concentrate on architectural patterns (mvc, pipes and filters, blackboard, layers, etc.).
Design patterns respond to the problems developers are tasked to solve. That's why it's the developer who should deal with them. Unfortunately, sometimes the architect is the only one who knows what a design pattern is (or vice versa)...
 
Faisal Khan
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Lasse for that answer. It makes sense and gives me even better idea of design patterns.
I have another question about DB abstraction / DAO (I am not fully clear about the DAO yet) -
Senario 1 (currently how I do it) - I have a class where I do the database connectivity and have methods to take a query and return and array of results. All other classes use an object of this class to query the database.
Scenario 2 - I write a DAO class for each of my classes to perform database specific functions for those object. For example, I have a class Car which makes extensive use of the Database class from scenario 1, but now I should have CarDAO class.
I am not sure if I have made sense. I am sure you guys will let me know either way.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure what was the question but what you described sounds a lot like the DAO pattern.
 
Faisal Khan
Ranch Hand
Posts: 285
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I thought, I may not have made full sense. My question, I guess really is, should I be using scenario 1 or 2 above from a good design perspectve.
That is, should I continue down the path of having one Database.class with a method performQuery( String query ) and all my classes use this class for querying the DB.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Faisal Khan:
I thought, I may not have made full sense. My question, I guess really is, should I be using scenario 1 or 2 above from a good design perspectve.
That is, should I continue down the path of having one Database.class with a method performQuery( String query ) and all my classes use this class for querying the DB.


Ah. Now I see clearly.
The second option would be better (as the client doesn't need to know SQL). You can have a base class for providing things like connection pooling, reading configuration, etc. and extend your "CarDAO", "UserDAO" and so on from that class.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic