An OOP-style qustion

Programming Questions

noncom

in Programming Questions • 2 years ago

-all class names in this example are fictious-

I have a class Object, which gets extended by LowObject, HighObject, BigObject, SlowObject and other.. the class body of Object contains a

static int type = 0;

statement which represents it's type for switches in my program. Accordingly I have initiated similar things in all the other classes like

static int type = 1; //for LowObject

static int type = 2; //for HighObject

and so on...

Then when I get an Object, passed as a function parameter, I want my switch to know which type of object is it actually. Objects of class Object never meets in the program, it is merely a reference template. But then, in the switch(passedObject.type) statement, it always says that passedObject.type = 0!!! Actually this seems quite logical to me now.. but still I have this question: how can I effectively determine, which one of the extended classes does the passed object belong to?

If possible, I would not like to use reflection. Is there any memory and time cheap approach for such an issue?

Replies(8)

noncom

Re: An OOP-style qustion

2 years ago

I have found a more simple formulation of the question:

"If class B and class C extend class A and I have an object of type B or C, how can I determine which it instantiates?"

The stress that I want to make is that I do not want to use reflection. Is there any way of doing this by using some methods or variables inside a class?

anchnk

Re: An OOP-style qustion

2 years ago

Why don't you want to use reflexion ?
I'm not an expert in this area but are your object istanciated ?
You could try something like that perhaps :

B testObj;
void setup() {
testObj = new B();
switch(testObj.getType()) {
case 0:
println("Your object was intanciated from class A");
break;
case 1:
println("Your object was intanciated from class B");
break;
case 2:
println("Your object was intanciated from class C");
break;
}
}
void draw() {
}
class A {
protected int type;
A() {
type = 0;
}
int getType() {
return type;
}
}
class B extends A {
B() {
this.type = 1;
}
}
class C extends A {
C() {
this.type = 2;
}
}

nootropic..

Re: An OOP-style qustion

2 years ago

IMHO it's not clear why you do not want to use reflection.

reflection is about that (and more other). in simpler and general case reflection is defined as:

"capacity of an object to have informations about itself" (well, this is really bad definition, if there are some computer scientishere please sorry me, but i wan to be as clear and simple as possible)

in this reference page:

http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Object.html

you can see some method that can help you:

Object.toString()

Object.getClass()

and here:

http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Class.html

Class.getName()

in the last link you can read this note:

The following example uses a Class object to print the class name of an object:
     void printClassName(Object obj) {
         System.out.println("The class of " + obj +
                            " is " + obj.getClass().getName());
     }
 
It is also possible to get the Class object for a named type (or for void) using a class literal (JLS Section 15.8.2). For example:

System.out.println("The name of class Foo is: "+Foo.class.getName());

also if you don't write anything like invoke(), getDeclaredMethods() or more in general

import java.lang.reflect.*;

i think obj.getClass().getName() is a clear example of introspective reflection.

i don't think (but i'm not sure) that you could do something similar in c++

(that is a language without reflection).

if this solution is not good for you, well.. the only way is to declared type in constructor

(or mayebe better an abstract getMyClassType) as anchnk show

by the way antoher solution invles pure (=not overridden) toString() and a bit of parsing

PhiLho

Re: An OOP-style qustion

2 years ago

Reflection should be used rarely, as in general it is slow and less type-safe.
Although a simple getClass() shouldn't be very slow.
Anyway, there is a simple answer to the original request:

void setup()
{
ArrayList<ClassA> al = new ArrayList<ClassA>();
al.add(new ClassA());
al.add(new ClassB());
al.add(new ClassC());
for (ClassA ca : al)
{
println(ca.getType());
}
}
class ClassA
{
int getType() { return 0; }
}
class ClassB extends ClassA
{
int getType() { return 1; }
}
class ClassC extends ClassA
{
int getType() { return 2; }
}

noncom

Re: An OOP-style qustion

2 years ago

Thanks everyone!

Reflection is really slow and uncertain. I feel like java is not a language where I can rely on reflection... The method with type getter, proposed by Phi.lho is the one that works. However, I still find it obscure, why did not work the method when i assigned (and re-assigned for children) a static int 'type' with a common return function...

quarks

Re: An OOP-style qustion

2 years ago

a static int 'type' with a common return function...

Do you realy mean static e.g.
static int type;

If that is the case then that is the problem. A static attribute is one shared by ALL objects of that class there is not a separate one for each object.

phi.lho has provided a good responce but if you want a single return function then we can modify his program to

void setup()
{
ArrayList<ClassA> al = new ArrayList<ClassA>();
al.add(new ClassA());
al.add(new ClassB());
al.add(new ClassC());
for (ClassA ca : al)
{
println(ca.getType());
}
}
class ClassA
{
int type = 0;
int getType() { return type; }
}
class ClassB extends ClassA
{
ClassB() { type = 1; }
}
class ClassC extends ClassA
{
ClassC() { type = 2; }
}

In other words set the type in the constructors of the child classes.

PhiLho

Re: An OOP-style qustion

2 years ago

Well, your solution, quarks, isn't "memory cheap" as wanted by OP. ;-)
Granted, on modern systems, even with millions of instances, it shouldn't take that much memory, but yet...

quarks

Re: Re: An OOP-style qustion

2 years ago

Granted, on modern systems, even with millions of instances, it shouldn't take that much memory, but yet.

very true

perhaps I should change the code to make use of byte instead of int

noncom also talks about having a

... common return function.

My solution provides that and avoids using polymorphism.

As far as I can see both solutions meet his requirements and both solutions are equally valid, as in all programming there is always more than one way of doing something.

Top Reply