Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Consolidating java objects

Reply
Thread Tools

Consolidating java objects

 
 
Dave
Guest
Posts: n/a
 
      10-16-2006
I have been a J2EE developer since Jan 2000, and have been on a number
of projects. However, with most of the projects we have been able to
keep the number of objects that can be used fairly small, to around 50
at the most and re-used or inherited from the core group of objects.

I am now on a project where the number of objects keeps growing with
each development release. It went from 250 to 277 objects in the last
release. There are so many objects that developers no longer look to
see if an object will work for them, they just create a new one from
scratch.

Some objects are small, around 4-10 fields, others are much larger
(dozens of fields) and some inherit from other objects. I cannot come
up with a good way to find the similar objects so that the number can
be brought back under control. I also cannot come up with a good way
for developers to find objects that have what they need, since they
have spread the objects out from the initial framework package into
packages and modules all through the code. A way to compare objects
would also be very helpful.

The project is larger, around 15-25 developers at any time, but I am
tasked with figuring out a solution to this problem. I have tried a
spreadsheet, but it grows too big in a short time, and I can't see more
than 1-3 objects on the screen at once, when I need to be able to see
more of them. I also tried writing an XML document but it was too
hard. Javadoc generates too many files for this to be useful as well.


I have found several examples where the object wasn't needed and a
framework object could be used. I've also found cases where the object
simply extended another object and then didn't add any additional
fields. There have also been cases where the same set of fields show
up in object after object.

Does anyone have any ideas of tools or methodologies to use that could
help? I tried google and yahoo but didn't have any luck. Any ideas
would be greatly appreciated.

Thanks in advance

 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      10-16-2006
Dave wrote:
> I have been a J2EE developer since Jan 2000, and have been on a number
> of projects. However, with most of the projects we have been able to
> keep the number of objects that can be used fairly small, to around 50
> at the most and re-used or inherited from the core group of objects.
>
> I am now on a project where the number of objects keeps growing with
> each development release. It went from 250 to 277 objects in the last
> release. There are so many objects that developers no longer look to
> see if an object will work for them, they just create a new one from
> scratch.


Are you actually talking about objects? It seems more that you mean
"classes" instead.

> Some objects are small, around 4-10 fields, others are much larger
> (dozens of fields) and some inherit from other objects. I cannot come
> up with a good way to find the similar objects so that the number can
> be brought back under control. I also cannot come up with a good way
> for developers to find objects that have what they need, since they
> have spread the objects out from the initial framework package into
> packages and modules all through the code. A way to compare objects
> would also be very helpful.


What about documentation? Is there proper JavaDoc and package
documentation?

> The project is larger, around 15-25 developers at any time, but I am
> tasked with figuring out a solution to this problem. I have tried a
> spreadsheet, but it grows too big in a short time, and I can't see more
> than 1-3 objects on the screen at once, when I need to be able to see
> more of them. I also tried writing an XML document but it was too
> hard. Javadoc generates too many files for this to be useful as well.


The question is what is the criteria for identifying similar classes?
If it is just methods or fields that seems pretty easy - even with
reflection. But if you are talking about semantics or want to compare
method behavior then you'll have a difficult task to do.

> I have found several examples where the object wasn't needed and a
> framework object could be used. I've also found cases where the object
> simply extended another object and then didn't add any additional
> fields. There have also been cases where the same set of fields show
> up in object after object.
>
> Does anyone have any ideas of tools or methodologies to use that could
> help? I tried google and yahoo but didn't have any luck. Any ideas
> would be greatly appreciated.


First of all 270 classes is not really much. You might be more
successful with a social solution instead of a technical one. For
example, you can improve communication by having developers present what
they developed so others know about. Or you install a process that must
be followed during creation of new classes and which might ensure people
find and use solutions done by others etc.

Kind regards

robert
 
Reply With Quote
 
 
 
 
Daniel Dyer
Guest
Posts: n/a
 
      10-16-2006
On Mon, 16 Oct 2006 20:29:16 +0100, Dave <(E-Mail Removed)> wrote:

> I have been a J2EE developer since Jan 2000, and have been on a number
> of projects. However, with most of the projects we have been able to
> keep the number of objects that can be used fairly small, to around 50
> at the most and re-used or inherited from the core group of objects.
>
> I am now on a project where the number of objects keeps growing with
> each development release. It went from 250 to 277 objects in the last
> release. There are so many objects that developers no longer look to
> see if an object will work for them, they just create a new one from
> scratch.


