• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

instanceOf operator

 
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Is this approach "bad"? why?

Source:
http://www.javapractices.com/topic/TopicAction.do?Id=31
(Example modified for java. //PRIVATE classes made public here.) <---
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is bad because if you add another Animal class to the program, you have to modify the doSomething method too.

When you use polymorphism (getting rid of using the instanceof operator) you would not have to change the doSomething method when you add another animal, and it would still work correctly.

Suppose that you have a large and complicated system and a new programmer gets assigned the task of adding a new Animal class. The new programmer could easily miss the fact that he must also change the doSomething method. Especially if this construction is used in multiple places in the software, it's hard to be sure that you've added support for the new Animal class in all places where it's necessary. So, using the instanceof approach leads to a code maintenance problem.
 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jesper is right. The usual way to do this is to have the base class (Animal) be abstract and have an abstract method that all non-abstract sub classes then must implement:
 
Akhilesh Trivedi
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:Jesper is right. The usual way to do this is to have the base class (Animal) be abstract and have an abstract method that all non-abstract sub classes then must implement:



So I will have to take-off all my constructors from Animal then(in case I have them)?
 
Rob Spoor
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't understand your question.
 
Akhilesh Trivedi
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When we make a class abstract, we can not instantiate it, right? So previously if I had constructors for my class Animal, I will have to remove them because now I am making it abstract.
 
Rancher
Posts: 1776
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No need to remove the constructor - the abstract class might use them to store some generic information.

In below code the Animal has a name regardless of whether its a dog or a cat. So the common variable shall be declared in the base class.

 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Remember that a constructor doesn't actually instantiate an object. It initialises an object that's been instantiated. So there's no reason for an abstract class not to use one, and (as John's example shows) it may be needed to initialise data belonging to the abstract class.
 
Ranch Hand
Posts: 287
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As we know moving is not just restricted to animals, let me try another solution. isn't this any better?

 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you are going to use interface inheritance then you should simply consider using the strategy pattern and create 'Interface' moveable with concrete implemenations in fish..spider..etc.
http://en.wikipedia.org/wiki/Strategy_pattern

To take advantage of the composition the animal class should be like this..


 
Akhilesh Trivedi
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Only if you could have different names. moveable (it is instance variable, it is local variable and it is also method name)



If i am getting it right, movebale is supposed to be another inteface/class.
 
Yogesh Gnanapraksam
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah you are right...moveable is supposed to be another interface ..
class Animal {

private moveable mv; //<--

public Animal(moveable m)
{
this.mv = m;

}

public void performMove()
{

mv.move();

}

}

The first method is actually a constructor. that is why it did not have the return type..i made a mistake in naming it.
Just follow the strategy pattern.
 
reply
    Bookmark Topic Watch Topic
  • New Topic