CSE 332 Lab 5: OOP Design

Posted 2021-09-10 智低对商象

CSE 332 Lab 5: OOP Design
Due by Wednesday December 12th at 11:59 pm
Final grade percentage: 20 percent - 15 percent implementation, 5 percent Readme
Objective:
This lab is intended to extend your understanding and use of C++ object-oriented programming
techniques, and to give you more experience using common design patterns.
To complete this lab, you will be given some starter code in your repository. You should build
additional functionality from there, documenting your thought process for each implementation
decision you make in your Readme. The project we will be working on is a Calendar
Application(I know 330 already has a calendar project...sorry!), however the goal is to design
the software to be very extensible. For this lab, your documentation will be worth much more
than in previous labs. Make sure you think through your design decisions thoroughly and
document them thoroughly as well. The code I’ve provided is a very bare bones calendar, with
currently very little functionality. You will be adding functionality is this lab. Below is a brief
description of the provided code.

1. The application makes use of the composite pattern. This allows objects to be stored in
   tree-like structures, creating hierarchical structures of objects(a year has 12 months, a
   month has __ days, etc.). The composite pattern also allows us to treat leaf
   objects(objects that do not have any children) and composite objects(objects that may
   contain children) identically, because all objects in the composite define the same
   interface. The abstract base class “DisplayableComponent” defines the interface that all
   calendar objects inherit from, including days, months, years, and the calendar itself. The
   majority of the concrete classes that define the “DisplayableComponent” interface can be
   found in calendarcomponents.h and calendarcomponents.cpp.
2. The application makes use of the builder pattern for managing the construction of a
   Calendar. This allows the Calendar to remain unaware of how its internal state is
   constructed, allowing different builders to be used to construct the calendar in varying
   ways. The abstract base class “CalendarBuilder” declares the interface that a builder
   must define. FullCalendarBuilder is a concrete class defining that interface.
   FullCalendarBuilder works by constructing the entire calendar at once.
3. The CalendarInterface class is the client using a Calendar object. The code is designed
   with separation of concerns in mind. CalendarInterface manages input/output from the
   user(the user interface). The calendar object stores the data of our Calendar, and the
   builder is responsible for managing the construction process of our calendar and adding
   new components to it.declares and defines the interface presented by a calendar.
   Currently, the CalendarInterface class is very simple. It displays the calendar and gives
   the user a few options like zooming in or out on a particular object in the calendar and
   that’s about it. Throughout the rest of this lab, you will be expanding on that functionality.
4. Designpatterns.cpp gives a main function that initializes a CalendarInterface object and
   calls into it, allowing for user interaction. You should not write any significant code in this
   file, although you may end up changing the string passed as an argument to the
   CalendarInterface constructor.
   For this lab, you may work individually or in a 2-person or 3-person group. If you choose to
   work in a group, you work within a single repository, but in the ReadMe.txt file you then must:
   (1) indicate who the members of the group are, and
   (2) explain in some detail how you divided up the work (reasonably) evenly between you in
   designing and implementing your lab solution - i.e., who did which parts, etc.
   Assignment:
   Part I - Resources and Guidelines:
5. The constructor, destructor, operator, accessor, and mutator method examples in the C++
   classes lecture slides give an overview of the kind of class syntax and structure you may
   need for this lab.
6. The examples on C++ subclassing and inheritance polymorphism in these slides also
   may be useful for thinking about how to structure your classes. Reviewing chapters 12,
   13, and 15 from [LLM] can certainly be helpful as well.
7. Reviewing chapter 1 from [GHJV] can be helpful in thinking about different ways to create
   flexible, extensible code. Particularly, reviewing encapsulation, interface inheritance,
   composition, and delegation may be useful. Chapters 2 - 5 should be very useful as
   references when thinking about which design patterns may be applicable to problems you
   may encounter in your work, and thinking about the benefits of one pattern over another.
8. Please review the CSE 332 Programming Guidelines, all of which may be relevant to this
   lab. Please follow them as you implement your solution.
   Part II - Required Functionality:
   Your Readme.txt file for this lab should include the typical information:
   ● Group member names
   ● Any errors, warnings you ran into while working
   ● Test cases you ran to test the functionality of your Calendar
   In the Readme.txt file you will also find a series of questions that should be answered as well.
   Below is a list of functional requirements that should be added to your Calendar application. You
   are required to implement all functionality in this list. Exactly how you choose to do that is up to
   you, but I will make some suggestions as we go. There will be questions in the Readme.txt file
   associated with each piece of added functionality, you must answer them thoughtfully.
   NOTE: I have provided interfaces for particular classes. These are simply starting suggestions,
   you may change these interfaces if needed.