Do you mean classes rather than objects?

250 classes is not that big a project (unless they are all huge monolithic
things), especially for such a large team.

> Some objects are small, around 4-10 fields, others are much larger
> (dozens of fields) and some inherit from other objects. I cannot come
> up with a good way to find the similar objects so that the number can
> be brought back under control. I also cannot come up with a good way
> for developers to find objects that have what they need, since they
> have spread the objects out from the initial framework package into
> packages and modules all through the code. A way to compare objects
> would also be very helpful.


This really comes down to organisation and communication. If you can
reorganise your packages, and which classes are in them, to be more
logical it should make things easier to locate. Ideally, you'd get the
whole team to agree on how things are to be arranged, then everybody knows
how things are supposed to be organised.

> The project is larger, around 15-25 developers at any time, but I am
> tasked with figuring out a solution to this problem. I have tried a
> spreadsheet, but it grows too big in a short time, and I can't see more
> than 1-3 objects on the screen at once, when I need to be able to see
> more of them. I also tried writing an XML document but it was too
> hard.


Something like a UML class diagram would probably be more appropriate, it
will also show the relationships between classes. Many tools will
generate a diagram for you from source code (though it may need some human
input to tidy it up).

Anything that exists in isolation from the codebase is going to be awkward
to maintain and will quickly become out-of-date and useless.
Reports/diagrams that can be automatically generated from the code would
be preferable.

> Javadoc generates too many files for this to be useful as well.


There are lots of configuration options and custom doclets to control the
kind of output it gives you.

> I have found several examples where the object wasn't needed and a
> framework object could be used. I've also found cases where the object
> simply extended another object and then didn't add any additional
> fields. There have also been cases where the same set of fields show
> up in object after object.


Again this is communication. It sounds like your developers are working
in isolation, trying to get their little piece done without considering
the bigger picture. Perhaps code reviews would help?

Dan.

--
Daniel Dyer
http://www.uncommons.org
 
Reply With Quote
 
Dave
Guest
Posts: n/a
 
      10-16-2006
Thank you for your answers.
When a class has private fields, getters and setters and no logic, I
call this an object. It is certainly a class.

There are a couple of other problems that I have not mentioned. Half
of the project is offshored to India, and the other half of the
development is done in-house by additional Indian developers and then I
have come into the picture. I would be staying long term and
maintaining what is being written now in addition to doing further
development.

They are not doing any documenting, adding JavaDoc, etc... When asked
to help document their objects so we could see what their objects are
doing/used for, one of the team leaders outright refused and said they
didn't have time for that. Since my boss apparently allowed this,
there won't be any documentation for that.

We have plenty of instances where there are 3-4 classes (objects) named
exactly the same, but with completely different fields and each is in a
completely different module or package. How would anyone know which
student class to use without any documentation or JavaDoc?

Reorganizing is easier said then done. There may only be around 280
classes (objects), but we have a few hundred JSPs, a very large number
of services and data access objects that all depend on them. Everyone
is acting fairly independently and without documentation they are
creating classes rather than re-using.

Can you recommend any UML tools that would do this?
Also, I am working towards doing code reviews. Unfortunately, it is
only because I am pushing for it and it will be coming fairly late into
the development process.

 
Reply With Quote
 
Mark Jeffcoat
Guest
Posts: n/a
 
      10-16-2006
"Dave" <(E-Mail Removed)> writes:

> Some objects are small, around 4-10 fields, others are much larger
> (dozens of fields) and some inherit from other objects. I cannot come
> up with a good way to find the similar objects so that the number can
> be brought back under control. I also cannot come up with a good way
> for developers to find objects that have what they need, since they
> have spread the objects out from the initial framework package into
> packages and modules all through the code. A way to compare objects
> would also be very helpful.
>



I suspect that if I looked at your project, I'd suggest breaking
up some of the larger classes (dozens of fields?) into smaller
classes with fewer responsibilities.

That's clearly not the direction you want to go.

What difficulty is having too many classes causing? Alternately,
what Good Thing would you gain by having fewer classes that you
don't have now?


--
Mark Jeffcoat
Austin, TX
 
Reply With Quote
 
Daniel Dyer
Guest
Posts: n/a
 
      10-16-2006
On Mon, 16 Oct 2006 21:45:27 +0100, Dave <(E-Mail Removed)> wrote:

> Thank you for your answers.
> When a class has private fields, getters and setters and no logic, I
> call this an object. It is certainly a class.
>
> There are a couple of other problems that I have not mentioned. Half
> of the project is offshored to India, and the other half of the
> development is done in-house by additional Indian developers and then I
> have come into the picture. I would be staying long term and
> maintaining what is being written now in addition to doing further
> development.
>
> They are not doing any documenting, adding JavaDoc, etc... When asked
> to help document their objects so we could see what their objects are
> doing/used for, one of the team leaders outright refused and said they
> didn't have time for that. Since my boss apparently allowed this,
> there won't be any documentation for that.


OK, this doesn't sound like much fun.

> We have plenty of instances where there are 3-4 classes (objects) named
> exactly the same, but with completely different fields and each is in a
> completely different module or package. How would anyone know which
> student class to use without any documentation or JavaDoc?


The short answer is, without documentation, you don't know. If there are
two classes with the same name and neither is documented, the only real
solution is to document them somehow.

There are tools for finding duplicate code in projects (see
http://checkstyle.sourceforge.net/co...uplicates.html) but it doesn't
sound like these will be much help.

> Reorganizing is easier said then done. There may only be around 280
> classes (objects), but we have a few hundred JSPs, a very large number
> of services and data access objects that all depend on them. Everyone
> is acting fairly independently and without documentation they are
> creating classes rather than re-using.


An IDE with good refactoring support (such as IDEA) should be able to
resolve all of these dependencies for you when doing the reorganisation.
Just make sure everybody has checked-in their changes, declare a temporary
code freeze and then checkout the code on one machine, make the necessary
changes and commit them (in theory).

> Can you recommend any UML tools that would do this?


Most of the ones you have to pay for (i.e. Rational Rose, Together,
etc.). I think even the Open Source ArgoUML (http://argouml.tigris.org)
does it (if not, it's commercial cousin Poseidon -
http://www.gentleware.com - will do).

> Also, I am working towards doing code reviews. Unfortunately, it is
> only because I am pushing for it and it will be coming fairly late into
> the development process.


Good luck. I was on a project last year where development took place in
three different timezones, so I know that remote coordination can be very
difficult. I'm glad that my current project team are all in the same room
as me. Even the guy who runs a separate project that we have to interface
with sits next to me.

Dan.

--
Daniel Dyer
http://www.uncommons.org
 
Reply With Quote
 
Mark Jeffcoat
Guest
Posts: n/a
 
      10-16-2006
"Dave" <(E-Mail Removed)> writes:

> Thank you for your answers.
> When a class has private fields, getters and setters and no logic, I
> call this an object. It is certainly a class.



That this sort of class should exist at all is a red flag--
it usually indicates you've got a lot of old-school procedural
programmers who are just faking the whole OO thing. Using
getters and setters, instead of just admitting it's a C-style
struct and making all the fields public, means they're probably
not aware of it.

(Of course, "old-school procedural programmers" got a lot
of good software written. It's just useful to know who you're
dealing with, now that a lot of them have migrated to Java.
In syntax, at least.)

>
> They are not doing any documenting, adding JavaDoc, etc... When asked
> to help document their objects so we could see what their objects are
> doing/used for, one of the team leaders outright refused and said they
> didn't have time for that. Since my boss apparently allowed this,
> there won't be any documentation for that.


Another red flag, as you're well aware.

>
> We have plenty of instances where there are 3-4 classes (objects) named
> exactly the same, but with completely different fields and each is in a
> completely different module or package. How would anyone know which
> student class to use without any documentation or JavaDoc?


Student class? Is that the domain model slipping out?

If the fields are different, and there's no logic, there's
no real commonality between the classes. This is not a sign
that you have too many classes, but that the separation between
modules isn't doing enough to help manage the project's complexity.


> Reorganizing is easier said then done. There may only be around 280
> classes (objects), but we have a few hundred JSPs, a very large number
> of services and data access objects that all depend on them. Everyone
> is acting fairly independently and without documentation they are
> creating classes rather than re-using.


Another red flag. That is, that no one's looking for opportunities
to build better abstractions.


>
> Can you recommend any UML tools that would do this?
> Also, I am working towards doing code reviews. Unfortunately, it is
> only because I am pushing for it and it will be coming fairly late into
> the development process.



You don't need a new tool. You've got a broken development
process. Someone in project management must recognize this--that
seems to be why you were brought in.

Code reviews won't help unless your team has some basic agreement
on the difference between good code and bad. For instance, your
definition of good code includes "has documentation", and it seems
that most of the rest of the team disagrees, or just doesn't care.

You're in a tough spot. If everyone continues working as they
are right now, with their current values, they will continue
to get the same results, no matter what new tools you introduce,
UML and otherwise.

(Yeah--no actual Java programming in this post, but I've spent
the last year on a project that once had very similar problems.)

--
Mark Jeffcoat
Austin, TX
 
Reply With Quote
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      10-16-2006
Dave wrote:
> I am now on a project where the number of objects keeps growing with
> each development release. It went from 250 to 277 objects in the last
> release. There are so many objects that developers no longer look to
> see if an object will work for them, they just create a new one from
> scratch.
>
> Some objects are small, around 4-10 fields, others are much larger
> (dozens of fields) and some inherit from other objects. I cannot come
> up with a good way to find the similar objects so that the number can
> be brought back under control. I also cannot come up with a good way
> for developers to find objects that have what they need, since they
> have spread the objects out from the initial framework package into
> packages and modules all through the code. A way to compare objects
> would also be very helpful.


As other has said then this is not that many classes.

That of course does not prevent it from being a mess.

But I doubt any tools will solve the problems.

You will simply have to look at the classes, see where
they are used, see what they contain and do the refactoring
the hard way.

Arne

 
Reply With Quote
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      10-17-2006
Mark Jeffcoat wrote:
> "Dave" <(E-Mail Removed)> writes:
>> Thank you for your answers.
>> When a class has private fields, getters and setters and no logic, I
>> call this an object. It is certainly a class.

>
> That this sort of class should exist at all is a red flag--
> it usually indicates you've got a lot of old-school procedural
> programmers who are just faking the whole OO thing. Using
> getters and setters, instead of just admitting it's a C-style
> struct and making all the fields public, means they're probably
> not aware of it.


Or they may have read a book about J2EE (including the
section about DTO pattern).

Arne
 
Reply With Quote
 
Mark Jeffcoat
Guest
Posts: n/a
 
      10-17-2006
Arne Vajh°j <(E-Mail Removed)> writes:

> Mark Jeffcoat wrote:
>> "Dave" <(E-Mail Removed)> writes:
>>> Thank you for your answers.
>>> When a class has private fields, getters and setters and no logic, I
>>> call this an object. It is certainly a class.

>>
>> That this sort of class should exist at all is a red flag--
>> it usually indicates you've got a lot of old-school procedural
>> programmers who are just faking the whole OO thing. Using
>> getters and setters, instead of just admitting it's a C-style
>> struct and making all the fields public, means they're probably
>> not aware of it.

>
> Or they may have read a book about J2EE (including the
> section about DTO pattern).
>


I agree-- in one version of my post, I included as a footnote
the idea that the dev team may be something clever to
deal with the accidental difficulties of J2EE.

I deleted it. I don't see any evidence from the original
poster that his team is making sophisticated decisions, and
I decided not to confuse the issue.

(No insult intended. I don't think your point is wrong, I'm
just moving toward the idea that talking about "patterns"
to people who haven't gotten a good grip on the basics may
actually be counter-productive.)

--
Mark Jeffcoat
Austin, TX
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Consolidating emails philo Computer Support 6 01-22-2007 08:15 PM
consolidating bunch of HTML pages lbrtchx Java 1 06-02-2006 06:07 PM
Consolidating multiple CNR Severs blindpirate Cisco 0 04-05-2006 08:49 PM
Consolidating images in one folder in wwwroot =?Utf-8?B?cG11ZA==?= ASP .Net 5 04-05-2005 10:15 PM
Consolidating Sites - DNS Implications Guadala Harry ASP .Net 1 02-06-2004 02:18 AM



Advertisments