aspose file tools*
The moose likes Cattle Drive and the fly likes OOP4 Lookup problems understanding nitpick on branching for Thing type Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » This Site » Cattle Drive
Bookmark "OOP4 Lookup problems understanding nitpick on branching for Thing type" Watch "OOP4 Lookup problems understanding nitpick on branching for Thing type" New topic
Author

OOP4 Lookup problems understanding nitpick on branching for Thing type

margaret gillon
Ranch Hand

Joined: Nov 12, 2008
Posts: 277
    
    2

In OOP4 there are 3 different types of Things: Books, Videos, and Furniture. My nitpicker is saying that I don't need the IF sequence I wrote in the Lookup class to decide which object to call. But -- if each type of thing has different attributes and some Things have more attributes than others then some logic somewhere in the code has to know if the object the user selected is a video, book, or furniture. I understand the inheritance but I don't understand how Lookup can run without branching. I tried sending the user's choice to all objects and letting the object decide if the string belonged to the that type but that is still using switches based on type, it is just putting them in the subclasses instead of letting Lookup decide which object to call.

Hints appreciated.
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9043
    
  10
You have a serial number (id) which belongs to a certain subclass of Thing. Lookup by the serial number that you pass in ...
Subclasses are not switches. A switch was what you used in the 8th assignment (in basic Java). An if/than is not necessary as long as you have a way for the program to know which subclass you are asking for. Although conceptually you might visualize it as "branching", it isn't really. The key is that the subclass inherits some characteristic(s) of the superclass, in this case, a method.

Have you read this story about polymorphism?


JavaBeginnersFaq
"Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
margaret gillon
Ranch Hand

Joined: Nov 12, 2008
Posts: 277
    
    2

You have a serial number (id) which belongs to a certain subclass of Thing. Lookup by the serial number that you pass in ...


I do not know how much detail I can put in this without saying too much. I get a number from the user, I Lookup the serial number in the hashmap that the assignment says to create, the next character in the hashmap row I create defines the type of Thing. I use that character to tell me what is the appropriate subclass to call.

The confusing part is not the assignment but the nitpicker comments that told me NOT to have a statement that branched using the Thing type. This is part of the nitpick...

Let's use polymorphism so we don't need to be worrying about what type of object we have. If each object knows how to output its own description, we should be able to call some output method which will know how to output. Then we aren't messing with maps, checking types, looking up codes, anything.... the JVM takes care of keeping track of who's who and who does what.



Yes, I have read the ranch story about polymorphism. It's a good article. I have used subclasses in other languages for many years and I write class libraries. Just haven't done it in Java.

Thank you for replying!
Carol Murphy
village idiot
Bartender

Joined: Mar 15, 2001
Posts: 1190
margaret gillon wrote:In OOP4 there are 3 different types of Things: Books, Videos, and Furniture. My nitpicker is saying that I don't need the IF sequence I wrote in the Lookup class to decide which object to call.

Hints appreciated.


Maybe your Lookup class should be calling something other than an object?
margaret gillon
Ranch Hand

Joined: Nov 12, 2008
Posts: 277
    
    2

I haved load the hashmap with the keys and values, the values are objects. There are different kinds of objects in the hashmap values. I go to the main routine. In main I can get the hashmap value and the value is an object.

Here is where I am stuck..... How do I call one of that object's methods? As far as I can tell I cannot create a new object and load the hashmap object into it because I do not know what type of object the hashmap object is, I just know it's an object. Because there are multiple object types a call like the following cannot be done because the type of object is unknown
String(mystery object from hashmap) thingDesc = new hashmap.hashmap.get( serialNumber ).getDescription();

What is the syntax to access the object in the hashmap?

TIA


Carol Murphy
village idiot
Bartender

Joined: Mar 15, 2001
Posts: 1190
margaret gillon wrote:I have referenced some other posts on Javaranch regarding this assignment and think I have a conceptual understanding of the fix but I don't know the syntax.

Here is where I am stuck..... How do I call that object's getDescription method ? As far as I can tell I cannot create a new object and load the hashmap object into it because I do not know what type of object the hashmap object is, I just know it's an object. Because there are multiple object types a call like the following cannot be done because the type of object is unknown
String(mystery object from hashmap) thingDesc = new hashmap.hashmap.get( serialNumber ).getDescription();

What is the syntax to access the object in the hashmap?

Syntax is not the issue here. Would inheritance and/or casting be useful in this situation? If you could find a way to call getDescription() on each object in your hashmap using Polymorphism, would you need to create a new hashmap? Try reading about Polymorphism again, and see if you can make the concept work for this situation. Think about solving your problem using inheritance.

TIA


margaret gillon
Ranch Hand

Joined: Nov 12, 2008
Posts: 277
    
    2

If you could find a way to call getDescription() on each object in your hashmap using Polymorphism, would you need to create a new hashmap? Try reading about Polymorphism again, and see if you can make the concept work for this situation. Think about solving your problem using inheritance.


If I could do this, then no I would not need a new hashmap, I would just read the value from the hashmap and output it. The issue I have been trying to resolve most of the weekend is that because the hashmap is static and the thing classes and subclasses are not static the hashmap will not accept being loaded with a call to any of the Thing objects.
margaret gillon
Ranch Hand

Joined: Nov 12, 2008
Posts: 277
    
    2

I have learned that as well as making the Thing classes static I have to make the class methods static as well and then the hashmap will load correctly. Now we'll see if I make it through the nitpick.
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1623
    
  10

If you make the methods static, you don't have state. The point of the assignment is to have state.
You need to have instance methods in order to output the state of the object, not the state of all objects of that type.

Remember:
if you mark a field with static, it means ALL objects of the same type have the SAME state. so:



The reason the compiler says you can't access non-static fields from a static method is because static methods are on the class level.
The class has no idea if there's any objects of its type instantiated or what their state is.
Each instantiated object is in charge of knowing its own state.

That said, the reason you CAN access static fields/methods from nonstatic methods is because, well, that instantiated object is that class type, so he knows all the things his class knows.

Back to our example:




When you do things right, people won't be sure you've done anything at all.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OOP4 Lookup problems understanding nitpick on branching for Thing type
 
Similar Threads
Two Swing Questions
toString method in Object Class
Doubt In MVC..
XSLT/XPath predicates: not(), =, !=
Polymorphism doubt