Final Entry

Class Takeaways:

• test first, test during, test after; test, test, test
• when designing algorithms, demand the weakest iterators (e.g. bidirectional vs. random access)
• when designing containers, provide the strongest iterators (e.g. random access vs bidirectional)
• build adapters on top of containers
• always look for reuse and symmetry in your code
• collaboration is essential to the quality of your code and to your well-being in producing it
• refactor, refactor, refactor
• make your code beautiful

How well do you think the course conveyed those takeaways?

I think that this course was able to stick close to demonstrating, and providing opportunities for experimenting with, key OOP concepts such as continuous integration, inheritance, and abstraction.

This course truly excels in providing a solid academic framework through which to convey OOP material such as in-class exercises, daily low-stakes quizzes (lower stress meant that I could focus on the material better), and, naturally, programming projects.

Were there any other particular takeaways for you?

Yes! The most valuable sections of the class to me were the ones where we went over the general functionality of particular C++classes (iterators, vectors, etc) and then were tasked with taking a stab at implementing their specific behavior. I cannot think of a better way to learn Object-Oriented Design than to study and evaluate the implementation of real classes in an OO language. In this particular regard, each exercise felt like a case study for a different OO principle/technique, putting to practice the popular idea that there exists no better way to learn than by doing.

In summary, my biggest takeaway from this course is the knowledge and confidence to create scalable, malleable, and well-purposed classes!

How did you feel about cold calling?

I think that it might have been a little intimidating at first, but it overall helped me focus by forcing me to constantly and consciously pay attention to the particularities of the material being discussed.

How did you feel about office hours?

The professor and the TAs had a reasonable number of office hours, scheduled at a variety of accessible times throughout the week. They proved to be extremely competent tutors and I never left a session with a question or felt like I was not welcome to ask them.

It is also worth noting that the professor made himself consistently available after every single class to answer our questions. This is not to say that he usually went over class time either! Downing managed to structure the material in such a way that we were, for the vast majority of classes, able to get through daily topics entirely within the allotted time. I have personally stayed after class to clear doubts, and cannot say that I have ever had a bad experience.

How did you feel about lab sessions?

Unfortunately, I did not have the opportunity to go to many of them, but I had lab partners who did so in the past, and from what I hear, they are extremely similar to office hours in terms of quality and effectiveness.

What required tool did you not know and now find very useful?

Over this semester I became extremely acquainted with Visual Studio Code, which, has proved to be an invaluable tool, primarily due to its incredible SSH integration. Being able to create, manage, and edit files directly onto the application eases the difficulty of working on labs, especially with a partner (live share!).

I cannot answer this question without also mentioning gitLab. Even though I had some degree of experience with gitHub before, being compelled to delve deep into the different version control mechanisms within gitLab helped me start building a solid sense of what it means to work on a project outside the programming itself. Taking advantage of tools like continuous integration and issue tracking has made me appreciate the importance of building project documentation.

You should have read five papers that describe SOLID design : Single responsibility, Open-closed principle, Liskov substitution, Interface segregation, Dependency inversion. What insights have they given you?

The underlying theme found in every single one of the “design” papers, was the importance of creating code that is non-rigid and scalable. A large amount of emphasis is placed on ensuring that a codebase can seamlessly undergo changes and additions to its modules, which, unsurprisingly, can only take place if it is built upon intelligent design.

In my opinion, this idea is best articulated in the Open-closed principle, which outlines the importance of abstraction and polymorphism in OOD. Code that depends on derived objects of some base class should not have any more knowledge about the data it manipulates than strictly necessary. It does not need to know the intricacies of its implementation or the data members it keeps. Following this basic rule leads to the natural conservation of the Open-Closed principle, allowing for the codebase to be closed to modification but open to extension. The Single Responsibility principle also arrives at a similar conclusion, in that it describes the importance of minimizing dependencies! If modules are meant to take care of multiple functions at once, then if we need one instance of its behavior to change, all other behaviors are affected! We ought to extend, not modify, so we must aim for single responsibility modules. Besides, if we encounter some bug later down the line, it will likely be easier to catch it if we have a clear outline for what each of our classes do. It seems to me that all other readings conclude with similar thoughts.

You should have read two papers that advised minimizing getters and setters. What insights have they given you?

Getters and setters are conducive to unexpected dependencies. We force exterior code to become privy to the implementation of our classes, meaning that if we wish to change their behavior later, we are constrained by the amount of code that may depend on the data we have inadvertently made available to client code.

Give me your suggestions for improving the course.

The only real piece of feedback I have is that I feel like this course could benefit from giving students a few slip days, especially when the per-day penalty for late submissions is so harsh.