1. 19
  1.  

  2. 1

    Why not just have a Manager constructor for Contractor and one from Employee. After all a manager isn’t a kind of employee, because they can also be a Contractor.

    1. 2

      And yet they obviously are, because they are necessarily an employee of a company themselves, no matter what the UML diagram says. (Presumably there’s a need for reuse of Employee code/methods in Managers, and that should really be what leads you down the path of what belongs where, rather than “this can’t be the case because it doesn’t fit the class hierarchy”, which is a backwards argument when you’re trying to design the hierarchy.)

      The point is kind of that trying to tie yourself down to what can be modelled with OOP like this leads to sentences like this:

      After all a manager isn’t a kind of employee, because they can also be a Contractor.

      1. 2

        A contractor isn’t an employee (I assume that was the point).

    Stories with similar links:

    1. Semantic Compression (2014) via inactive-user 1 year ago | 6 points | no comments