Composition

One of the topics from the semester that I understood the least was software design patterns. At the time, they seemed very abstract and I didn’t go in depth enough to understand any one of them. Since I haven’t worked on any big projects, most of the benefits that are mentioned do not apply to me, yet.

I got interested on the topic after watching the following youtube video by funfunfunction. It goes over what Composition is and its advantages:

Simply put, composition is making new types by having an instance of another type for its functionality. It’s different from inheritance in that you have, no are, another object.

What made this video specially relevant for me was that in POO (OOP class), we learned about inheritance as one of the main benefits of OOP. Inheritance to me was one of the better ways to achieve code reuse and I thought it made a lot of sense when talking  about OOP. Since taking that class I very often try to make inheritance work with my (school) projects.

Learning that one of the main concepts I had learned in POO was considered bad led me to understanding a one of the main differences in coding for homework and coding as a job: Planning. Ken has even mentioned this in class but now I’m able to relate it to myself. After watching the video, I felt like my way coding to date had been wrong, but I slowly came to understand how planning affected the situation heavily. In the video’s example, not knowing the future was the main reason why inheritance didn’t work. When I’m doing homework, Inheritance works perfectly because there are no users and I know how the code will work before I start. That situation just doesn’t happen in the real

which is why inheritance is such a big unneeded commitment.

In the end, it’s not that I shouldn’t use inheritance, it’s just that my current situation doesn’t suffer from its negatives.