Class Design page

[mattagape]

1. In code snippet self.position+= self.velocity*delta_t the C++ code makes clear that delta_t is a single quantity (double) rather than a list. That suggests the bird is flying at the same speed in all 3 directions; would it not be better to have a triple of speeds to comprise the velocity list, so they can be different in different axes? Or have I misunderstood?

   2. YUML diagram link needs to end with a ].

2. In "Property accessors" section, get_married() method disappears from new version.

3. "Using Objects doesn't mean your code is object-oriented." Is that a fair comment?

4. In "Inheritance in python", maybe add a Starling class with a flee() method, to show that we can have multiple different classes inheriting from the same parent. (This is indeed seen in the UML diagram a little further down).

5. In same block we should say that a child class extends a parent class (adds functionality) (usually) and that a parent class can be used to abstract common behaviour. Plus use of the terms "parent" and "child" should be introduced.

6. Typo in "Aggregation vs Inheritance" section: overal should be overall.

7. "Refactoring to inheritance" section: People are not Animals. Replace Animal class with LivingBeing class.

8. Wikipedia article on duck typing says this term is synonymous with dynamic binding; if so, the latter term should be used.

9. "Interfaces and concepts" section. It would be better to reword "Classes which define these methods, which cannot be instantiated into actual objects..." as "Classes which define these methods, but which cannot be instantiated into actual objects..." as not all classes with virtual methods cannot be instantiated in C++.

10. Add reference to book "UML Distilled" by Martin Fowler. https://martinfowler.com/books/uml.html

[ageorgou]

1. Information hiding: I would be more explicit about what single and double underscores mean. Perhaps start from a language-agnostic (or perhaps Java-like) point of view, and use public/private terminology, then say what of that you can do in Python and how.

2. Aggregation vs Inheritance: This section makes it sound like a solution to the Boids example should be given in the week before this lecture; do we need to move things around?

3. Refactoring to inheritance:

   • After refactoring, should have a Pet class with owner field.
   • Regarding super: it might be better to just use the simpler super().__init__ form, which in Python 3 does the same as super(Person, self) in this example, and doesn't require explaining the arguments to super. I don't think it's worth going into details about how to use super besides this simple case, for this class.

4. Interfaces and concepts: Typo in the last sentence: "A class is said to "implement and interface"" should be "... an interface"".

[dpshelio]

@mattgillucl

1. It's a particle, not birds. A single value is expected.
2. fixed
3. fixed - that was a change made after a question. I added comments around to make properly part of the notes.
4. Yes. That's how it's object-base vs object-oriented
5. Added
6. Added
7. fixed
8. As the scientific classification we are animals, so kept as it is to don't change the relation with the rest.
9. duck typing is the term used by the community. Personally I found it clearer as it highlights the process based on "behaviour".
10. fixed
11. added

@ageorgou

1. I've added a line explaining the use.
2. :man_shrugging:
3. a) fixed ; b)fixed
4. fixed