• 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

Refactoring to Patterns

 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Isn't there a danger of endless confusion if work is left so that it is neither one pattern nor another but somewhere in between.
In a past project, speaking of a case where it was left mid way between a Business Delegate and JavaBean - it ought to have been a JavaBean given that no networking was subsequently required but no resolution was reached.
It wasn't my code but I have nightmares that they would continue generating the part BD for the entire project unnecessarily for years to come without realising why it was so.(There were other non-Java tools in between to add to the confusion. And I can guarantee there would be no networking required on that particular project for a few more years yet. A simple thing but a right royal screw-up on Motivation.)
So I hope Refactoring to Patterns means some pattern is established finally, it just doesn't necessarily have to be a widely known pattern just one that is recognised within the project.
How would one ensure it was widely recognised other than great nodding of heads ?
Documentation ? Impossible since no resolution was reached.
[ February 21, 2004: Message edited by: HS Thomas ]
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
it just doesn't necessarily have to be a widely known pattern just one that is recognised within the project.
Unfortunately I've faced problems with this, too.
A few years ago most of the self-important "I know everything, and you are only a contractor" types I encountered were pushing "architectures", and the main problem was usually massive code bloat. It seems large organizations can't bring themselves to admit they might have problems needing small solutions - everything has to be "strategic" and "enterprise" :roll:
These days, a lot of them have encountered the idea (or at leat the name) of Patterns. The self-importance comes in again when every grubby and misconcieved local idiom gets elevated to the status of "Pattern", and trotted out at meetings as evidence of a good design.
Where possible I like to stick to the guiding rules of patterns. You need three separate successful applications of it, to be worthy of naming as a pattern.
Not all software has to fit known patterns, though. Some situations are sufficiently uncommon to need an individual solution. To find out, I usually suggest focussing on the published reasons and situations for using the well-known patterns, rather than leaping straight to the implementation details. If the motivating forces are not the same, then it makes sense to consider a different pattern.
Bear in mind that just because the current shape of your code looks like a known pattern, doesn't always mean that this is the most appropriate pattern to use.
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Frank.
To find out, I usually suggest focussing on the published reasons and situations for using the well-known patterns, rather than leaping straight to the implementation details. If the motivating forces are not the same, then it makes sense to consider a different pattern.

So what would the motivation be for either a JavaBean or Business Delegate ?
[ February 21, 2004: Message edited by: HS Thomas ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason I ask : faced with the decision of either a quick and dirty solution to hang different tools together shouldn't one aim for an OO design.
Motivation for the component being a JavaBean : reusable, OO design
Motivation for Business Delegate : networked, OO solution.
Motivation for the part BD : actually it was just using the reflection API to get at the methods in a JavaWrapper generated from the tool.
The simplest thing that worked (quick and dirty ) but hardly reusable or OO design, an extra step in compilation, a waste of time in that respect. When XP recommends doing the simplest thing that worked, I expect it also means aiming for reusable OO.
I see Java 1.5 will be using dynamic proxies instead of RMI stub and skeleton generation which seems to be a step in the right direction.
[ February 22, 2004: Message edited by: HS Thomas ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But then again, there are examples of several workarounds especially in the EJB arena.
Session Facade and EJB command patterns - designs to minimise the number of network round-trips but hamper practising OO design. This is a serious risk according to Rod Johnson. EJB should be an implementation issue not drive the overall design.
ANY tool that is used tends to drive the design overall,IMHO. True or not ?
 
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 HS Thomas:
The simplest thing that worked (quick and dirty ) but hardly reusable or OO design, an extra step in compilation, a waste of time in that respect. When XP recommends doing the simplest thing that worked, I expect it also means aiming for reusable OO.

XP recommends simplicity, which may or may not lead to reusable code. The result is not automatically reusable across projects regardless of how Good Design it is because reusability costs (hardly anything is without explicit attention to it) and the focus is on current customer value.
Personally, I have only reused two things:
1) a set of requirements and an architecture for a specific problem domain
2) a custom library of XML, IO, etc. utility classes
 
HS Thomas
Ranch Hand
Posts: 3404
  • 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:
the focus is on current customer value.
Personally, I have only reused two things:
1) a set of requirements and an architecture for a specific problem domain
2) a custom library of XML, IO, etc. utility classes


