Correct way to model a real world object

[Brian Munroe]

I am having trouble modeling a real world object in Java, hopefully
someone can shed some light. I am fairly new to OOP and Java
programming, so hopefully I haven't munged the concepts and terms up
too bad

I have a document, called an Action Plan, that I am trying to turn in
to an object, ActionPlan.

The real world document contains things like a title, description,
start date, etc - these are trivial to turn into attributes of the
ActionPlan object.

However, one section of the Action Plan, called Plan Conditions, won't
work as a primitive attribute. In the real world, the Plan Conditions
section can contain an arbitrary number of Plan Condition, each of
which has it's own attributes like orderNum, name, description, etc.

Here is an ASCII representation of the above paragraph:


-------------------------------------------
Action Plan
-------------------------------------------
Title: Action Plan Title
Description: Test Case Failures
Author: n/a


Plan Conditions
--------------------------------------
OrNum | Name | Description
--------------------------------------
1 Exp 1 n/a
2 Exp 2 n/a
3 Exp 3 n/a

-------------------------------------------

How should I model this one to many relationship? I am thinking I
should have an attribute of ActionPlan be an array of PlanCondition
objects?

I this the correct thing to do? Thanks.

 

[Eric Sosman]

I am having trouble modeling a real world object in Java, hopefully
someone can shed some light. I am fairly new to OOP and Java
programming, so hopefully I haven't munged the concepts and terms up
too bad

I have a document, called an Action Plan, that I am trying to turn in
to an object, ActionPlan.

The real world document contains things like a title, description,
start date, etc - these are trivial to turn into attributes of the
ActionPlan object.

However, one section of the Action Plan, called Plan Conditions, won't
work as a primitive attribute. In the real world, the Plan Conditions
section can contain an arbitrary number of Plan Condition, each of
which has it's own attributes like orderNum, name, description, etc.

[...]

How should I model this one to many relationship? I am thinking I
should have an attribute of ActionPlan be an array of PlanCondition
objects?

I this the correct thing to do? Thanks.

You could use an array, which is convenient if you
know the number of PlanConditions in advance but less so
if you discover the number as you go along. You might
also consider using a java.util.List or java.util.Set,
or even a java.util.Map -- it depends on what you need
to do with the collection of PlanConditions.

 

[Brian Munroe]

You could use an array, which is convenient if you
know the number of PlanConditions in advance but less so
if you discover the number as you go along. You might
also consider using a java.util.List or java.util.Set,
or even a java.util.Map -- it depends on what you need
to do with the collection of PlanConditions.

Oh, that's right I forgot about an Array not being dynamic, noted, but
you didn't have any comment about the way I am modeling it, so I can
safely assume that my thinking is correct?

thanks

-- brian

 

[Oscar kind]

I have a document, called an Action Plan, that I am trying to turn in
to an object, ActionPlan.

The real world document contains things like a title, description,
start date, etc - these are trivial to turn into attributes of the
ActionPlan object.

However, one section of the Action Plan, called Plan Conditions, won't
work as a primitive attribute. In the real world, the Plan Conditions
section can contain an arbitrary number of Plan Condition, each of
which has it's own attributes like orderNum, name, description, etc.

Here is an ASCII representation of the above paragraph:

-------------------------------------------
Action Plan
-------------------------------------------
Title: Action Plan Title
Description: Test Case Failures
Author: n/a

Plan Conditions
--------------------------------------
OrNum | Name | Description
--------------------------------------
1 Exp 1 n/a
2 Exp 2 n/a
3 Exp 3 n/a

-------------------------------------------

How should I model this one to many relationship? I am thinking I
should have an attribute of ActionPlan be an array of PlanCondition
objects?

Because the number of conditions is not fixed, an array is not very
suitable IMHO. It can be done though, especially if the number of
conditions is known when you create the object.

But since that is generally not the case in situations I encounter, I use
a Collection (in this case a List): you get a list of conditions, ordered
in the order you read them, or sort them.

To do this, you create the collection when you create the ActionPlan. An
example:

public ActionPlan {
List conditions;

public ActionPlan() {
this.conditions = new ArrayList();
}

public void addCondition(Condition cond) {
this.condition.add(cond);
}
}

 

[Brian Munroe]

Because the number of conditions is not fixed, an array is not very
suitable IMHO. It can be done though, especially if the number of
conditions is known when you create the object.

But since that is generally not the case in situations I encounter, I use
a Collection (in this case a List): you get a list of conditions, ordered
in the order you read them, or sort them.

To do this, you create the collection when you create the ActionPlan. An
example:

[snip]

This is all great stuff, appreciate it! I think I am finally starting
to 'get' OOP.

One question though..before I read your post, I was using an ArrayList,
and you mentioned a List. Is a List more effective then an ArrayList?

thanks

-- brian

 

[R.F. Pels]

How should I model this one to many relationship? I am thinking I
should have an attribute of ActionPlan be an array of PlanCondition
objects?

Possibly. That depends on wether you may add the same PlanCondition to the
array more than one time. Read up on container classes. The answer is there
to be found.

Another approach can be that a Document consists of a set of
DocumentElements, and that you derive specific elements from the
DocumentElement class, for example, DocumentTitle, DocumentDescription,
DocumentStartDate and DocumentPlanCondition. That seems like overkill, but
you might investigate the Visitor pattern and see what possibilities this
creates.

 

[Eric Sosman]

One question though..before I read your post, I was using an ArrayList,
and you mentioned a List. Is a List more effective then an ArrayList?

List is an interface, a specification of a group of
methods that provide (in this case) the operations one
wants to perform with a "list" of things. The interface
describes what the methods should do, but says nothing
about how their tasks are to be done.

ArrayList, LinkedList, and Vector are classes that
implement the List interface. (There's also AbstractList,
but I have a notion you're not quite ready for it yet;
see below). Each of these implements the methods List
calls for, but each does so in its own way, with different
trade-offs. For example, it's really easy to find the
Nth element of an ArrayList, but harder to do so with a
LinkedList. On the other hand, it's really easy to insert
a new element in the middle of a LinkedList, harder to do
so with an ArrayList.

Recommendation: Use List everywhere except at the
point when you actually create the list. At that point,
create an ArrayList as `List list = new ArrayList()'.
If you later decide that a LinkedList would be better,
just change to `List list = new LinkedList()' and all
the rest of your code will continue to work without change.

Concerning the "not quite ready" remark: If you don't
yet understand what an interface is, your questions probably
belong in comp.lang.java.help rather than here. c.l.j.h.
is geared towards beginners' questions; c.l.j.p. sort of
assumes you already have a reasonable grasp of the language.
There's a certain amount of overlap -- but the notions of
"interface" and "implementing an interface" are pretty
fundamental; you'd do well to master them before going much
further. Followups set.