This is an excellent example of Aggregation, not of Composition! In Composition the PC is the owner of its parts (motherboard,case, monitor) to enforce life-long dependency , so the motherboard, case and monitor objects should never exist as stand alone objects outside of the PC object, since this would mean you still would have a reference to them, even if you would mark the PC object for deletion (by setting: thePC = null;)
the fun thing is i am taking your course on Udemy and i did not understand it there, then i said maybe i can find anything on youtube that can help, then i found you lol .. the same video that i did not understand earlier.
do you make sure this is Composition ? if it compostion why dont you try add line pc = null and see whether or not Case ,Monitor and Motherboard already delete ?
There is something that I can't undestand. For instance if the PC object is composed by a Case object, I think that you should have a new Case() sentence inside the PC constructor. The way you implemented it, creating the Case object in the main and passing the reference to the set method, looks more like aggregation than composition to me.
.Thank You .You just described a great example greatly but for suggestion, I think it might be better to make it simpler ... I mean do not going too much on details would be better
I have owned the full course... Very depth course.. I have one problem. In Monitor class, in getter method public String getNativeResolution() { return nativeResolution; } It is showing me an error - Incompatible types: Required: Java.lang.String Found: com.Composition.Resolution I am also using same IDE.... Please help
Thank you so much for this video! Very nicely explained. However, I have one question: where you called the drawPixelAt() method like thePC.getMonitor().drawPixelAt(x,y,""), this does the same thing as theMonitor.drawPixelAt(x,y,""). Why is the previous way better? Is it simply so you only have to remember the name of the PC object?
Thanks Jason. The reason is sometimes you may have a class where you don't want to allow an external class to update fields directly. Think of a bank account for example. You would probably be happy to have a getter to retrieve the balance, but would not want a setter to update the balance directly. You would probably want to only allow the balance to be affected by a particular method that validates the amount passed, logs the transaction, etc.
Lately i've been hearing Composition > Inheritance, but i've been having trouble understanding how to build structures so that they avoid inheritance. Can someone give an example of how the vehicle class could be set up as composition instead of inheritance.
A few very interesting points made in this video and I like that the computer example is easy to visualize. Maybe next time use less time creating classes and more focus on the subject at hand (what is composition). This is my personal opinion though.
