Of course, every so often Junior gets gutsy and builds a Static Variable in his Castle with the same name as one of Dad's Static Variables. Since he never confessed that he was getting the value from Dad, as far as all his friends know, Junior's Static Variable is the only one there. He just hides the fact that Dad has one with the same name. Heck - he often isn't so respectful as to even use the same TYPE for his Static Variable. Anyway - you have to be on to his tricks and know to use the magic words (that would be to say "super dot" ) before you request a Static Variable from Junior, to insure that you are getting at Dad's Static Variables for sure. Then again, you could do what the rest of the world does, and just request Dad's Static Variables directly from Dad by using his Classfile name in front of the variable, like "Dad.var" or whatever.

When Junior is being especially difficult he will intentionally pull rank with his Static Variables. So if Dad has blueprints for his subjects object houses on the heap that call for a variable closet with a particular name, Junior may just decide that he has to use that EXACT name for his Static Variable. Well, that means that every single one of Junior's objects that might have inherited a small closet from his Dad, well, it gets its meager closet hidden, just so some Royal Variable can use that name. It is bad enough when his Castle Variables go around hiding Dad's Castle Variables, but to hide the variables of the poor of his kingdom, this is difficult to put up with.

Same thing for his behavior. If Junior's Classfile just does not know how to do something, even after he has looked through ALL of his Royal Static decrees, he just runs down that super tunnel and finds the Royal Static decree that his Dad is keeping in Dad's method area, and follows those instructions.

Yes, he often hides Dad's Static behaviors that he should have learned with his own childish Royal Static behaviors. Royally rotten, that's what he can be. At least he can't use his Royal Static behavior methods to hide any of the behaviors that his objects might learn from his Dad (from his Dad's regular method decrees), like he can with variable closets. If he tries that the Justice Department would come down on him big time at compile time . Houses are one thing - but education for the masses is quite another thing.

Of course the reverse is true also. Junior's regular methods are way too feeble to override or hide one of Dad's Royal Static Methods. It can be good to have the Justice Department working for YOU.

Building bigger and better
So what happens when it is time to build an instance of Junior's out in the "Heap" suburbs? Not only do kids these days feel that their Classfile Castle has to outdo Dad's and all his static stuff, but all of Junior's object houses have to outdo Dad's too. FIRST Junior gets the complete blueprint for how to build one of Dad's houses on the heap, complete with all of Dad's variable storage closets, neatly labeled as having come from Dad's blueprint, and then Junior has to make HIS subjects houses bigger and better by adding his own variable storage closets labeled as having come from Junior's blueprints.

So even though Dad has laid out some very good regular method decrees, and even though left alone, the masses would benefit from inheriting this knowledge of how to behave, and even though Junior can not hide those methods with his own Royal Static methods, he CAN invent his own regular method decrees and give them the same method names. AND since Junior is the last one to talk to the objects of his kingdom, yep - you got it, they always decide to override good common sense - with Junior's version of how they should behave in case that method is called. You know - Junior is shaping up to be a heck of a politician.

Moving in on Dad
Now comes the difficult part. Sometimes Junior crowds in on Dad's space. Well, we have already described how he can mess with Dad's Royal Static Variables, and play all sorts of hide and seek games, but he also sometimes abuses the hospitality of Dad's friends.

You know about TYPEs don't you? You know how all variable closets are stamped with a type which directs them at the Classfile to get directions from?

That is great if all of the variables with Dad's Variable types are holding objects that are subjects of Dad. You know:
Dad dadCloset = new Dad();

Well, when that variable is asked for the value of any other variable that is in it's object, FIRST the variable has to run to the Classfile for his type, and get the OK to give out that information. Since Dad's Classfile knows all the variables in his objects, Dad hands out the OK to get a "Dad::var" from the object and all is good. It even seems a bit of a waste to have to go get that OK from Dad. The same thing for Junior. Junior hands out OKs for "Junior::var" information. As long as everyone sticks to variables that are stamped with their own type, there is no confusion.

But, if Junior's subjects have a hidden Dad:X and also have a Junior::X they will give out whichever one that they get the OK for. If a Junior type is asking, then that type will go to Junior's Classfile and get the OK for a Junior::X. But when Junior butts in like:
Dad dadCloset = new Junior();
The type gets the OK from Dad for a Dad:X, (Junior's subjects HAVE a Dad::X built in and hiding behind the Junior:X), and the subject gives out the HIDDEN variable Dad::X. Go Dad!!! Suddenly it becomes clear why Dad enforces those rules.

Too bad it doesn't work that way with behavior. But like I already said, behavior is not built into the object houses, it is decided on at the last minute. If a Junior object is sitting in a Junior type and a method is requested, the type runs to the Classfile and finds the behavior for the method in Junior's Method area. If it can't find it there, it sneaks down that tunnel and gets the behavior from Dad's method area.

If the Junior object is sitting in a Dad type and a method is requested, the type goes to Dad's Classfile to get the OK for the method. If Dad HAS that method, he will give out the OK, and THEN Junior will convince the subject to use HIS version instead. Unless of course you use the magic words "super dot" when calling the method.

Well, at least if one of Junior's subjects can not GET the OK for a method from Dad's Classfile, Junior can't use his own methods, even if he has them, until he gets his butt into his own darn variable type.

Did I mention that that tunnel is one way. Too bad Dad can't sneak down and swipe whatever behaviors he wants to learn from Junior.

Dare to discipline
Well, you can see that Junior could turn out to be a problem. It takes a firm hand to guide him properly. So there are some things that you just MUST make sure that you enforce.

Do NOT let them get at your private Stuff! Your privates are your own business and that is that!

You must be Firm and INSIST that they use the return type that you have used if they insist on overriding your methods. It really is not so bad if their behavior strays from the path, as long as they return correctly.

NO WAY that they should be able to throw extra exceptions in their methods after they have overridden Dad's, and expect Dad to pick up the tab! Just say NO.

If you just be sure to add these elements of discipline to your relationship with the kids, and try to understand them - well, you will just LOVE them - in spite of their wayward ways.