xterm wroteThat example doesn't highlight the proper use of instanceof, in fact such a solution is frowned upon in OO
i deny , it does for sure,however, generally the usage of it is not very recommended , its much better when you distinguish them by setting ID's for them for example , and distinguishing them with that , but still that is an ideal use of the instanceof dirty op ;)
Syntactically it's correct, practically it works. Theoretically it's incorrect, proper OO dictates that a much better solution would be to apply further constraints to achieve such functionality in a better hierarchical structure with additional Behavior.

Edit: Reply came before your edit.
xterm wroteSyntactically it's correct, practically it works. Theoretically it's incorrect, proper OO dictates that a much better solution would be to apply further constraints to achieve such functionality in a better hierarchical structure with additional Behavior.
yes, theoretically its incorrect, like its always better to use information supported by the class itself, but i'm just kinda explaining some point of using that operator.

The case is similar with Threads, you an use the Thread.stop() method, but it's being deprecated, because it might cause some synch problems and theoretically incorrect, therefore it always recommended to base what's in the run() method on conditions, where certain stuff won't execute if for example a certain boolean , integer or whatever's value changes.
What xterm is trying to tell you is that you need an extra function within the interface of appliance that you derive to do nothing in radio and changes the channel in tv. If it needs arguments, you're probably mixing things and deriving them where they don't belong.
arithma wroteWhat xterm is trying to tell you is that you need an extra function within the interface of appliance that you derive to do nothing in radio and changes the channel in tv. If it needs arguments, you're probably mixing things and deriving them where they don't belong.
i totally don't get you , besides that Appliance isn't an interface, it is an abstract class...
Since when has programming become a dogma? Let everyone program the way he wants to!
Moderation warning: Let's keep focused on the subject at hand, the use of instanceof and why and when should it be avoided. No off-topic please.
Back on topic, I want to allude to the most brief argument against instanceof or any other type identification used in branching.
You have a compiled system that defines an interface that the client will be deriving additional classes from. If you branch on some of your library defined classes you will be stuck when you later want that behavior to be specified by the client for their own classes.
On the other hand, there does not seem to be any case where the instanceof is necessary: you can always remove instanceof from a language and do whatever you please with the same ease or simpler; unless of course you show a certain point of otherwise. The more major issue is that the use of instanceof as a shortcut may later impose a recompile for various assemblies when you need to add behavior for specific usually remote classes. What do you think?
First of all, I found this blog post who makes a pretty good point about the bad use of instanceof.

And on the other hand, does the instanceof method takes inheritance into account?

Example:
public class B extends A 
{
    public B()
    {
       super();
    }
}
what does B isntanceof A returns (true or false)? Is it the same for all languages? Java? C++? PHP?
In C++ it does return true (dynamic_cast<A*>(new B()) doesn't return null). Most probably it works that way in Java as well. I expect it to do so too in PHP (otherwise would call it a broken language).

As for an example of what I was musing about in my last post:
class machine has a set of plugins. A machine has to set on and off different objects. Based on his uni education, he defines a machine to have a list of plugins. Each plugin implements the interface/(base class) plug in. The interface has two functions (turnOn and turnOff). The machine iterates through the list and shuts down or powers up plug ins as it sees suiting based on various criteria.

The program is deployed and works for months without being stopped.

A curious little plugin needs to do recurrent machine-induced house keeping very often. The hasty architect, confined with time, decides to define the method keep and call it from within the machine. However there is no mechanism now for the machine to accommodate this behavior. So he states a little: is this plugin a curious plugin? On true, call the keep method.
To deploy, he has to recompile the machine, and upload both the machine and the plugin.

If he foresaw the need to call other functions or do extra processing that is specific for each type, he should have defined a default no op function in the interface for plugin that gets called for each plugin. To solve the current issue would be as simple as defining whatever keep needs to do by overriding, and uploading that solitary plugin alone.