9. Implement functionality for creating and adding Events to the Calendar. Here are
   some requirements:
   a. An Event has a name, and a date/time(of type struct tm), as well as anything
   else it may inherit from base classes.
   b. Event objects can only be added to Days (DisplayableDay objects). Events
   should only be added to the day that the event occurs in.
   c. Recurring and multi day events should be supported(recur every __ days, event
   lasts for __ days). Each day an event falls on should contain a shared_ptr to a
   unique Event object. You should not share the same event object between days.
   d. Events may be created in future years as well (up to the number of years stored
   in the calendar). Events may not be created in years prior to the current year.
   e. A day may contain multiple events. Those events should be sorted by their start
   time.
   Things to think about and suggestions:
   f. How can you determine what day an event occurs in?
   g. What object or objects should be responsible for this? What objects contain the
   necessary information to determine this?
   h. Should an event inherit from any of the given classes?
   Question 1 in the Readme pertains to the above functionality.
10. Make the Calendar interactive. Each time the Calendar is displayed, a set of options
    should be given. The user should be prompted to choose an option, and that request
    should be handled appropriately. A user should be given options pertaining to the
    current object being displayed as well as a set of global options:
    a. Global options(available each time the Calendar is displayed)
    i. Create a new Event
11. Should be handled by prompting the user for information about the
    Event, creating an event, and adding it to the calendar
    ii. Search for an Event by name
12. Should display details of the event if found by updating the current
    view of the Calendar to display the event
    a. If multiple Events have the same name, a list of all Events
    with the matching name should be displayed. The user can
    then choose one to display.
13. If no event matches the name, a message should be printed to
    alert the user.
14. For full credit, this should be done efficiently. What STL containers
    can be useful here? There is no need to iterate through or search
    the entire calendar.
    iii. Jump to a specific date and select the granularity to view in the calendar
15. Ex: a user may specify August 10th, 2018 and “day” as the
    granularity, the display should then update its current view to the
    DisplayableDay object representing August 10th, 2018. If the user
    specifies “month” as the granularity, the display should update its
    current view to the DisplayableMonth object containing the
    DisplayableDay object for August 10th in its component subtree.
16. If the date does not exist in the calendar, a useful message should
    be printed to notify the user and the current view should be
    displayed again.
    iv. Save the Calendar to a file so that it may be restored later, make sure to
    save/restore the calendar’s name as well
17. Could an iterator be useful for traversing the objects in the
    Calendar in order?
18. Does the entire state of a Calendar need to be written to the file to
    be able to fully restore it later?
    v. Restore a Calendar from a file
19. This should overwrite the contents of the current Calendar
20. Perhaps a new concrete Builder would work well here
    vi. Change the Calendar’s current view by zooming in and out 1 level at a
    time (zoom functions are already given).
    b. Local options: local to the currently displayed object
    i. If the object is an event, the user should be able to edit it, including
    changing the date or deleting the event. This may cause the event to
    have to be moved.
    Question 2 in the Readme pertains to the above functionality.
21. Update the display: Currently, how the calendar is displayed is not very useful. Modify
    what information is displayed about an object at run-time to create a more readable
    output.
    a. If the Calendar’s current view is the Calendar itself:
    i. Display a list of years the calendar contains and their corresponding
    indices in the Calendars vector of children. A user can use these indices
    to zoom in on a particular year.
    b. If the Calendar’s current view is a DisplayableYear object:
    i. Display the current year
    ii. For each month the Year contains:
22. Display the name of the month
23. Output the first letter of each day of the week
24. For each week, output the day of the month associated with each
    day contained in the week. Each day should be aligned with the
    first letter of its weekday that was output in step 2.
    The output for a single month(let’s say February, and the 1st falls
    on a Tuesday) should look like this:
    February
    S M T W T F S
25. 2 3 4 5
26. 7 8 9 10 11 12
27. 14 15 16 17 18 19
28. 21 22 23 24 25 26
29. 28
    c. If a month is the top level object being displayed:
    i. Display a line containing the name of each weekday, evenly spaced from
    each other. Let each column be about 11 characters wide.
    ii. For each week contained in the month:
30. Display a line containing the day of the month associated with
    each day in the week, aligned properly with its associated
    weekday printed in step i.
31. Display a line containing the name of the first Event contained in
    each day of the week, once again columns should be spaced
    evenly with the weekday names above. If an event name is longer
    than the column width allows, truncate the event name.
