Hollywood Principle

[Flash Gordon]

Hi guys,

Is this a violation of the Hollywood Principle?

var upper:UpperLevel = new UpperLevel();
var lower:LowerLevel = new LowerLevel(upper);
lower.foo();

//
//
package
{

public class UpperLevel
{

public function UpperLevel()
{
//
}

public function speak():void
{
trace("Hello World");
}
}
}

//
//
package
{

public class LowerLevel
{

protected var _instance:UpperLevel;
public function LowerLevel(instance:UpperLevel)
{
_instance = instance;
}


public function foo():void
{
trace("LowerLeve.foo() called");
_instance.speak();

}
}
}


If not, I'm confused what it really means then.

[hangalot]

this is composition. so in that sense not a problem for the hollywood principle.

the hollywood principle's best indications are template or startegy patterns and it asks you not to call up the chain

[Flash Gordon]

hm....you mean chain calling how how the Decorator Pattern does?

Think you could give me an example of what you mean?

[hangalot]

you could call it a decorator, but in this exact example you are not adding more functionality to a method of the same name and adding some to it.
here i just see a class composed onto the class you wish to use and you taking functionality from that composed class

[Flash Gordon]

I don't follow. How do I break the Hollywood Principle?

[hangalot]

you don't. the problems i see relates to the fact that you aren't coding to an interface

[Flash Gordon]

LoL.....I'm not asking for feedback on what I wrote. I'm asking for someone to demonstrate breaking the Hollywood Principle. I don't understand what it is, so I'd like to see the anti-principle in action and then maybe the correct way.

[Flash Gordon]

Can anyone show me the correct way of the Hollywood Principle and then the wrong way of it?

[Assertnfailure]

Which one's the hollywood principle? Know only your friends?
I never hear the names of those principles outside of that java book.

If so, then an example of that violation is:
myShape.graphics.clear()
:o

Of course, nobody really cares about that one, since it would be far too inconvenient to do anything else.

The idea is, that instead of talking to an object's sub-objects directly, you talk to them via the object as proxy. This way you abstract the implementation, so you can make changes in the future without breaking everything.

For example, what if, for some obscure reason, Adobe decides to change the graphics property to "gfx"? Then the example listed above would break all over the place.

However, if instead, your myShape had a public method:
public function clearGraphics():void{
this.graphics.clear();
}

Then you can just call that method instead. If graphics is changed to gfx, then the only place you have to make that change is inside that method...as opposed to a potentially infinite number of places.

[Flash Gordon]

Ah....that makes total sense. **light bulb goes off** And in fact, it is kind of similar to an adapter or command principles.

According to the book (which I don't have any more) the Hollywood Principle states "Don't call us; we'll call you."

EDIT:
Hmm....here it is at WIKIPEDIA (http://en.wikipedia.org/wiki/Hollywood_Principle). It seems like composed objects should not call methods on the client.

[Assertnfailure]

ohhhh.....
I was thinking of a different principle....

Ok well for the hollywood principle...you can see tons of examples of that in the flex framework. For example, the UIComponent class has most of the logic built-in to integrate into the core framework and the various managers used in flex. When you build custom components, you're building lower level classes that extend the higher level UIComponent. Most of the protected creation and validation methods you override are called only internally by UIComponent, so in essence, it follows the "don't call us, we'll call you" mentality.