Campbell Ritchie wrote:Something has gone wrong with your image; please explain how you attached it.
Jesse Silverman wrote:Hi Tim:
I am thinking the OP may have used the word "warning" somewhat carelessly.
I definitely have seen this as an actual warning in other languages I need to work in, including when it was like "warning -- this very bad thing you should never do just happened". The code compiled (depending on settings) and you were playing the slot machines to find out what would happen at runtime (also often dependent upon compile settings).
But as far as I recall, this message is always associated with a compile failure in Java since way back.
There are warning class messages, usually about type-unsafe operations or deprecated usages, I don't think this was ever one of those.
Tim Cooke wrote:Giving an example of when you saw this warning might give a bit of context for your question. Otherwise the best I can offer is "it depends".
Campbell Ritchie wrote:Note the above classes are all mutable. It should be possible to envisage a scenario where the classes are immutable.
Sometimes you add new interface elements to a derived type, thus extending the interface. The new type can still substitute for the base type, but the substitution isn’t perfect because your new methods are not accessible from the base type. This can be described as an is-like-a relationship (my term). The new type has the interface of the old type but it also contains other methods, so you can’t really say it’s exactly the same. For example, consider an air conditioner. Suppose your house is wired with all the controls for cooling; that is, it has an interface that to control cooling. Imagine that the air conditioner breaks down and you replace it with a heat pump, which can both heat and cool. The heat pump is-like-an air conditioner, but it can do more.
Because the control system of your house is designed only to control cooling, it is restricted to communication with the cooling part of the new object. The interface of the new object is extended, and the existing system only knows about the original interface. Once you see this design it becomes clear that the base class “cooling system” is not general enough, and should be renamed to “temperature control system” so it can also include heating—at which point the substitution principle will work. However, this diagram shows what can happen with design in the real world.
When you see the substitution principle it’s easy to feel like this approach (pure substitution) is the only way to do things, and in fact it is nice if your design works out that way. But you’ll find there are times when it’s equally clear you must add new methods to the interface of a derived class (extension). With inspection both cases should be reasonably obvious
Campbell Ritchie wrote:A Stream‑based solution might be eminently suitable for beginners, but we shall have to make them do it the hard way with a loop () because these exercises are for teaching people how to use loops.