32. Repeat with the second event in each day on a new line. If at any
    point a Day does not contain anymore events, fill its column with
    spaces. Continue this process until all events of each day are
    printed
33. Output a blank line
    The output for the first couple of weeks of the month should look like:
    Sunday
    6
    Event 1
    Event 2
    Monday
    7
    Tuesday
    1
    Event 1
    Event 2
    8
    Event 1
    Wednesday
    2
    9
    Thursday
    3
    10
    Event 1
    Friday
    4
    Event 1
    11
    Event 1
    Saturday
    5
    Event 1
    Event 2
    Event 3
    12
    d. If a day is the top level object being displayed:
    i. Print the name of the weekday and the days date on a single line
    ii. Print the events contained in that day, 1 event per line. The event name
    and time should be printed. The events should be printed in sorted order
    based on their time.
    iii. Output for a day may look something like (you can display the time
    however you would like):
    Monday 2/21/2018
34. event 1
35. event 2
36. event 3
    Updating the DisplayableComponent interface may be useful here. Particularly, you need to
    modify how display() behaves for a component depending on its depth from the current view.
    Design patterns that may help here: Strategy, State, Visitor, Chain of Responsibility
    Part III: Implement 2 of the following options:
    (Extra credit: 5 points - implement the 3rd)
    In your Readme, document which piece of functionality you chose to implement. Document how
    the chosen design pattern works, and how it is used to implement the specified functionality.
37. Implement functionality to merge one calendar into another. Each merged Calendar
    should be given a unique name (chosen by the user when specifying which text file to
    load and merge). The structure of the Calendar should not change in any way, only the
    Events of the Calendar should be merged in. When displayed, an Event should specify
    which calendar it is associated with. Any number of Calendars should be able to be
    merged into 1. For instance, we may merge 3 calendars together with names C1, C2,
    and C3. The output when a day is displayed may look something like:
    Monday 2/21/2018
38. C1::Event1
39. C2::Event1
40. C1:: Event2
41. C3::Event1
    When an event is displayed directly, the Calendar it belongs to should be listed as well.
    For full credit you must use the Decorator design pattern.
42. Implement functionality to add a TODO list within a DisplayableDay object in the
    Calendar. You should use the singleton pattern to ensure that each Day has only a
    single TODO list. A TODO list contains some number of Tasks. Each Task has at a
    minimum a name. When a Day is displayed directly, a user should be able to:
    a. Add a TODO list to the day, if a TODO list does not already exist for that day
    b. Zoom in on the TODO list if it exists
    c. A TODO list should be displayed below the events for a given day and marked
    “TODO list” when displayed
    d. When a user is currently displaying a TODO list, the user should be able to:
    i. Add tasks to the TODO list
    ii. Mark tasks as complete
    iii. Each task should be displayed and marked with either “TODO” or
    “COMPLETE”
    iv. A user does not need to be able to zoom in on a particular task
    TODO list should not be displayed in any other view, only when a Day containing a TODO list is
    being displayed directly or the TODO list itself is being displayed directly.
    Design Patterns to consider: Singleton, Strategy, Decorator
    For full credit, the singleton pattern must be used to ensure only a single TODO list exists for
    each day.
43. Incremental builder: Currently the FullCalendarBuilder constructs the entire calendar at
    once, which allocates a lot of objects and uses a lot of memory. In this part, you will
    implement an incremental builder. The goal is to construct components of the calendar on
    demand as they are needed. Your IncrementalCalendarBuilder class should inherit from
    CalendarBuilder. Initially, only a Calendar object should be constructed along with the
    current year, month, and day(the day, month, and year associated with the current date).
    As the user zooms in/out or jumps to a particular date and granularity, components of the
    calendar should be constructed and added to the calendar as needed by the builder. A
    user should be able to zoom in to a child that does not exist yet, so you may need to
    update the zoom functions accordingly.
    GETTING STARTED:
    Decide if you are working alone or in a team of 2 or 3. Decide on a team name. One member
    of your team should accept the assignment link here and create a team for their group. Now,
    the other members of the group should visit the assignment link, select the correct team
    name, and accept the assignment. A repository will be created for your team that is pre
    populated with the starter code for lab 5. You should create a VS solution within the repository
    and add the provided code into the solution to get started.
    SUBMISSION:
    Complete the additional functionality as described. Document your work as typical in the
    Readme.txt file associated with the project. Answer all additional question in the Readme.txt
    file as well. Commit and push your final code to Github. There may be a demonstration
    process soon after the due date. This will give you a chance to demonstrate the functionality
    you implemented to a TA directly. Details on this to come.

WX：codehelp