Where should I store objects in my design

**santeron** · 03-09-2012, 03:21 PM

Hello guys,

I have a system that needs to store various kinds of information such as users, publications, meetings etc. I have various objects describing that sort of information but I am having a hard time choosing where to store the objects inside the design.

Quick overview of the system: I have a SystemAdmin who registers users. I have a RegisteredUser who makes publications and meetings. I have Publications and Meetings.

Where should I store the objects created by all these classes? Where should I store the "RegisteredUser" or the "Publication"? Should I use a "super" class with a bunch of collection objects or is it a bad design?

I would like to avoid using a DBMS, but if you think it would get messy otherwise, I can give it a go. Thanks

**Eranga** · 03-09-2012, 03:32 PM

Arrays!

**santeron** · 03-09-2012, 03:36 PM

I know how to store them, I don't know where. Having a control class that instantiates everything and stores everything makes any sense or is it a wrong design decision?

**Eranga** · 03-09-2012, 03:43 PM

What I am doing to keep the separation in different classes itself and retrieve when required.

**santeron** · 03-09-2012, 03:47 PM

So having a "main" class with 2-3 collection objects in it to keep all the data in one place and accessor methods for those collections seems a good idea for you?

**Sierra** · 04-11-2012, 12:57 PM

I would say: Open your mind about what is the structure of your application. E.g. you can have the application for planning inside a company - you could have Company as superclass - each company has Employees and Projects, Projects may organize Meetings and have Publications... just a hint. You need a big picture, and even then sometimes there is more than one place where items/objects may have their home.
So go and think of a tree like structure and maybe how objects relate to each other, just my 2 cents.

**santeron** · 04-11-2012, 01:07 PM

Originally Posted by Sierra

I would say: Open your mind about what is the structure of your application. E.g. you can have the application for planning inside a company - you could have Company as superclass - each company has Employees and Projects, Projects may organize Meetings and have Publications... just a hint. You need a big picture, and even then sometimes there is more than one place where items/objects may have their home.
So go and think of a tree like structure and maybe how objects relate to each other, just my 2 cents.

Thanks for the reply Sierra. I have done the UML class diagrams and I have done what you said. So I basically made the department class more or less a controller which holds collections of the other classes and provide functionality to use them :)