Inner classes use

[devu]

Currently I'm working on a class that performs a batch process as per
scheduling for all employees in a company. Being a batch process load
is obviously a huge factor.
The process first needs to calculate the eligibility of each employee
before proceeding to the next stage. I need to cache some of the
employee information if an employee is found eligible for later use in
the next stage.
One option could be a javabean style value object class with all
required attributes and getter setter methods. However I would like to
avoid the overhead of these method calls for say 3000 eligible
employees. A lightweight object where I can access the attributes
directly would help me

I therefore propose an inner class....

class Process {

doEligibility () {
EmpInfo a = new EmpInfo();
a.attrib1 = //set it
a.attrib2 = //set it

//store in hashmap with empID as key

}

private Class EmpInfo { //INNER CLASS
int attrib1;
String attrib2;
.....
}

doProcess {

EmpInfo a = (EmpInfo) map.get("empID");

//use the attributes directly

}
}

Is this wrong/bad design ?? If so, what is a better way to achieve
this ???

[Raymond DeCampo]

devu wrote:

I therefore propose an inner class....

class Process {

doEligibility () {
EmpInfo a = new EmpInfo();
a.attrib1 = //set it
a.attrib2 = //set it

//store in hashmap with empID as key

}

private Class EmpInfo { //INNER CLASS
int attrib1;
String attrib2;
....
}

doProcess {

EmpInfo a = (EmpInfo) map.get("empID");

//use the attributes directly

}
}

Is this wrong/bad design ?? If so, what is a better way to achieve
this ???

If possible, I would suggest making the attributes of EmpInfo final.
When doing this, you must set them in the constructor. For example,

private class EmpInfo
{
public final int attrib1;
public final String attrib2;

public EmpInfo(int a1, String a2)
{
attrib1 = a1;
attrib2 = a2;
}
}

I assume your real classes will have better variable names. :)

This way you are not breaking anything since other classes will only
have read-only access to the attributes. The drawback is that they
cannot change after construction.

Also, there is probably no need to make EmpInfo an inner class, a nested
class will likely do. For example here are your choices:

// Start Main.java

public class Main
{
// Class Inner must be associated with an instance of class Main
// and has access to private things of class Main
private class Inner {}

// Class Nested need not be associated with an instance of Main
// and has access to private things of class Main
private static class Nested {}
}

// Class Another need not be associated with an instance of Main
// and has no special access to class Main
class Another {}

// End Main.java
HTH,
Ray

[perry anderson]

inner classes where designed for a reason, simplicity of code is one. if
reducing class names in your global namespace is of importance to you go
right ahead. sounds to me like you are after reading up on some GoF...

give it a whirl, you'll know soon enough

- perry
devu wrote:

Currently I'm working on a class that performs a batch process as per
scheduling for all employees in a company. Being a batch process load
is obviously a huge factor.
The process first needs to calculate the eligibility of each employee
before proceeding to the next stage. I need to cache some of the
employee information if an employee is found eligible for later use in
the next stage.
One option could be a javabean style value object class with all
required attributes and getter setter methods. However I would like to
avoid the overhead of these method calls for say 3000 eligible
employees. A lightweight object where I can access the attributes
directly would help me

I therefore propose an inner class....

class Process {

doEligibility () {
EmpInfo a = new EmpInfo();
a.attrib1 = //set it
a.attrib2 = //set it

//store in hashmap with empID as key

}

private Class EmpInfo { //INNER CLASS
int attrib1;
String attrib2;
....
}

doProcess {

EmpInfo a = (EmpInfo) map.get("empID");

//use the attributes directly

}
}

Is this wrong/bad design ?? If so, what is a better way to achieve
this ???

[devu]

Raymond DeCampo <rd******@spam.twcny.spam.rr.spam.com.spam> wrote in message news:<JA*******************@twister.nyroc.rr.com>. ..

devu wrote:

I therefore propose an inner class....

class Process {

doEligibility () {
EmpInfo a = new EmpInfo();
a.attrib1 = //set it
a.attrib2 = //set it

//store in hashmap with empID as key

}

private Class EmpInfo { //INNER CLASS
int attrib1;
String attrib2;
....
}

doProcess {

EmpInfo a = (EmpInfo) map.get("empID");

//use the attributes directly

}
}

Is this wrong/bad design ?? If so, what is a better way to achieve
this ???
If possible, I would suggest making the attributes of EmpInfo final.
When doing this, you must set them in the constructor. For example,

