CPSC 421 Object-Oriented Programming Spring 2026

News

---

• 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

• Project 4 Posted: Apr 07

  Project 4 continues the work on srcFacts. It is due at 11:59:59 pm Tuesday, Apr 21, and involves the following stages which must be performed in order:

  Tag v4a Correct the issues in XMLParser that affect srcfacts, xmlstats, identity, class diagram, and sequence diagram.

  Tag template Redesign XMLParser to use the Template Design Pattern. In this design pattern, extension points are virtual methods. This means new classes that inherit from XMLParser:

  • srcFactsParser in the new files srcFactsParser.hpp and srcFactsParser.cpp
  • IdentityParser in the new files IdentityParser.hpp and IdentityParser.cpp
  • XMLStatsParser in the new files XMLStatsParser.hpp and XMLStatsParser.cpp

  The pull request template adds these new files to your repository and updates the CMakeLists.txt so that they are part of the build. Update your class and sequence diagrams to show this new design.

  As before, our XML parser needs to provide access to all parts of XMLvia the following extension points from XML notes slide 33

  XML Extension Point	Attributes
  Start Document
  XML Declaration	version, encoding, standalone
  Element Start Tag	qName, prefix, localName
  Element End Tag	qName, prefix, localName
  Characters	characters
  Attribute	qName, prefix, localName, value
  XML Namespace	prefix, uri
  XML Comment	value
  CDATA	characters
  Processing Instruction	target, data
  End Document

  WARNING Do not pull the pull request for handler until you are completely done with template.

  Tag handler Extract a handler from XMLParser called XMLParserHandler, a new class that only handles the user-defined processing (what we previously had as callbacks). Put the entire XMLParserHandler class in the file XMLParserHandler.hpp.

  Then change srcFactsParser, IdentityParser, and XMLStatsParser to inherit from XMLParserHandler instead of XMLParser, and rename them by replacing "Parser" in the name with "Handler".

  The pull request handler renames these files updates the filenames in CMakeLists.txt. Update your class and sequence diagrams to show this new design.

  Make sure to update the class names and header comments in these files.

  Update your class and sequence diagrams to show this new design.

  Warning Once you tag template and move on to handler, you will not be able to change anything for template. So carefully check that you are done with the template part before you tag it and move on to handler

  One prevalent issue in these conversions is that changing XMLParser and srcfacts will cause identity and xmlstats to break until they are converted. To avoid this, understand that make uses the default target all and means make all. So instead of building all executable targets, build them separately as needed, e.g., make srcfacts, make xmlstats, or make identity.

  Keep in mind:

  • You are required to implement these steps in the order given, i.e., tag v4a, tag template, and then tag handler
  • At every commit, ensure the project compiles, builds, and produces the correct answer. Note that it may be only one of the executable targets that builds during conversion.
  • The Template Design Pattern has absolutely nothing to do with the C++ language feature templates. Any use of C++ templates will result in a 0.

Archive