CPSC 421-020 Object-Oriented Programming Spring 2026

Week 14 Class 22 Tue Apr 14 Posted: Apr 14

Announcements

• Project 4

• Exercise 73: Dynamic Dispatch

  Feedback is in the file oracle.dynamic.txt in the branch feedback in your repository. This is the difference between the oracle (with the correct answers) and your Base.cpp. If it is empty, then that means your answer is completely correct (reflected in your score). Even if your answer is correct, the file may show some differences.

  There is a strong possibility that this will be in a question on the Final Exam.

• Exercise 76: FileIO

  Please read over the feedback in Brightspace. Even if you got a 10 points, there may be feedback as to your comments or coding style.

  • All methods should have a comment before the declaration/definition. This includes constructors and destructors. See the notes for a good comment before a destructor.

  • Do not use the term // virtual ... for a comment of a method (or destructor). The keyword virtual tells us that. The following are examples of substandard comments for destructors:

• Exercise 81: Software Development Habits Survey This is an optional exercise that involves taking an outside survey. The survey involves making changes to code in a browser-based editor. See the Brightspace anouncement for more information, and how to get a screenshot to prove your survey completion.

  Upload the screenshot to Brightspace. Due by Noon on Fri, Apr 17.

• Examples and Coding Style

  We started looking at code that involves multiple classes. To more clearly show the relationships between classes, e.g., two classes involved in a design pattern or classes that inherit from one another, we will often include the definitions of constructors, methods, and destructors directly in the class, rather than in a separate declaration file (i.e., .hpp) and a definition file (i.e., .cpp). However, for any code in a project, you must still follow our established rules:

  • Each class in its own file
  • Constructor, method, and destructor declarations in a declaration file, e.g., .hpp
  • Constructor, method, and destructor definitions in an implementation file, e.g., .cpp

  Failure to follow this will result in a penalty, except in very specific approved cases.

Agenda

• Exercise 82: Encoder

  Use the GitHub Classroom Exceptions invitation link in Brightspace.

  Take the code and perform the following changes, each in a separate commit:

  • Change the maximum size from 4096 to 2048 in both the code and the exception message
  • Change the byte-alignment requirement from 8 to 16 in both the code and the exception message
  • Change the minimum block size from 8 to 4 (size 3 and smaller still throws an exception)

  Run the program once without an exception being thrown. Then, run the program once for each exception, and show that the exception is thrown. Note that there are instructions for building, BUILD.md. You can also install the program encoder (see INSTALL.md). Once installed, you can run encoder from any directory. Note that if you rebuild, you will need to reinstall. See README.md for how to run.

  To demonstrate this, record a terminal session using asciinema. Submit the terminal session using the form in the exercise title. You can use GitHub Codespaces for this as it has asciinema installed.

  Note that both parts, the commits and the asciinema session, must be completed to receive any points.

• Notes: API
• Exercise 83: API Crossword
• Notes: Design Pattern Factory Method

• Exercise 84: Design Pattern Factory Method Crossword

• Exercise 85: Design Pattern Factory Method Quiz

  Complete the quiz. Any incorrect answer is a point off out of 10, so answer very carefully.

  You will see the correct responses after the due date.

• Notes: SOLID

Unless otherwise noted, exercises are due by 3:30 pm on Wed Apr 15