CODEWITHSUNDEEP
javaoopaggregationcomposition
heisenberg
heisenberg

Reputation: 1954

Correct way of applying OOP concept of Aggregation

I'm fixing the OOP design of my system because I think the architecture is flawed. I've to rewrite the classes for correct Object Orientation application such as its inheritance, interfaces and aggregation / composition for proper code re-use and relationship.

Say I have Curriculum Class, Subject Class, School Year Class, Year Level Class and I want to apply the concept of HAS-A (Aggregation) as

Curriculum HAS-A Subject Curriculum HAS-A Year Level Curriculum HAS-A School Year Subject HAS-A School Year Subject HAS-A Year Level

Is it enough to do it like:

public class Curriculum {

   SchoolYear schoolYear = new SchoolYear();
   YearLevel yearLevel = new YearLevel();
}

or initialize it using the constructor:

public class Curriculum {

   SchoolYear schoolYear;
   YearLevel yearLevel;

   public Curriculum(SchoolYear sy, YearLevel yl ){
       this.schoolYear = sy;
       this.yearLevel = yl;
   }

or just create an instance of the class within a method like: 

   public DefaultListModel getAllYearLevel(){
       YearLevel yl = new YearLevel();
       return yl.getAllYearLevels();
   }

which I don't think is correct because I don't see the point in recreating the same method just to say Curriculum class HAS-A YearLevel.

How can I implement or apply the HAS-A concept considering Curriculum is composed of year level, subject and school year?

At this point I can't proceed with setters and getters because I don't know which way is correct. I want to be able to properly apply OOP concepts.

I'd appreciate any advice or help.

Upvotes: 0

Views: 203

Answers (2)

Mad Matts
Mad Matts

Reputation: 1116

The "right" concepts for Association, Aggregation and Composition are all about the lifecycles and relationships. So the most important questions are "Which objects can exist independently from which objects?" and "How strong is the relationship between two objects (A-owns-B, A-knows-B, A-composed-of-B)?"

If you want to use the aggregation concept for your classes Curriculum (as an Owner) it would mean Curriculum would have a SchoolYear and also would have a YearLevel, but they all have their own life cycles. So if you destroy Curriculum the other objects would still exist. This can be achieved like your second approach:

public class Curriculum {

   SchoolYear schoolYear;
   YearLevel yearLevel;

   public Curriculum(SchoolYear sy, YearLevel yl ){
       this.schoolYear = sy;
       this.yearLevel = yl;
   }
}

If you want a stronger relationship between them you need the composition concept, where A-is-composed-of B so their life cycles are the same. If you destroy A you also destroy B. This means B can not exist without belonging to A. Like a building is composed of Rooms, but can a Room exist without a building? To map the life cycles you need to create YearLevel and SchoolYear when you instantiate your Curriculum like your first approach.

From my opinion you're fine with aggregation on this one. If you're adding Subjects to your Curriculum you should consider using composition.

Upvotes: 2

Amer Qarabsa
Amer Qarabsa

Reputation: 6574

The second approach seems to be the best of them, first and third approaches seem to have much dependency between the classes which is not recommended.

Note that SchoolYeal and YearLevel should be interfaces or abstracts but not implementation otherwise we will be still stuck in the dependency issue.

Upvotes: 0

Related Questions