Hello, in this video, I will show you a couple of concrete examples of business problems and we will see how to model their domain in scala and how to implement the business logic. In the previous lectures, you have learned about methods, conditions, case classes, and sealed traits. These features are the building blocks for modeling the business domain of a program and implementing its business logic. In this video, you will see how to use these building blocks on larger examples and you will get some advice on how to manage the complexity of a programming problem. Let's start with the first example, what is the impact on the environment of video streaming? It depends on the quality of the video, whether it is in high definition or low definition, the duration of the video, and the type of internet connection. A simplified model of footprint is the following; first, Data centers consume electricity per megabyte of transferred video. Downloading the video requires a network infrastructure, which also consume electricity per megabyte of transfer video. We can distinguish two types of networks, mobile networks and fixed networks, which consume a bit less energy. Last, producing electricity emits greenhouse gases and in our case, we will use a word average value. The questions we want to answer are the following, what is the impact watching 30 minute series in high definition from a mobile phone and in low definition from a desktop computer? First, let's model the concepts that are relevant to our problem. We are interested in the experience of watching videos of some duration, some quality, and from some type of network. We will have a case class experience containing the duration of the video in seconds, the definition of the video in megabytes per second and the type of network used for downloading the video. We have seen that we want to compare two types of networks, so we can model the type network as an enumeration with the cases fixed and mobile. These two types, experience and network would be our domain model. We can validate that our model is expressive enough by constructing the scenarios we're interested in. In the problem statement, a lowQuality video has a bitrate of 0.3 megabytes per second and high quality video has a bitrate of 0.6. megabytes per second. For convenience, I defined a value 30 minutes that contains the number of seconds in 30 minutes. Then I can define the experience of watching a highQuality video from a mobile network to be an instance of experience of 30 minutes, highQuality and network that mobile. Similarly, I can define the experience of watching a lowQuality video from a fixed network to be an instance of experience of 30 minutes, lowQuality and network that fixed, this looks good. Let's move on and implement the business logic, which is the computation of greenhouse gases for given experience. Eventually we want to implement a method footprint that takes an experience as parameter and returns the amount of emitted carbon dioxide in kilograms. To implement this method, we first need to know the amount of data of the video, which we get by multiplying the duration of the video by the bitrate. Then we need to know the amount of energy per megabyte required by the experience, which is the sum of the energy consumed by the data center and the energy consumed by the network infrastructure. Let's create an intermediate value dataCenterEnergy, containing the amount of energy per megabyte consumed by data centers based on the information provided in the problem statement. Similarly, we can create an auxiliary method that returns the energy per megabyte consumed by each type of network. Here we have 202 cases. We can now complete the implementation of the footprint method and compute the amount of carbon dioxide by multiplying the energy intensity by the number of megabytes, which gives us a number of kilowatt hour that we finally convert into kilograms of carbon dioxide with these conversion factor. I find it more readable to give a name to this conversion factor. I'm creating a val kilogram of CO2 per kilowatt-hour. Now that the method is implemented, we can call it to compare that two experiences. Here that was a def not a val. Now it works. We see these differences in the results. Let's now have a look at a second example. Set is a card game where three cards makeup a set if they satisfy some properties. Let's explain the game and see if we can implement it in scalar. The cards have four features across three possibilities for each kind of feature. The first feature is the shape, which can be either a diamond, a squiggle, or an oven. The second feature is the number of shapes under card 1,2 or 3. The third feature is the shading. It can be solid, striped or open. The last feature is the color. It can be red, green, or purple. Three cards make up a set if all the following properties are satisfied. The three cards all have the same number of shapes, or they have three different numbers of shapes. The three cards all have the same shape or they have three different shapes. Then three cards all have the same shading, or they have three different shadings, and the three cards all have the same color or they have three different colors. Let's practice a little bit. If we take the three cards on the left column. Do they satisfy the four properties? They all have the same number of shapes. One shape. They all have different shapes, and over here, a squiggle here and the diamond here, they all have the same shading, solid, and they all have the same color, red. The four properties are satisfied. These three cards make up a set. Now let's look at the three cards on the right, on the first row. First, they have a different number of shapes. Two here, three here, and one here. They all have a different type of shapes. Squiggles here, diamonds here and over here. However, two cards are stripped, and the third is open. They don't all have the same shading, nor three different shadings. Those three cards don't make a up a set. Could we implement a method that takes three cards of the game and return whether the cards make up a set or not. What is our domain model? We are interested in cards which are defined by four features or shape, the number of shapes, a color and a shading. Let's define a case class card that aggregates a shape, a number, a color, and a shading. There are three possible values for a shape. It's an enum with the cases diamond, squiggle and oval. Same for color. It's an enum with the cases red, green, and purple. Same for shading. It's an enum with cases open, striped and solid. Can we construct sensible instances of this model? For example, can we construct a deck with these three cards here? It would be a list of a card of shape diamond, one Color.Purple, Shading.Striped. Another card of shape squiggle, two Color.Red and Shading.Open, and a card of Shape.Oval, three Color.Green, and Shading.Solid. This looks good. However, note that we can also construct nonsensical instances like a card with zero shapes, this card does not make any sense or it could have more than three shapes or a negative number of shapes. We should avoid this, otherwise, the business logic might be impossible to implement. We can fix the problem by changing the type we use for modeling the number of shapes instead of Int, let's use another enumeration number with exactly three cases. Now that our model is ready, we can implement the business logic. We want to implement a method that takes three cards as parameters and returns two if they make up a valid set. Let's call it isValidSet. The implementation consists of checking the four properties. First as a shape property, and then the number property, the color property, and finally the shading property. Instead of writing everything in the body of the method isValidSet, it's more convenient to structure the implementation into smarter methods that we combine together with End. Let's implement checkShapeProperty. It takes three cards and returns whether the three cards all have the same shape or if they have three different shapes. I define intermediate computations, allSame and allDifferent, and I return allSame or allDifferent. Finally, though implementations of allSame and allDifferent are straightforward, we compare the shapes of the cards. The methods, checkNumberProperty, checkColorProperty, and checkShadingProperty are very similar except that we replace that shape by that number, that color, and that shading respectively. By the way, we could write a method checkProperty that would generalize these four methods but this is left as an exercise to you. It would be nice to compare and discuss your solutions under discussion forums. We have implemented all the pieces, we can now check whether three cards from a valid set or not by coding isValidSet with three cards. We see that those three cards here make up a set. Those three here don't make up a set because I've changed the number of shapes here. Let's take a step back and reflect on what we have been doing through these two examples to see if we can find general advice for domain modeling. We have identified the concepts that we are interested in and the relations between them. To achieve this, we asked questions like, does a concept belonged to another one or does a concept generalize another one? We have translated each concept into a type definition. Concepts belonging to others become parameters of case classes and concept generalizing others become sealed traits. Then we checked that we could construct meaningful instances from our model and more importantly, that we could not construct nonsensical values from the model. Finally, we implemented the business logic operations and the model. To summarize, reify the concept in general nouns of a business domain into case classes and sealed trait. Check that the values derived from your model are valid by construction and that they make sense for your problem and implement the business logic as operations on your model.