Introduction to UML diagrams design
What we’ve discussed?
We’ve talked more about the UML notation that we’re going to use to design the class structures on our computers. You can find some more details at the exercises' description here.
We presented some examples of tools that can be used to create the UML diagrams for our class hierarchies:
You played a little with the class hierarchy for Queue collections and did really well with it 😊
However, when checking your solution diagram you should always take into account if:
- your abstract classes are clearly marked with italic text or with explicit A letter
- your abstract methods that you want to have an implementation in child classes are also marked clearly as abstract
- your fields and methods have proper visibility constrained - rule of thumb for fields: make it as private as possible (so start with -, if it doesn’t work - maybe # and at the end + but it’ll be rare for fields)
- every abstract method has some concrete implementation in concrete classes or on the chain between the definition as abstract method and the final concrete class - it has to have exactly the same signature (i.e. the name and the types of arguments)
- some methods may do the same things - we’ve had the example of Dequeue class that is also a Queue
- it has extra methods like Int popFront(), Int popBack(), Void pushFront(e: Int), Void pushBack(e: Int)
- but it has to have the implementation for the abstract methods from Queue like Int pop() and Void push(e: Int). We can assume (write in the documentation may probably on the diagram as some comment outside) what they actually do under the hood, but for the Dequeue, it’s important to have these 2 methods to be an actual Queue