An object of a subclass must always be able to be used as if it were an object of its superclass. Tightening access modifiers violates this principle.
The principle is called [some bloke whose name begins with L and ends OV]'s Substitution Principle, and is one of the basic rules of object orientation.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Hi Peter, Please let me know how tightening violates the principle and which principle exactly it violates.If possible,please explain through some example.
As this sounds like it could be homework, I don't feel inclined to provide a full answer that could just be copied. I think you should do some Googling first. I've given some very good clues.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
It's kind of like buying a AA battery for my TV remote. No matter who makes it, I expect it to fit my remote. I'd be really ticked if I bought batteries and found out they were too short to fit.
Think about shopping for a List. List is an interface that might be implemented by ArrayList, LinkedList or some new fangled List that I write. When you buy a List you know you can call size() to see how many things are in the list. What if I make my size() method private? I advertise "This is a List!" on the box, but you get it home and there's no size() method! That would be so bad that the compiler just won't let me reduce the visibility.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi