The provided code works with the singular and plural concepts of card and cards (aka deck) and die (aka n-sided die) and dice. There is a GamesApp class mainly for a starting point. In general, you would not do much inside the GamesApp class as you would instead create other classes to run. For example, you could have a CardWars class and in GameApp's main() function, you would have something like this:

CardWars cardWars = new CardWars();

cardWars.run();

This would create a variable named cardWars of the type CardWars that was then set to the value of a new instance of CardWars using the default constructor. This is quite a nuanced statement as we have to pay close attention to the capitalization to catch which one we are talking about since they are all spelled with the same letters but have different capitalization when it comes to the variable name and the class name.

You could also have a GameManager class that has a menu to select from different games. The instantiation would look almost identical in the main() function in the GamesApp class.

GameManager gameManager = new GameManager();

gameManager.run();

In both cases, you would have a public run() function where you would then put your code to run that game. In all cases, there would only be the two lines in your App class (i.e. GamesApp). This design will help you start your application without having to struggle with understanding the static concept, which will come later.

NSidedDie

The reason for NSidedDie is that a single die could have any number of sides. Here are some key points:

• Notice how ALL class variables are private. This forces any use of the class to go through the getters and setters, which in turn allows you to control the data coming in and out of the class. Although this may seem like it is not needed, it costs less to use this approach upfront than it does to refactor your code later to require it. The cost difference is related to the time to refactor your code.
• The default number of sides for a die is 6 because many games use this die. Some games may even use 100 sided die, such as Dungeons and Dragons. So we left it open to a much wider use but have a quick default.
• If you try to put 1 or fewer sides, the class will use the default value of 6.
• Notice the test for setting the number of sides is in the setter and the constructor uses the setter rather than setting the value directly. Having redundant code can open you up to later chasing flaws you thought you fixed. So if you ever notice yourself writing code that seems familiar, stop and confirm you do not have any repeated code.
• Notice the use of comments to create sections. Imagine having thousands of lines of code and how easy it would be to find the code you are looking for.
• This class has a peculiar pair of functions to print the die to the console. The reason for this feature is to later print a set of die side-by-side. For now, notice how we can pass data from one function to another.

Dice

Now let's look at the plural version of the die called Dice. This is a very simple class and one might think they do not need such a wrapper, but let's look further into the benefits.

• What if i would like to roll the whole set of dice? This class allows me to have a simple dice.roll() and all of the dice will be updated to a new random number as if they were rolled as a set.
• What if I want to generate a set of 5 dice for my Yahtzee game? I can quickly generate dice using the default number of sides or specific number of sides. This becomes a bit more apparent when we get into cards since there are numerous sets of decks we may be playing with.

Any concept where there is a set of dice would fall within the Dice class.

Card

The next class to look at is the Card class. Here are some features:

• We have a concept called an enumerator. This is an opportunity to make sense of something the computer has no concept of. In this case, the computer has no concept of the suits or card faces. To us, they have meaning, and we can use that meaning to create tests and other game logic. Consider what would be needed to play a card game where you need to say the 3 has a greater value than a 2. Now this may seem simple, but what about face cards? How does it fit in with aces? How do you compare an ace and a 2? Let's look further down at the compareTo() function. What we are doing here is a bit more advanced but we have enough to understand the main code. Let's say we have two cards, thisCard (known as \"this\" or this instance) and otherCard. How could we make sense of an arbitrary sequence? I say it is arbitrary because we cannot simply match it to a typical binary numbering sequence. What if we simply look at the card value and give it a numeric value? This is what the cardFaceToNumber() function does. So take a look at how we can identify the card faces and return a number. It isn't important what number is returned as much as we are ranking them. It is the rankings that are then compared to say whether thisCard is greater than the otherCard, thisCard is less than the otherCard, or the two cards are equal.
• Notice we are implementing the Comparable interface. This may not mean much right now, but this is how we can later use a sort on the ArrayList and get our cards in a particular order. This is also the same interface used on letters to determine how to sequence letters.

Deck

Just like with the Dice, we have the plural form of card called Deck. It's a very simple class, but all concepts related to a set of cards would be housed here. Note a few features:

• Notice how I can shuffle the cards by using a Deck function. This reduces the number of times I may need to implement this function in my code.
• Notice there is a quick way of getting a standards deck of 52 cards by using embedded for loops. This takes advantage of the numerators as if they were lists and you can iterate over the lists.

I have left an example of how to move a card from one deck to another. This is a great concept to understand since we can pull out objects from one place and place them in other places. Consider features of the code and discuss them as examples on this week's Q&A.

Assignment Details

The assignment submission is as follows:

1. Theater App
1. Create ArrayLists for the Theater, Movies, and MovieShowing.
2. Using your menu, create the features for listing, adding, and removing from each of the three areas.
2. Smart Home App
1. Create ArrayLists for each of the kitchen items.
2. Using your menu, create features for listing, adding, and removing the kitchen smart devices.

The focus of this assignment has more to do with \"how you do it\" rather than observable behavior. For R1.1 and R2.1 of this deliverable, I will be specifically looking at your code looking for you to use ArrayLists. For R1.2 and R2.2, I will be exercising your menu to have it list or add or remove elements. This will require you to create some test data. On the Smart Home side, you can combine all of your kitchen devices into a single ArrayList (will take some research on how to do this - related to inheritance) or you can use separate ArrayLists for coffee makers and refrigerators and stoves and each other item. In that case, you may only have 1 item in the ArrayList, such as having only one stove in a kitchen, but that is perfectly fine. Keep in mind, it would be a good test of your system to add in several of each item into the ArrayList to build a more robust or professional kitchen. Challenge yourself by uniquely identifying appliances and trying to remove them from the list, much like removing a specific card from a deck.

If you have questions on the Theater App or Smart Home App, please try to phrase them in terms of the Games App or the Theater App but DO NOT phrase it in terms of the Smart Home App. Part of the assessment is how well you can translate the concepts across different contexts. This is a lot like finding a similar solution on GitHub or Stack Exchange but you still need to operationalize it in your own context, which helps to demonstrate you understand the concept.