CSE 332程序写作、辅导C/C++语言程序

” CSE 332程序写作、辅导C/C++语言程序CSE 332 Lab 5: OOP DesignDue by Wednesday December 12th at 11:59 pmFinal grade percentage: 20 percent – 15 percent implementation, 5 percent ReadmeObjective:This lab is intended to extend your understanding and use of C++ object-oriented programmingtechniques, 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 buildadditional functionality from there, documenting your thought process for each implementationdecision you make in your Readme. The project we will be working on is a CalendarApplication(I know 330 already has a calendar project…sorry!), however the goal is to designthe software to be very extensible. For this lab, your documentation will be worth much morethan in previous labs. Make sure you think through your design decisions thoroughly anddocument them thoroughly as well. The code Ive provided is a very bare bones calendar, withcurrently very little functionality. You will be adding functionality is this lab. Below is a briefdescription of the provided code.1. The application makes use of the composite pattern. This allows objects to be stored intree-like structures, creating hierarchical structures of objects(a year has 12 months, amonth has __ days, etc.). The Composite pattern also allows us to treat leafobjects(objects that do not have any children) and composite objects(objects that maycontain children) identically, because all objects in the composite define the sameinterface. The abstract base class DisplayableComponent defines the interface that allcalendar objects inherit from, including days, months, years, and the calendar itself. Themajority of the concrete classes that define the DisplayableComponent interface can befound in calendarcomponents.h And calendarcomponents.cpp.2. The application makes use of the builder pattern for managing the construction of aCalendar. This allows the Calendar to remain unaware of how its internal state isconstructed, allowing different builders to be used to construct the calendar in varyingways. The abstract base class CalendarBuilder declares the interface that a buildermust 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 designedwith separation of concerns in mind. CalendarInterface manages input/output from theuser(the user interface). The calendar object stores the data of our Calendar, and thebuilder is responsible for managing the construction process of our calendar and addingnew components to it.declares and defines the interface presented by a calendar.Currently, the CalendarInterface class is very simple. It displays the calendar and givesthe user a few options like zooming in or out on a particular object in the calendar andthats 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 andcalls into it, allowing for user interaction. You should not write any significant code in thisfile, although you may end up changing the string passed as an argument to theCalendarInterface constructor.For this lab, you may work individually or in a 2-person or 3-person group. If you choose towork 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 indesigning 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 mayneed for this lab.2. The examples on C++ subclassing and inheritance polymorphism in these slides alsomay 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 createflexible, extensible code. Particularly, reviewing encapsulation, interface inheritance,composition, and delegation may be useful. Chapters 2 – 5 should be very useful asreferences when thinking About which design patterns may be applicable to problems youmay 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 thislab. 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 CalendarIn 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. Youare required to implement all functionality in this list. Exactly how you choose to do that is up toyou, but I will make some suggestions as we go. There will be questions in the Readme.txt fileassociated 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 aresome requirements:a. An Event has a name, and a date/time(of type struct tm), as well as anythingelse it may inherit from base classes.b. Event objects can only be added to Days (DisplayableDay objects). Eventsshould only be added to the day that the event occurs in.c. Recurring and multi day events should be supported(recur every __ days, eventlasts for __ days). Each day an event falls on should contain a shared_ptr to aunique 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 storedin 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 starttime.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 thenecessary 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 optionsshould be given. The user should be prompted to choose an option, and that requestshould be handled appropriately. A user should be given options pertaining to thecurrent 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 Event1. Should be handled by Prompting the user for information about theEvent, creating an event, and adding it to the calendarii. Search for an Event by name1. Should display details of the event if found by updating the currentview of the Calendar to display the eventa. If multiple Events have the same name, a list of all Eventswith the matching name should be displayed. The user canthen choose one to display.2. If no event matches the name, a message should be printed toalert the user.3. For full credit, this should be done efficiently. What STL containerscan be useful here? There is no need to iterate through or searchthe entire calendar.iii. Jump to a specific date and select the granularity to view in the calendar1. Ex: a user may specify August 10th, 2018 and day as thegranularity, the display should then update its current view to theDisplayableDay object representing August 10th, 2018. If the userspecifies month as the granularity, the display should update itscurrent view to the DisplayableMonth object containing theDisplayableDay object for August 10th in its component subtree.2. If the date does not exist in the calendar, a useful message shouldbe printed to notify the user and the current view should bedisplayed again.iv. Save the Calendar to a file so that it may be restored later, make sure tosave/restore the calendars name as well1. Could an iterator be useful for traversing the objects in theCalendar in order?2. Does the entire state of a Calendar need to be written to the file tobe able to fully restore it later?v. Restore a Calendar from a file1. This should overwrite the contents of the current Calendar2. Perhaps a new concrete Builder would work well herevi. Change the Calendars current view by zooming in and out 1 level at atime (zoom functions are already given).b. Local options: local to the currently displayed objecti. If the object is an Event, the user should be able to edit it, includingchanging the date or deleting the event. This may cause the event tohave 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. Modifywhat information is displayed about an object at run-time to create a more readableoutput.a. If the Calendars current view is the Calendar itself:i. Display a list of years the calendar contains and their correspondingindices in the Calendars vector of children. A user can use these indicesto zoom in on a particular year.b. If the Calendars current view is a DisplayableYear object:i. Display the current yearii. For each month the Year contains:1. Display the name of the month2. Output the first letter of each day of the week3. For each week, output the day of the month associated with eachday contained in the week. Each day should be aligned with thefirst letter of its weekday that was output in step 2.The output for a single month(lets say February, and the 1st fallson a Tuesday) should look like this:FebruaryS M T W T F S1 2 3 4 56 7 8 9 10 11 1213 14 15 16 17 18 1920 21 22 23 24 25 2627 28c. If a month is the top level object being displayed:i. Display a line containing the name of each weekday, evenly spaced fromeach 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 witheach day in the week, aligned properly with its associatedweekday printed in step i.2. Display a line containing the name of the first Event contained ineach day of the week, once again columns should be spacedevenly with the weekday names above. If an event name is longerthan the column width allows, truncate the event name.3. Repeat with the second event in each day on a new line. If at anypoint a Day does not contain anymore events, fill its column withspaces. Continue this process until all events of each day areprinted4. Output a blank lineThe output for the first Couple of weeks of the month should look like:Sunday6Event 1Event 2Monday7Tuesday1Event 1Event 28Event 1Wednesday29Thursday310Event 1Friday4Event 111Event 1Saturday5Event 1Event 2Event 312d. If a day is the top level object being displayed:i. Print the name of the weekday and the days date on a single lineii. Print the events contained in that day, 1 event per line. The event nameand time should be printed. The events should be printed in sorted orderbased on their time.iii. Output for a day may look something like (you can display the timehowever you would like):Monday 2/21/20180800 event 11200 event 21600 event 3Updating the DisplayableComponent interface may be useful here. Particularly, you need tomodify 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 ResponsibilityPart 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 howthe 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 Calendarshould be given a unique name (chosen by the user when specifying which text file toload and merge). The structure of the Calendar should not change in any way, only theEvents of the Calendar should be merged in. When displayed, an Event should specifywhich calendar it is associated with. Any number of Calendars should be able to bemerged 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/20180800 C1::Event11200 C2::Event11300 C1:: Event22000 C3::Event1When 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 theCalendar. You should use the singleton pattern to ensure that each Day has only asingle TODO list. A TODO list contains some number of Tasks. Each Task has at aminimum 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 dayb. Zoom in on the TODO list if it existsc. A TODO list should be displayed below the events for a given day and markedTODO list when displayedd. When a user is currently displaying a TODO list, the user should be able to:i. Add tasks to the TODO listii. Mark tasks as completeiii. Each task should be displayed and marked with either TODO orCOMPLETEiv. A user does not need to be able to zoom in on a particular taskTODO list should not be displayed in any other view, only when a Day containing a TODO list isbeing displayed directly or the TODO list itself is being displayed directly.Design Patterns to consider: Singleton, Strategy, DecoratorFor full credit, the singleton pattern must be used to ensure only a single TODO list exists foreach day.3. Incremental builder: Currently the FullCalendarBuilder constructs the entire calendar atonce, which allocates a lot of objects and uses a lot of memory. In this part, you willimplement an incremental builder. The goal is to construct components of the calendar ondemand as they are needed. Your IncrementalCalendarBuilder class should inherit fromCalendarBuilder. Initially, only a Calendar object should be constructed along with thecurrent 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 thecalendar should be constructed and added to the calendar as needed by the builder. Auser should be able to zoom in to a child that does not exist yet, so you may need toupdate 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 memberof 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 teamname, and accept the assignment. A repository will be created for your team that is prepopulated with the starter code for lab 5. You should create a VS solution within the repositoryand add the provided code into the solution to get started.SUBMISSION:Complete the additional functionality as described. Document your work as typical in theReadme.txt file associated with the project. Answer all additional question in the Readme.txtfile as well. Commit and push your final code to Github. There may be a demonstrationprocess soon after the due date. This will give you a chance to demonstrate the functionalityyou implemented to a TA directly. Details on this to come.请加QQ：99515681 或邮箱：99515681@qq.com WX：codehelp

“