Week 13 Class 23 Tue Apr 06 Posted: Apr 06

Class session:

  1. Announcements:
  1. Screencast: APIs notes
  2. Exercise 65: APIs Crossword
  3. Screencast: SOLID notes
  4. Exercise 66: SOLID Crossword
  5. Screencast: C++ Inheritance Specifiers notes

    One additional note. Programming language changes should not change existing code. That is one reason why contextual keywords are essential. They allow a new keyword without breaking existing code. For example, the override specifier was added to the language, but you are still allowed to have a variable or function named override.

    And you can even override a method override():

    It would be nice to require the use of override. However, this would break all previous classes. So you are not required to use override, but if you use it even for one method in a class, the compiler requires it for that class.

    One more thing. The introduction of override makes the coding style clear:

    1. As required, use virtual in the base class for a virtual method
    2. Use override in derived classes to override a virtual method in the parent class. We sometimes use virtual in these situations as documentation, but it is not required. Once a method is virtual, it is virtual in all derived classes.
  6. Exercise 67: C++ Inheritance Specifiers Crossword
  7. Exercise 68: ScenarioA

    The project, Scenario, contains three different scenarios of using a class. The code is available in GitHub Classroom using a link on the Brightspace course page.

    ScenarioA was the start of the project. Only class A, and a static class AUtilities, existed. Classes B and C did not exist yet.

    To more closely examine a UML class diagram, click on the diagram.

    The main program, ScenarioA.cpp, contains assertions (assert()) to check the methods and functions return types. These assertions are all incorrect as they assume the class name is X. Fix each assertion with the correct class name so that the assertion passes.

    To build ScenarioA:

    To run ScenarioA:

    Only make changes to the file ScenarioA.cpp.

  8. Exercise 69: ScenarioB

    In ScenarioB, we add class B (derived from class A) and a static class BUtilities. Class C does not exist yet:

    Follow the same general procedure as in ScenarioA.

    It is important to understand that class B’s addition does not require recompiling A.cpp, AUtilities.cpp, nor ScenarioA.cpp. This demonstrates the “Closed” part of the OCP (Open/Closed Principle) of SOLID. E.g., adding class B does not change anything about how ScenarioA.cpp works. The “Open” part is class B’s ability to inherit from class A and extend the behavior.

  9. Exercise 70: ScenarioC

    In ScenarioC, we add class C (derived from class B) and a static class CUtilities.

    Follow the same general procedure as in ScenarioA.

Screencast Folder: Class 23 Tue Apr 06

Exercise Due Date: 4 pm on Wednesday, Apr 07