I am not sure where JavaBeans stand on performance now, but then the trade-off may have been on reusability vs. performance. Stripping of to the bare minimum requirements ( reflection) and using XML for any pluggability / reusablity issues perhaps was a wise decision made with foresight..Good performance and scalable.
Perhaps there are more than three uses of this design feature and deserves a Pattern name. Is something similar used in JSPs ?
Name the Pattern.
[ February 23, 2004: Message edited by: HS Thomas ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by HS Thomas:
The simplest thing that worked (quick and dirty )


"Quick'n'Dirty" is only the first part of finding a Simple solution in XP - making the current test pass as easy as possible. The second, most important step is to refactor the design so that it is Simple in the whole, as defined by (in priority order):
- runs all the tests
- expresses intent
- contains no duplication
- contains no superfluous code
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, Ilja. That sounds simple.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by HS Thomas:
Thanks, Ilja. That sounds simple.


Yes. Unfortunately (or fortunately?) it is *not* *easy*...
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Would anyone have an opinion on whether it should have been JavaBeans that were generated from the non-Java tool wrapped round the database rather than Java wrappers? It's still bugging me. What would have been the right thing to do in this case ?
[ February 24, 2004: Message edited by: HS Thomas ]
 
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
Why couldn't a JavaBean do the networking?
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It was one of the earliest JavaBeans 1.0 and I cannot recall whether it had networking.
The constraints as I remember were :-
HTML for the light-weight client but no JSPs ; instead had Swing-like classes generating HTML for the presentation. The wrapper used reflection to get at the non-Java methods/functions to access the database. Reflection implies motivations similar to that of RMI or JavaBeans in such a context.
Networking may not have been a then current requirement. I just think that JavaBeans being a reusable component architecture would have saved a lot of confusion. But mixing and matching technologies to requirements isn't simple. A lot of work that may have gone into building the presentation isn't easily chucked away once requirements change to include networking. There's a lot of people trained to work around those screens.
Anyone maintaining those would have a problem Refactoring to Patterns unless they butcher it. I am not sure that simple thing that works is necessarily better in the long run - almost as bad as overkill implemention of patterns.
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I suppose as long as someone understood why it was done that way - economic value in not changing too much but keeping a foot on the ladder for change in the near future not much harm done..
It's something an architect should decide, really and in current climate possibly would expect the JavaBean option to be taken.
But transferring to a JavaBean earlier would have raised developer skill sets but perhaps not business economic value. But then refactoring comes into it's own here. I guess this kind of decision will still bug me.
[ February 25, 2004: Message edited by: HS Thomas ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Or InfoBus ?
InfoBus is an optional package in Java 2 Platform, Standard Edition (J2SE) that extends JavaBeans component API by providing a set of enhanced interfaces to share and exchange dynamic data.
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I worked extensively with InfoBus when one of the first specs were released back in 1998 (admittedly I was using an off-the-beaten-path application of it). It's really more of a stripped down MOM than anything else, and it's really kind of fallen by the wayside once JMS came out.
Incidentally, if you guys are talking about performance problems and code bloat concerning getters and setters--I wouldn't worry too much about it. Since HotSpot, all one line getters and setters are inlined anyway, so there's no performance penalty.
And if it's code bloat you're worried about...if you implement a bunch of value objects with public member variables and everyone starts accessing them and setting them directly, what happens down the road when you need to stick in some logging code or fire off an event when a value gets set? You have to make the getters and setters, and then to force everyone to actually use them (so the accesses get logged and the events get fired), you'll make the member variables private anyway, and everyone will have to go in and change all that code.
On the other hand, if you start with the one line getters and setters, you can later go in and add validation, logging, event-firing, etc, with no impact to anyone else. Or, you can subclass those VOs and have your back-end system hand back the subclass polymorphically...stuff just works. I find that the up-front savings of breaking extensibility by violating encapsulation principles never pays off in the long run.
sev
[ March 01, 2004: Message edited by: sever oon ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Sev. That's useful to know.
I think refactoring to patterns should only come after loads of experience.(perhaps architecting experience). If the tech/API then falls by the way-side , room for more refactoring . Any idea what happened to the off-the-beaten-path app ?
XP does not aim for transcendental perfection in it's programs.
Wabi-sabi is an aesthetic celebration of the rough and functional. - Kent Beck
[ March 01, 2004: Message edited by: HS Thomas ]
reply
    Bookmark Topic Watch Topic
  • New Topic