Any particular design reason why it ought to be final ??? Since there
are about 10 attributes, that would be one hell of a constructor... :)
private class EmpInfo
{
public final int attrib1;
public final String attrib2;

public EmpInfo(int a1, String a2)
{
attrib1 = a1;
attrib2 = a2;
}
}

I assume your real classes will have better variable names. :)
They do.... :)
This way you are not breaking anything since other classes will only
have read-only access to the attributes. The drawback is that they
cannot change after construction.

Also, there is probably no need to make EmpInfo an inner class, a nested
class will likely do. For example here are your choices:

// Start Main.java

public class Main
{
// Class Inner must be associated with an instance of class Main
// and has access to private things of class Main
private class Inner {}
What advantage would making it static give me in particular
....especially if its private ???

// Class Nested need not be associated with an instance of Main
// and has access to private things of class Main
private static class Nested {}
}

// Class Another need not be associated with an instance of Main
// and has no special access to class Main
class Another {}

// End Main.java
HTH,
Ray

[Raymond DeCampo]

devu wrote:

Raymond DeCampo <rd******@spam.twcny.spam.rr.spam.com.spam> wrote in message news:<JA*******************@twister.nyroc.rr.com>. ..

If possible, I would suggest making the attributes of EmpInfo final.
When doing this, you must set them in the constructor. For example,
Any particular design reason why it ought to be final ??? Since there
are about 10 attributes, that would be one hell of a constructor... :)

It depends on how OO you want to be. The advantage is that clients of
the class can access the data without using a method. Encapsulation is
not broken since the values cannot be changed.

If the class is purely a collection of data, analogous to a struct in C,
you should be OK without the final. You might get into trouble if the
client should be accessing the data via a member but setting it via a
method...

private class EmpInfo
{
public final int attrib1;
public final String attrib2;

public EmpInfo(int a1, String a2)
{
attrib1 = a1;
attrib2 = a2;
}
}

I assume your real classes will have better variable names. :)

They do.... :)

This way you are not breaking anything since other classes will only
have read-only access to the attributes. The drawback is that they
cannot change after construction.

Also, there is probably no need to make EmpInfo an inner class, a nested
class will likely do. For example here are your choices:

// Start Main.java

public class Main
{
// Class Inner must be associated with an instance of class Main
// and has access to private things of class Main
private class Inner {}

What advantage would making it static give me in particular
...especially if its private ???

There are two reasons. First, if the contained class conceptually does
not need an instance of the containing class to exist your code reflects
that relationship. Second, when you make an inner class (i.e.,
non-static), the compiler adds a reference to the outer class to the
inner class. Also, the compiler may add accessors and/or mutators to
the outer class (although this may happen in the case of a nested class
as well). Remember that the JVM has no notion of inner or nested
classes and all the access they get are really compiler tricks.

Mostly I would worry about the conceptual reasons. What is the
relationship between the objects? Should each instance of the class be
associated with an instance of the containing class? For example, it
the containing class is a Customer and the contained class is an Order,
an inner class would be appropriate. OTOH, if the containing class is a
Parser and the contained class is a Token, a nested class would be more
appropriate.

Another reason is that if your outer class has static methods they will
be able to instantiate instances of the nested class.

// Class Nested need not be associated with an instance of Main
// and has access to private things of class Main
private static class Nested {}
}

// Class Another need not be associated with an instance of Main
// and has no special access to class Main
class Another {}

// End Main.java

The most important thing is to understand what you are doing and why you
are doing it. Don't just do something because someone on the Usenet
told you it was the best way. If you don't really understand why or how
it is best for your situation, it probably won't work out.


HTH,
Ray

[Gawnsoft]

On 29 May 2004 03:50:36 -0700, de*******@rediffmail.com (devu) wrote
(more or less):

Currently I'm working on a class that performs a batch process as per
scheduling for all employees in a company. Being a batch process load
is obviously a huge factor.
The process first needs to calculate the eligibility of each employee
before proceeding to the next stage. I need to cache some of the
employee information if an employee is found eligible for later use in
the next stage.
One option could be a javabean style value object class with all
required attributes and getter setter methods. However I would like to
avoid the overhead of these method calls for say 3000 eligible
employees. A lightweight object where I can access the attributes
directly would help me

When I did benchmarkinng in Smalltalk, direct access oy saved 3%
against using accessor methods.

Is using accessors in Java realy much more expensive? Or are you just
wanting to save the 3% for your 3000 instances?
--
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk