This is the last series of episodes of this MOOC, introducing object-oriented programming (OOP) in Java. In this last series of episodes, we wanted to present to you an entire problem, a very general problem, a case study which will consist in representing different watches. There will be analog watches, digital watches, watches that will be both; watches will have accessories such as bracelets, bodies,... So a rather general frame which could serve for example as management software for a jeweler's or as sales software or even for printing catalogs. Through this, we will illustrate different concepts that were presented all along this course. The themes we have chosen to present to you in these summary episodes include first of all the notion of conception, the modelling of a problem from an OOP point of view : which classes have to inherit from which other ones, whether abstract classes are needed, how to make the calculation of watches' prices polymorphic, or how to make the output polymorphic. Output will be treated in a very specific way, with an override of the toString method inherited from Object, and an adaptation of the output for each class, to have a polymorphic output. We will also go over interfaces, with the different mechanisms, digital or analog watch mechanisms, and even double mechanisms, which will be both analog and digital, then we will end with a last episode presenting a problem we have not yet seen in this course, which is the notion of polymorphic copy, how to copy heterogeneous collections; how to copy watches which can contain different components, each behaving in different ways, on the point of view of either price or display. This is the menu for this final week. But let's start by presenting the problem in more detail. We want to model watches, let's say that watches are products, in the sense that a product is something that we can sell, that has a price. Watches will have basic mechanisms, typically hands, to display the time, and will be made of different accessories such as a body, a bracelet, the glass, the clasp. The products we will discuss later on will have a price, and the calculation of this price can vary. So this aspect is interesting for conception, as it varies depending on a base price that is fixed at the level of the product. All products can be displayed, and the output can vary, as each product must be displayed in its own way. Of course, what is behind these notions of "can vary" and "displayed in its own way", is the concept of polymorphism. Then, the mechanisms we have discussed just above, and the accessories that make up the watches, these mechanisms and accessories are also products. We have used the verb "to be" several times, which refers to inheritance relationships. We could for example buy accessories or mechanisms separately, so each of these could behave like a product, and have its own price, and its own way of calculating its price. Fundamentally, there are three sorts of mechanisms: mechanisms we will refer to as analog, to represent watches with hands, whereas digital watches will be represented by a digital mechanism, and we will have watches that are both analog and digital. For mechanisms that we call double mechanisms, we will suppose that they display only one time, so we will say that there is a time associated to a watch here, and that it will have two ways of being represented. This is a point of view chosen as an exercise we could of course have chosen a different point of view which would consist in associating a time to each of the representation mechanisms, either analog or digital, but it is not the point of view that we took here, in order to introduce an interesting problem on coding these classes. To sum up, regarding classes, that is, regarding the types of objects that we will have in our program, we will have watches, we will have products, we will have mechanisms and accessories, where accessories can be bodies, bracelets -- all of these will be classes -- regarding mechanisms, we can have analog mechanisms, digital mechanisms, or double mechanisms. That is the whole set of classes. Regarding inheritance relationships, we have seen that watches are products, so they will inherit from Produit (TN: means "products"), we have seen that analog, digital and double mechanisms are sorts of mechanisms, so these three classes will naturally inherit from the Mecanisme class We have also seen that mechanisms and accessories are also products. So all of this will lead to the following hierarchic model: Right at the top, we have the concept of a product, accessories, mechanisms and watches are products (TN: "montre" means "watch") however, a watch will have a mechanism and accessories, so it will encapsulate those classes. Among the accessories, we will find bodies, bracelets (TN: "boitier" means "body"), clasps, glasses (TN: "fermoir" and "vitre", resp.), all of these are accessories. Mechanisms can be analog or digital, these are both mechanisms. Finally, the double mechanism. Originally, it is a mechanism, but we have decided, according to the last remark, that it indicated only one time, which we will certainly represent at the level of the notion of mechanism, and that it behaves both as analog mechanism and digital mechanism, which will certainly require an interface, but we will see later on how to model this exactly. Let's see how all of this can be translated into code By the way, we suggest that while you watch these videos, you take breaks from time to time to write the code yourselves in your favorite development environment. First point, watches are products, this is represented with a Montre class, which is a, which inherits from Produit, and so of course we introduce a Produit class, of which Montre inherits. And for now, we simply have an empty main. Second point, watches have a mechanism, so they will encapsulate a mechanism, watches have a mechanism and are made of, they have, different accessories. So how do we translate different accessories? It is simply a collection of accessories, a dynamic array of accessories. And so this introduces two new classes. A Mecanisme (TN: "mechanism") class and an Accessoire (TN: "accessory") class. Next aspect: products have a price So we could simply encapsulate a price, naturally represented as a double, but we have a constraint saying that the price can vary, which shows that we will have to calculate the price. For example, later on, we will decide that the price of a watch is the price of its mechanism and the sum of the prices of its accessories, and so a price is no longer a datum but becomes a process, which we will represent with a method here. This method returns a price, naturally a double, then we want to say that the price can vary, so this means that we may have a polymorphic behavior Let's say that, by default, we will return the base price, the base value, and so what we called a price, earlier, will become a base value, to be the price of the product by default, but maybe later, in other subclasses of the Produit class, it will simply be used in different calculations for the price of other products, subclasses derived from the Produit class. Moreover, all products can be displayed, which means concretely that we will add a polymorphic toString method, that will be capable of giving us a character string corresponding to displaying a product. Products can be displayed but each in their own way which means that we will have a polymorphic output. We will leave this for the next episode, we will come back to it in that episode For now, we will simply write a header to remember that we want to override the toString method for products. Regarding mechanisms and accessories, we said that mechanisms and accessories are products. So here too, we have an inheritance relationship, where the Accessoire class inherits from the Produit class which was defined earlier, and the Mecanisme class also inherits from the Produit class. About mechanisms: there are three kinds of mechanisms so these three classes, of course, extend Mecanisme. We have MecanismeAnalogique (TN: means "analog mechanism") which is a Mecanisme, which inherits from Mecanisme, we have MecanismeDigital which inherits from Mecanisme, and MecanismeDouble which also inherits from Mecanisme. And final point, about double mechanisms, we will suppose that there exists only one time within the double mechanism, but that double mechanisms behave as analog mechanisms and as digital mechanisms, which is something we haven't translated here, and which will affect this inheritance relationship, but we will come back to that in an episode specifically dedicated to that aspect. There, this concludes this first episode on the presentation and object-oriented modelling of the problem. The next episode will focus on polymorphic display and on filling the Produit class.
