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.