class aggregations question

[maybnxtseasn]

www.learncpp.com/cpp-tutorial/103-aggregation

In the example given they state a department can have a teacher and if a department goes out of scope/deconstructs it doesnt destroy the teacher that was in that department. for example in real life departments at different school change names,get added,and get deleted all the time. Just because a department gets deleted doesn't mean they also fire/delete the teachers. My question is i understand this perfectly fine( or so i think as i just described ) but the problem i see with aggregation compositional classes is the following. Say you have the same example given from the website posted above but instead departments have MULTIPLE teachers.

How are you supposed to deal with teachers that are no longer hired? do you just check the address of the pointer and if it's set to 0 you know you need to remove them from the department?
Also
You will have tons of dynamically allocated teachers. How do you manage all of them will i need to create another class in order to do so? if i had done regular class composition this wouldn't have been a problem correct and only 1 class would be needed?

[mrnutty]

>>How are you supposed to deal with teachers that are no longer hired?

You would presumably have a function to fire teacher:

class Department
{
private:
    Teacher *m_pcTeacher; // This dept holds only one teacher
public:
    Department(Teacher *pcTeacher=NULL)
        : m_pcTeacher(pcTeacher)
    {
    }
  void fireTeacher(const Teacher* t){ 
     if( t == pcTeacher){  //if you know teacher has a unique value, say SocialSecurityId, then you can delete it based on that or other criteria. 
         pcTeacher = 0; 
    } 
  }
};

>>You will have tons of dynamically allocated teachers. How do you manage all of them

You manage them with a container that represents a list of teachers

>>if i had done regular class composition this wouldn't have been a problem correct and only 1 class would be needed?

Think of composition as representing a list of object as a whole. For example, you can think of a class called Car as a whole, even though it has different objects in it like, tires, body...etc. But you still treat the Car as a whole, removing the car, repairing the car, selling the car and so on.

Conceptually, in that example, it makes more sense to remove teachers one by one. Certain teachers stays, others gets fired, although it may be possible, if the Department declared bankruptcy then all teachers would be removed.

[mike_2000_17]

If you are interested in such matters, I suggest you read my tutorial on ownership relations between objects in a software architecture.

As a note, I don't like the term "aggregation" (in OOP) because it is fundamentally (in English) a synonym for "composition", both sharing the same definition "The combining of distinct parts or elements to form a whole.".

Also, in that tutorial you refer to, the lack of a clear specification of the ownership of the object is big problem, which leads to the problematic that you are describing. The tutorial just says that the aggregate class doesn't own its subobject, which begs the obvious (and unanswered) question: "who owns it?".

Furthermore, the author leaves a vague open-question at the end that also refers to the problematic you described. He says: "This is generally handled by ensuring other pointers or references to those subobjects exist when the aggregate is destroyed.". Read my tutorial for the answer(s), because that problem is really the central issue, the aggregation "technique" itself is trivial.

Finally, the author's use (and implied recommendation) of raw pointers is also very problematic. Raw pointers are fundamentally ambiguous about ownership, and should thus be rarely used (apart from being encapsulated in the implementation details of a class or data structure).

Now, for your questions:

>> How are you supposed to deal with teachers that are no longer hired?

Teachers should still belong somewhere, or not exist. Either you have a more general group of teachers, like the "academic staff" of a university where teachers would exist as long as they have some employment at the university, or some association of all teachers including does who are currently unemployed. Or, the teachers could simply disappear as soon as they have no job. This all depends on your application, whether you need to keep unemployed teachers around for later re-hire or transfer, or if you don't care. The point of the "aggregation" is that the aggregate class doesn't have to make that decision, so, in this case, the "department" class could be used in any framework (one that keeps unemployed teachers, one that allows teachers to teach in multiple departments, or a simple one department software where teacher objects disappear if they are fired from the department or if the department disappears). It just makes the department class more flexible (multi-purpose).

>> do you just check the address of the pointer and if it's set to 0 you know you need to remove them from the department?

No. Normally, you should use a smart-pointer for this purpose, in this case, you should use the shared_ptr class (either in boost:: , std::tr1:: or std:: depending on your choice of smart-pointer library). See my tutorial for more details.

>>You will have tons of dynamically allocated teachers. How do you manage all of them will i need to create another class in order to do so?

You might or might not need another class to manage them. When you use shared_ptr instead of raw pointers, they are self-managed because they keep a reference count and the pointed-to object is automatically destroyed when the reference count goes to zero, so you don't need a managing class to handle the deletion of unused objects. In many cases, however, you will want to have a managing class, commonly referred to as a "resource broker", my tutorial also describes the basic design of such a class (in the context of managing 3D models in a computer game software).

>> if i had done regular class composition this wouldn't have been a problem correct and only 1 class would be needed?

Regular composition does not apply to the same situation, so you would avoid a "problem" by introducing a serious flaw in your design. And also given the aforementioned use of shared_ptr , that "problem" really isn't a problem at all.

[maybnxtseasn]

TO: Firstperson

in other words...

Container Class is the manager that deals with the allocation/deallocation of teacher objects and keeps track of them.( e.i. allocation when a new teacher is hired, deallocation when a teacher is fired )

Aggregation class is used to work with the already allocated objects( which are managed in the container class ). When they are not needed they are simply removed from use from the class without allocating or deallocating them internally.

Summary
--------
Aggregates keep you from creating duplicates of already created objects and let you actually WORK with the ACTUAL object in memory instead of a fake object created when being used. This provides a link to the actual object you want to work with. You can think of aggregrations as pass by reference instead of pass by value?

If Regular class composition had been used then the following problems would occur
1.) You would create "copy's" of the actuall objects therefore wasting memory
2.) you would not actually be working with the ACTUAL object. Therefore there is no link to each actual unique teacher. Therefore if a teacher gets fired you would have to have the class manually remove the teacher that got fired instead of being able to check if that teacher still has memory allocated to it

is my understanding better or not? thanks

TO: Mike
I will read your post and information once i am able to get home :) thanks

[maybnxtseasn]

TO: Mike
Looks like a very awesome tutorial. I will definately take a look at it. I will tell you it looks far more advanced them my current programming experience. I'm curious if u have any recommendations on sites/books for a beginner to learn up on certain design concepts