Object-Oriented Programming 2023/24

Exercise 3


back


Project

Make use of the possibility to consult your project objectives with the teachers at exercises. Here, a general approach to project realization, which goes beyond this one exercise, is described. For now, study it and, by the next exercise, make sure to know what your project will be aiming at and that you are able to diagrammatically express its essence as it is explained further.

Assume that your program is running and identify one or two typical situations that arise there. Think of what important objects are there in a given situation. What are their properties? Draw these objects and connect by edges those objects between which you assume interaction to occur. In this moment, do not worry about classes, but do mind the appropriate object naming. To draw such an object diagram you can use the UMLet tool. Have a look at an ogres and knights game object diagram example that depicts an ogre and knight interaction (PDF/UXF) or at another object diagram that shows also the clash object (PDF/UXF).

The object you have identified can be generalized, by which you will gain the key classes of your program. Class names come out of object names. Relationships between classes come out of object links. At this level, you can restrict yourself to two types of relationships: a general association and inheritance. The properties of the objects that had been identified represent the attributes and methods of these classes. To draw such a class diagram you can use the UMLet tool again. Have a look at an ogres and knights game class diagram example (PDF/UXF).

Create a provisional implementation of the classes you have identified (write their code). Some of their parts will remain unclear, but still you can create a few objects out of them and try the functionality you provide.

Check the functionality by simple text outputs to the standard output (by using print() or println()). If you need an input, you can use standard input and output, for which an example of reading a console input can be of help to you. You will elaborate the user interface later. Already at the next lecture, we will talk about graphical user interface.

Some of the classes might be in an inheritance relationship. You might not want to allow for creating objects out of some classes; these are going to be abstract. Already now, you might identify some interfaces, too.

You will be able to change everything later, but try already now to look beyond simply providing the functionality being desired and add the flexibility of applying polymorphism. Your program should be open for extension without the necessity to modify its basic logic. We reached a similar state in the game with ogres and knights, in which, despite extensions, the clash() method of the Clash class consists of a loop that was there already in the first version of the code.

^


UMLet

In CPU, a tool for drawing UML and other kinds of diagrams is available: UMLet. You can download and install the tool on your computers. An online version is also available: UMLetino. With both tools, make sure to save your diagrams in the UXF editable format, and not as images or PDF files.

You choose the elements form the palette available on the right side by a double click. Afterwards, you can edit the element you selected in the field under the palette. In the File menu, you have a possibility to export the diagram.

^


Tasks

  1. In the game with ogres and knights from the lecture, the Observer design pattern was applied.
    1. Study the realization of this pattern in the game.
    2. Add another observer of one of two existing kinds.
    3. Add another kind of an observer.
  2. In the game with ogres and knights from the lecture, the Strategy design pattern was applied.
    1. Study the realization of this pattern in the game.
    2. Change the strategy to another one of the existing two.
    3. Add another strategy.
  3. In the game with ogres and knights from the lecture, the Visitor design pattern was applied.
    1. Study the realization of this pattern in the game. Note the absence of the explicitly singled out Visitor interface and the extension of the accept() operation (method) argument list.
    2. The attack() method of the Knight class is overridden in the BraveKnight class, but its body is only repeated. Delete this method from the BraveKnight class. Run the program. Note (by its output) that during an attack, all knights behave as objects of the Knight class. Why? If you can't find the reason, click here for a hint. (For the following tasks, restore the code into its previous state.)
    3. Add another kind of a sword. Do knight classes have to be modified?
    4. Add another kind of a knight. What do you need to change in the classes that represent kinds of sword? Do other knight classes have to be modified?
  4. (Finish for homework.) Try the examples of the Observer, Composite and Strategy design patterns sketched out in the provided code. The code is provided in a simplified form: the complete code is provided in a single file (you can divide it into files according to types). In the Observer pattern, try to add another way of displaying temperature, for example, high/low temperature or temperature rounded to a whole number. The example of the application of the Composite and Strategy design patterns is only sketched: the code has to be elaborated in order to make it runnable. Set aside Lists (List and ArrayList) and so-called extended for loop for now. We will get to these in the lecture on structured data types, generics, and persistence.

^



Valentino Vranić
vranic at stuba.sk