CSE 332代做、代写C/C++语言、代做OOP Design、C/C++程序设计代写

日期：2018-12-15 10:45

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:

1. 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.

2. 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.

3. 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.

4. 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.

1. 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.

2. 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

1. 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

1. 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.

2. If no event matches the name, a message should be printed to

alert the user.

3. 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

1. 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.

2. 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

1. Could an iterator be useful for traversing the objects in the

Calendar in order?

2. 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

1. This should overwrite the contents of the current Calendar

2. 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.

3. 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:

1. Display the name of the month

2. Output the first letter of each day of the week

3. 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

1 2 3 4 5

6 7 8 9 10 11 12

13 14 15 16 17 18 19

20 21 22 23 24 25 26

27 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:

1. 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.

2. 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.

3. 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

4. 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

0800 event 1

1200 event 2

1600 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.

1. 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

0800 C1::Event1

1200 C2::Event1

1300 C1:: Event2

2000 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.

2. 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.

3. 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.