• 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

strategy pattern:how to call some SuperType mthd. from encapsulated behavior object

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
if i have following(see my question in CanNotDunk Class ) can i call some Supertype method?

[ October 28, 2005: Message edited by: Ner min ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To call NBAStar.jumpShoot() your strategy would need a reference to an instance of NBAStar. You can add an NBAStar parameter to the strategy constructor ...

See if you can imagine the strategy keeping the instance of NBAStar it gets in the constructor and calling jumpShoot() later.

A couple concerns: I added a circular dependency between the strategy and the NBAStar. Not a great thing, but necessary some times. Be very careful about how this affects your package or component dependencies. I also passed "this" to another class in the NBAStar constructor, unsafe because "this" is not completely ready for action and some strategy might try to use features that aren't set up yet.

This is a cute example. Is it for class? Did you make it up?
 
Ner min
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok this is how it works:


#Stan
yes i made it up couse i dindnt like that stupid "duck-example" and i needed something i can remember(im a basketball player)
Question 1.
what u mean by circular dependency?
Question 2.
whay did u used "___this___ " and not just "this"
Question 3.
is it clever to force every "concrete Dunk" implements dunk(NBAStar n)
ading the overhead of always passing the "this" even if is not needed.

I mean i know i could repeat in the CanNotDunk the System.out.println("i m jumpin and i m shootin"); line but the i would have the same thing on two places.

So what is the better way to go same thing on 2 places or overhead of this
[ October 28, 2005: Message edited by: Ner min ]
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Circular dependency: NBAStar requires strategy to compile and strategy requires NBAStar to compile. It's a warning sign but not a fatal flaw. There are ways to break the circle with interfaces. A good "next topic" maybe.

The lines around ___this___ were just to emphasize it. Instead it confused. Sorry about that.

I'd avoid duplication at (nearly) any cost. Passing "this" around is really pretty cheap. I might look for a way to get it out of the constructor.

Good topic and good questions. Keep asking!
 
Ner min
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

NBAStar requires strategy to compile and strategy requires NBAStar to compile. It's a warning sign but not a fatal flaw. There are ways to break the circle with interfaces. A good "next topic" maybe.

Passing "this" around is really pretty cheap. I might look for a way to get it out of the constructor.


the question reffer to youre both statemens.

But how do i break dependence?

Only think i can imagine is to make NBAStar an interface and then some class wich implements it. Wouldn't that have add to much komplexity?
And by the way, WHAY I SHOULD awoid dependence in this case couse the dunking-behavior is specific to ONLY BasketballStars and ONLy the BasketballStars striveing to Dunk?
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See, I said you have good questions! And answers, too!

Yes, a new interface would break the cycle. NBAStar and strategy would both require knowledge of the interface and they could be compiled and deployed separately.

This kind of thing really matters in big systems if you want to isolate change and maybe deploy components on indpendent release schedules or shrink wrap and sell them. I try to practice good dependency management even on very small projects just to challenge myself and form good habits, but I'm not fanatical (enough) about it.

Read up on "dependency inversion" for fun. I often see the issue coming down to which component "owns" the interface and which one implements it. There are some neat static source code analysis tools that list all your dependencies and grade them on a number of criteria Robert Martin put together. Of course I can't name one right now. Anybody?
 
For my next feat, I will require a volunteer from the audience! Perhaps this tiny ad?
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic