Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2006

Tip: Looking for answers? Try searching our database.

Splitting large Objects

Thread view: 
Markus Raab - 10 May 2006 19:39 GMT
I am working on a medium size project which use the composition pattern for
the structure of the data. The composition pattern basically means that
other objects are in a root object, recursively.

The problem we are now facing is that these objects become extremely large.
Following implemenations are in it:
- graphical representation (we are using swing)
- XML output generator
- physical formulas

All these parts are developed by different persons, but all make heavy use
of the tree structure.

One idea is to split it into different objects, having one object just
containing the tree.
class O {GRO g; XMLO x; PHYO p; List<O> others;}

Having the problem that g,x,p need also a list of others. So adding would be
not so nice.

Another idea is to have dozens of pass through functions like
class O {public void func (decl d1, decl d2,...)
       { // doing something with subobjects
       return g.func(d1,d2,...);} // doing implementation stuff
       private GRO g;
}
for functions making use of recursive calling and need subelements.

Any other ideas? How could that be solved elegant?

thank you for any ideas!
Markus

Signature

http://www.markus-raab.org |
                     -o)  |
Kernel 2.6.16.9        /\  |
on a i686             _\_v |

Oliver Wong - 10 May 2006 20:10 GMT
>I am working on a medium size project which use the composition pattern for
> the structure of the data. The composition pattern basically means that
[quoted text clipped - 13 lines]
> containing the tree.
> class O {GRO g; XMLO x; PHYO p; List<O> others;}

   Where's the "contain each other recursively" part? Is GRO, XMLO and PHYO
a subclass of O? If so why? Or more specifically, what is O that it can be a
superclass of GRO, XMLO and PHYO all at the same time?

   Otherwise all you have is a n-ary tree like structure (or perhaps an
arbitrary directed graph), which in itself doesn't strike me as being "too
big". Your problems might be elsewhere; like does O really need to know
about GRO? Perhaps GRO needs to know about O, but not the other way around.
I'm assuming O is some sort of model, and GRO and XMLO are views on this
model.

   - Oliver
Markus Raab - 13 May 2006 18:18 GMT
>> One idea is to split it into different objects, having one object just
>> containing the tree.
>> class O {GRO g; XMLO x; PHYO p; List<O> others;}
>
>     Where's the "contain each other recursively" part? Is GRO, XMLO and
>     PHYO

The contain each other recursively is the List<O> others.

> a subclass of O? If so why?

Yes, we decided to have:
interface Business {}
interface Drawable {}
class Model {Drawable getDraw(); ...}
class ConcreteModel extends Model {Drawable getDraw() {return d;}
       private ConcreteGRO d;...}
class ConcreteGRO extends ConcreteModel implements Drawable {}

> Or more specifically, what is O that it can be
> a superclass of GRO, XMLO and PHYO all at the same time?

Yes, the Model is superclass of all Concrete Models and ConcreteGRO (graphic
objects). So in (business or graphical) code, you have a model, use a get()
function to get the real object and work with it.

>     Otherwise all you have is a n-ary tree like structure (or perhaps an
> arbitrary directed graph), which in itself doesn't strike me as being "too
> big". Your problems might be elsewhere; like does O really need to know
> about GRO? Perhaps GRO needs to know about O, but not the other way
> around. I'm assuming O is some sort of model, and GRO and XMLO are views
> on this model.

Yes, you are completely right. Thank you very much for the input. The idea
to see it as Model is working out very good.

thank you
Markus Raab

Signature

http://www.markus-raab.org |
                     -o)  |
Kernel 2.6.16.9        /\  |
on a i686             _\_v |

Oliver Wong - 13 May 2006 22:00 GMT
>>> One idea is to split it into different objects, having one object just
>>> containing the tree.
[quoted text clipped - 14 lines]
>        private ConcreteGRO d;...}
> class ConcreteGRO extends ConcreteModel implements Drawable {}

   Shouldn't Model and/or ConcreteModel implement Business?

   I don't think Model should have a getDraw() method. Rather, you should
have a view implement Drawable, and you provide it with a model. The view
then queries to the model to figure out how to draw itself.

   - Oliver


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.