• 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
  • Tim Cooke
  • Devaka Cooray
  • Ron McLeod
  • Jeanne Boyarsky
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Martijn Verburg
  • Frits Walraven
  • Himai Minh

Tell don't ask and model view seperation

 
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I find there is a tension between the principles of "tell don't ask" and model view seperation. For example, I always end up with code like this :



Not ideal, switching on the objects type.
However to maintain model/view seperation, I cannot ask the object for it's image.
I could also create a map of class to image, but that is just another way of writing the switch statement, and it doesn't handle subclasses so well
I've tried using a double dispatch pattern, and while this does get rid of the switch, it makes the code much more confusing.

So in the end, I just live with the switch statement. Are there any other patterns/approaches I could use here?

thanks, Don.
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Conditional code is fine. What make you think that it is a problem?
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could simulate a double dispatch approach if you really want to, but it makes the code much more complex and it doesn't do much to improve maintainability either:



So exactly how far are you willing to take this to avoid those instanceof checks? ;)

Edit: Yeah, so I sort of skimmed over the part of your OP where it says you already had a look at the DD approach, and shot it down for the same reason I mentioned. I'll stop wasting everybody's time now...
 
Don Kiddick
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Exactly. So just live with conditional is probably the best bet. Ta.
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not too much fun in Java, but I've often used decorator-like things when stuff like this pops up.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The only problem I see with the conditionals is that this way the method is tightly coupled to all possibly existing types. At some point, you might want to separate some of those types into different, potentially optional, moduls. Then it really starts to make sense to use some kind of registry, like a HashMap - one, that doesn't get filled from a central place, but that different moduls/plugins contribute entries to.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic