Part I: Class Design

Write a class, Formula, that represents a way of converting resources into other resources. A Formula has one or more input resources and one or more output resources, including the quantities of each. Some examples:

• 2 iron ore -> 1 iron bar
• 3 iron ore, 1 coal -> 1 steel bar
• 1000 water -> 999 hydrogen, 1 deuterium
• 2 butter, 3 egg, 1 sugar, 2 flour, 2 baking soda -> 36 cookies

Additionally, each Formula has a chance of failing or producing a different number of outputs than expected. A Formula could produce 75% of the expected output, 110% of the expected output, the exact expected amount, or it could fail completely. All outputs must be whole numbers.

Clients should be able to query the names and quantities of the Formula's inputs and outputs, but not modify them (in fact, those values should be immutable after instantiation). Clients should not be able to see or modify the chances of different outcomes, but the Formula class should have a
method called Apply() that allows clients to simulate the outcome of applying the formula.

Each Formula has a proficiency level. The proficiency level starts at 0 but can be increased by the client up to some maximum. Increasing the proficiency level of a Formula increases the chances of better outcomes. For example, a level 1 Formula may have a 25% chance of failure, 20% chance of ¾ output, 50% chance of normal output, and 5% chance of bonus output, but after leveling it up to level 2 the chances could change to 20, 15, 55, and 10, respectively.

Write a second class, Plan, that represents a sequence of Formulas to be applied in order.
A Plan should allow the client to:

• Add a new Formula to the end of the sequence.
• Remove the last Formula from the end of the sequence.
• Replace a Formula anywhere in the sequence.

Use dependency injection to provide an initial sequence of Formulas. The Plan class must properly implement C++ copy and move semantics. The Plan copy constructor and copy assignment operator should support deep copying of all internal Formulas so that no unintended aliasing occurs: e.g. after copying Plan object x, any actions on object x, such as leveling up a Formula, should not affect any copy of x.

The Plan class must implement a destructor to appropriately dispose of owned resources. Each Plan object encapsulates some number of distinct Formula objects, with addition, removal and replacement of Formula objects supported as specified above – thus the cardinality of Formula sub-objects varies across Plan objects. You decide what, if any, additional public functionality should be supported, remembering that exposure should be minimized and queries should not affect state.

Additional Considerations

1. Many details are missing, much like with nearly every project you will work on professionally. Use logic and your creativity to fill in the blanks! Make sure to think through the following:

• Error processing - what will you do if the client tries to set up an invalid state or give an invalid input?
• Initialization of Formula objects (constructor design)
• Control of state - how do you ensure that your class works exactly as expected, no more, no less?

2. The public interface of the class is a key design requirement for this assignment.

• What must be exposed to the client?
• What should be hidden from the client?

3. Remember since the client does NOT control Formula objects directly there should NOT be any setSize(int) etc. public methods.

4. Do NOT use console input/output in the Formula class. This is generally bad practice in software development as it makes your class harder to test and less reusable (what if we want to use it in a GUI or a web server)? Put all of your end user interactions in your driver code instead (see below).

5. Many details are missing, much like with nearly every project you will work on professionally. Use logic and your creativity to fill in the blanks! Make sure to think through the following:

• Error processing - what will you do if the client tries to set up an invalid state or give an invalid input?
• Initialization of Formula objects (constructor design)
• Control of state - how do you ensure that your class works exactly as expected, no more, no less?

2. Do NOT use console input/output in the Formula class. This is generally bad practice in software development as it makes your class harder to test and less reusable (what if we want to use it in a GUI or a web server)? Put all of your end user interactions in your driver code instead (see below).

Part 2: Driver

i.e., creating a demo client

The purpose of writing a contract for your class is to help clients understand what they can expect and what they're responsible for when using that class. The purpose of unit tests is to make sure that your class implementation fulfills that contract. A good driver program reinforces both by demonstrating to other developers how to write a client in addition to exercising your code.

Write a functionally decomposed driver to demonstrate that your class code meets the requirements of Part 1. The driver must:

• Instantiate many instances of the Formula class stored in a collection. The instances should represent a variety of states; not all need to be unique, but you should have enough variation to demonstrate all of the interesting/distinct configurations of a Formula.
• Demonstrate how to interact with the Formula instances and what state transitions and outputs to expect as a result of the interactions.

When in doubt, look back to your contract. Your driver should show off all of the interface/class invariants, preconditions, and postconditions.

Deliverables

All CPSC 3200 programming assignments have two-parts: 1) class design(s) and 2) a ‘driver’ that simulates client use of the designed class(es). It’s essential to remember that the client (driver) has no knowledge of internal class design(s) and relies solely on the public interface(s).

In P1, the Formula class is an abstraction of a data sink (store) that holds data that is not directly accessible but yields specific information upon query. Though stored internally and subject only to controlled modification, data may still mutate/age and become invalid. Your design should encapsulate and control state as well as the release of information.

For an acceptable P2 submission:

1. Use C++, the Linux variety. I recommend writing your code on cs1 or using CLion. Visual Studio will use Microsoft's version of C++, which will not get you credit for this assignment.
2. Use the submission script on cs1 to submit your .h and .cpp files. If the script doesn't give you a success message, you did not submit your assignment!
3. Design using heap memory, composition, and move semantics. Due to variable cardinality of internal Formula sub-objects across the Plan objects you will need to use heap memory in order to achieve efficient memory usage. Do NOT design using excessive capacity.

To submit your code on cs1:

1. You must have files named formula.h, formula.cpp, plan.h, plan.cpp, and p2.cpp, all in the same folder.
2. You must run the program /home/fac/tspinney/submit/cpsc3200fq23/p2/submit from that folder. This will check for the existence of those files, try to copy your files to a folder the graders can access, and then try to compile the code. Make sure it says "Submission was successful, thank you!" or you will get a 0 on your assignment.

Other notes on submitting your work:

• You can run the submit script as many times as you want. I encourage you to run it early and often, but to make sure you finish with a working version of your code.
• If you want to try to compile your code without submitting, the exact command it uses to compile is g++ -Wall -Werror -pedantic -std=c++17 formula.cpp plan.cpp p2.cpp -o $sdir/p2. The options (anything starting with a -) are important; if you run g++ without them there is no guarantee that you will get credit for your work.
• Always keep a working copy of your code, even if it's not complete! cs1 has git installed, which makes it easy to keep snapshots of your code, but if you aren't familiar or aren't interested in trying it out you can always make copies of the folder you're working?