We see far too many people not writing object‑oriented code.
Gerard Gauthier wrote:. . . what areas of Java programming do rookie Java programmers tend to overlook . . .?
Most true rookies don't need a CLASSPATH at all. You only need it after you have started using external resources.
. . . the class path. . . .
Any subclass must always obey the principle that a subclass IS‑A superclass. An overriding method must always obey the specification given by the overridden method. Any changes must follow those constraints.Both those methods calculate pay (without calculating taxes) and may or may not throw such an exception. It would be wrong to implement that abstract method to calculate taxes. It would be all right to pass 1000000 hours to one overriding version because it ignores that parameter anyway. It is necessary to explain what the method does (=documentation comments) in order to allow it to be overridden. I shall let you guess what the last change I made to the documentation comments was, and how that causes both implementations to break the LSP. Also tell me what I put in the documentation comments that restrains the code in the future.
Monica Shiralkar wrote:. . . any subclass in Java has the right to override and change the implementation. . . . .
In OO that would translate as
Junilu Lacar wrote:. . . . If the superclass accepts one kind of input, its subclasses should also accept the same input. . . . .
. . . or more input. As far as I am concerned, if the overriding method would throw an exception for input which the overridden method would accept, that is incorrect overriding. It is permissible for the overriding method to accept more inputs than the overridden method. There is a description in Object‑Oriented Software Construction by Bertrand Meyer, but I think he doesn't say, ”Liskov.” Can't fid the page in my copy; sorry.
Junilu Lacar wrote:. . . . If the overridden method accepts one kind of input, itsoverriding methods should also accept the same input. . . . .