3 ms·

Abstract concepts map very well to objects. The problem of mapping a business domain to computing structures isn't unique to OOP. In this case, I'm slightly g

Abstract concepts map very well to objects. The problem of mapping a business domain to computing structures isn't unique to OOP. In this case, I'm slightly gobsmacked that no-one pointed out that an employee is not their job. The contract of employment is a separate domain concept. So is the invocation of the clauses of that contract. Termination involves invoking a particular contract clause. The job is to model a) the contract, b) the invocation of a specific clause, c) the record of that invocation (including its authorisations and so forth), and d) the consequential processing in other systems. Whether you're working in FP, or Kay-style OOP, or Java-style OOP or, heck, SQL stored procedures, these are separate concerns, separate concepts, separate units of code, separate records, hopefully loosely coupled by whatever idiomatic form is at hand.

nimblegorilla 6y ago
> Abstract concepts map very well to objects. The problem of mapping a business domain to computing structures isn't unique to OOP. Yes, I agree in theory. What I meant to say is that many concepts don't map to physical objects. > In this case, I'm slightly gobsmacked that no-one pointed out that an employee is not their job. The contract of employment is a separate domain concept. This is what I mean by flamewars. Your solution sounds good, but there are other people on this same thread still arguing that it makes perfect sense for an employee to fire itself.
- inopinatus 6y ago
  The litany of category and analytic blunders on display in that subthread is remarkable, but it’s hardly intrinsic to OOP, and mostly attributable to inexperience.