Thanks for the article.
This is regarding the Composition section of your Article. In composition relationship, "Lifetime of Part depends on the Lifetime of Whole". In your example, "Project" and "Manager" is not developing a part-whole relation. Your are passing the the "Manager" object in "Project"'s constructor. You are creating the "Manager" object outside the "Project". So, your "Manager" can still survive even "Project" is destroyed.As far as my concept goes, I agree this is a case of "Aggregation" and also might result to a dependency but not a Composition. Please correct me if I am wrong.
Don't think Manager as Physical Entity..consider it as a logical entity..An Employee is Manager only when that Employee is assigned a Project(then employee becomes Manager),and when project is complete(destroyed) then employee's Role as a manager may be revoked.
I spent entire weekend reading all your articles. Gotta say, I loved them. It was time well spent. I spent all my Monday early morning voting, categorizing and bookmarking my favourite ones. Loved the content, became fan of presentation style.
Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.
That's definitely more simplified. I have not see the Wheel class. But the wheel class should also refer the car object so that there is tight bonding or else i can attach the wheel to trucks also which probably is more of aggregation.
Yep, thats exactly the difference (Wheels and engine in my example don't reference the car, nethertheless I say this is composition). I wrote this with C++ in mind, so engine and wheels cannot extend their lifecycle beyond that of the car. They also cannot be moved to another car, only copied.
I agree what you are saying the child reference to parent is not needed and the most important thing is that childs object life time is depedent on parent.
Hi Shivprasad,
It is a nice article, just wanted to share my views on it.
Well, it is not 100% true that inheritance is a parent child relationship. In your example you mentioned "Employee" as parent of "Manager" class, this is partially true.
Inheritance can also not identified with IS-A relationship also, sometimes you have contradictions here. For example: square is a rectangle, yes true if you stretch any of the dimensions square becomes rectangle, that means square IS-A rectangle....and the reverse also true.
No, This is not true neither square is a rectangle nor rectangle is a square. They both are specialized form of shape. Hence, Square is a shape or more precisely square is a specialized form of shape. Rectangle is a specialized form of shape. So in my view - Inheritance is from specialization from generalization. I would prefer to call "Manager" is an specialized from of "Employee" and it is inheritance.
My 3 for the effort you have put to format it in the CP style. It is never fun for me at least to format articles for this site - I struggled with the editor.
I would love to give 4, if this is augmented by UML diagrams.
And by the way, many of my friends stumbled at these topics.
There are many formatting issues, but I could get the essence.
The tags quoted include all the spectrum: beginer - advanced (really this is advanced !!!)
I am suprised that an author with above 100 articles in CP could let these slip away
Quote:
The whole point of OOP is that your code replicates the real world object,
So can't I write generic programming (where I don't have exact object replicates) in OOPs
Quote:
inheritance in this article as its pretty straight forward and I am sure you can get 1000 of articles on the net which will help you in understanding the same.
I typed 'Association vs Aggregation vs compostion' in google and got many more
And it would be nice if there are some supporting UML diagrams as in REAL we will be using them to mention these relationships
Yeah why not then thats functional programming because it does not have classes and object. Did i write something wrong.
Lakamraju Raghuram wrote:
I typed 'Association vs Aggregation vs compostion' in google and got many more
Yeah relatively inheritance is higher in number as the relationship thing is straight forward. Wanted to spend more time discussing association relationship more because of its different thin varities.
Lakamraju Raghuram wrote:
And it would be nice if there are some supporting UML diagrams as in REAL we will be using them to mention these relationships
I did thought about this but then ended up with code images so that people who are juniors can also understand it better. I find the visual code more appealing than UML so that people who do not know UML can grasp it.
Lakamraju Raghuram wrote:
really this is advanced !!!
Its relative. Take a quick discussion about this topic with your developer freinds you will get to know how many of them know these concepts.