5 ms·

Just to set some context, I'm of the "OOP Generation" where I learned to program when OOP was at its zenith. Every major language was Class-based OOP (C++, C#,

Just to set some context, I'm of the "OOP Generation" where I learned to program when OOP was at its zenith. Every major language was Class-based OOP (C++, C#, Java, Python, Ruby) and it was just THE way to code for all things in the foreseeable future. That said, I've since looked into and learned other methods of programming: classic C, prototype-based JS, functional Clojure, and Go. From what I can gather, even from the SOLID principles and other Class-based OOP advice (prefer composition over inheritence) is that Interfaces (as abstraction and reuse), Aggregation (that objects can have other objects), and Delegation (which allows of ergonomic aggregation) are the real winners of OOP. In this way, Go gets it mostly right IMO, though at the risk of "initial hype" I'm still cautious on it. It feels so backward that OOP is taught with a focus on abstract & subclasses, with very little emphasis on interfaces, which is really how we achieve the goals of abstraction and reuse. What's funny is seeing languages like Java trying to "undo" the arguable "mistake" of abstract classes by adding more and more power into interfaces: default methods, etc. To your original conversation, there's a mix going on with "model." Are they talking about the Service's API Model, the internal model representation, or the database model? The outer layers (API & Database) of your code should be plain structs (POJOs in Java), but you're absolutely right that within the business code itself, you should have logic within the classes. Otherwise, you're not coding much different than C passing around struct pointers. Related terms: MVC, Data access object

lmilcin 6y ago
You need to read up on Anemic Domain Model (https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html). I see a lot of chaos in your post. Model is a model. Model is there to represent an aspect or aspects of a real system (https://en.wikipedia.org/wiki/Conceptual_model https://en.wikipedia.org/wiki/Conceptual_model). An object called "Employee" is a "model", a representation of certain aspect of an actual employee. Object oriented programming is about using objects -- models (representations of aspects) of actual systems, actors, objects, etc. In OOP you build the model from operations that define the object. The fields are not part of the interface, the operations are. That's why everybody says to make fields public (but for some reason not everybody remembers why). So a method call fire() on an object Employee is more "object oriented" than having HREmployeeService.fireEmployee(employeeId) to set field employedTo directly on EmployeeDAO.
- nimblegorilla 6y ago
  I think OOP is great, but one weakness is that a lot of abstract concepts don't really map to objects. And then people have flamewars about where to put those concepts. In the real world most employees would never fire themselves and HR would update things like payroll which the employee isn't allowed to change. Your example makes more sense as a justification for keeping a service layer.
  - lmilcin 6y ago
    As with almost everything, when you try to stretch an analogy or use a single tool for every job, you are going to run into problems. Every tool has limitations and so does OOP. Employee object is not a representation of the will of the employee. It is an interface with operations that are best naturally acting on an Employee object -- changing its state.
    - giantDinosaur 6y ago
      I suppose a manager is also an employee, but Manager inherits from Employee with a .fire() method seems wrong, no? I'd expect a method which takes another object or ID, not to change the state of the object with the fire() method. Anyway, this is why I stay far, far away from OOP when I can - vast amounts of time spent on these questions which generate zero insight (at least the mathematical obsession with some parts of FP can be fun)
  - inopinatus 6y ago
    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.
mikewarot 6y ago
I'm a Pascal programmer, so I come from a different heritage.... anytime I go to look at OOP in C++ or Java, etc... I see a fog of things about factories, and namespaces, and far, far too much code just to set up objects, which are glorified data structures with the code that manages it. I strongly agree with your conclusion that Composition, Interfaces, Aggregation, and Delegation are the real value in OOP. They all play very nicely together. Composition avoids the need to restructure everything into a single hierarchy. Interfaces make it possible to separate concerns, which lets you treat each library as a black box. Example: Imagine the electrical breaker panel in your home. The exact principles that cause the breaker to trip are irrelevant, nobody cares if it's thermal, magnetic, hydraulic, or whatever new tech comes down the block... all that matters is that it does the job in the described manner. It meets the goals of its interface. In hiding implementation behind the interface, you fend off premature optimization, and stave off technical debt by keeping things small enough to refactor at will. It is this standardization that allows you to add a Ground Fault Interrupter to a box that was designed before they became available. Aggregation is how you can have a series of fields in a form, all of different types, yet it all is a form. If one of those fields has a list of strings... nothing breaks, and you don't have to re-arrange everything to make it work. Example: Your breaker panel has any mix of 120 and 240 and GFI breakers, some even do 3phase power. Delegation is how the fields in a form let the details of where on the screen, and how to resize, just work. Example: Your breaker panel has X number of slots, provides a UL approved housing for them, with a reliable User interface. OOP isn't the problem, the teaching is.
apta 6y ago
> What's funny is seeing languages like Java trying to "undo" the arguable "mistake" of abstract classes by adding more and more power into interfaces: default methods, etc. Default methods are how Java-like languages are able to have mixins. They are extremely handy and quite safe to use as far as I can tell. golang on the other hand shows its extreme weakness in modeling non-trivial domains, and the code base quickly becomes very verbose and tedious to work in.

lmilcin 6y ago

You need to read up on Anemic Domain Model (https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html). I see a lot of chaos in your post. Model is a model. Model is there to represent an aspect or aspects of a real system (https://en.wikipedia.org/wiki/Conceptual_model https://en.wikipedia.org/wiki/Conceptual_model). An object called "Employee" is a "model", a representation of certain aspect of an actual employee. Object oriented programming is about using objects -- models (representations of aspects) of actual systems, actors, objects, etc. In OOP you build the model from operations that define the object. The fields are not part of the interface, the operations are. That's why everybody says to make fields public (but for some reason not everybody remembers why). So a method call fire() on an object Employee is more "object oriented" than having HREmployeeService.fireEmployee(employeeId) to set field employedTo directly on EmployeeDAO.

nimblegorilla 6y ago
I think OOP is great, but one weakness is that a lot of abstract concepts don't really map to objects. And then people have flamewars about where to put those concepts. In the real world most employees would never fire themselves and HR would update things like payroll which the employee isn't allowed to change. Your example makes more sense as a justification for keeping a service layer.
- lmilcin 6y ago
  As with almost everything, when you try to stretch an analogy or use a single tool for every job, you are going to run into problems. Every tool has limitations and so does OOP. Employee object is not a representation of the will of the employee. It is an interface with operations that are best naturally acting on an Employee object -- changing its state.
  - giantDinosaur 6y ago
    I suppose a manager is also an employee, but Manager inherits from Employee with a .fire() method seems wrong, no? I'd expect a method which takes another object or ID, not to change the state of the object with the fire() method. Anyway, this is why I stay far, far away from OOP when I can - vast amounts of time spent on these questions which generate zero insight (at least the mathematical obsession with some parts of FP can be fun)
- inopinatus 6y ago
  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.

mikewarot 6y ago

I'm a Pascal programmer, so I come from a different heritage.... anytime I go to look at OOP in C++ or Java, etc... I see a fog of things about factories, and namespaces, and far, far too much code just to set up objects, which are glorified data structures with the code that manages it. I strongly agree with your conclusion that Composition, Interfaces, Aggregation, and Delegation are the real value in OOP. They all play very nicely together. Composition avoids the need to restructure everything into a single hierarchy. Interfaces make it possible to separate concerns, which lets you treat each library as a black box. Example: Imagine the electrical breaker panel in your home. The exact principles that cause the breaker to trip are irrelevant, nobody cares if it's thermal, magnetic, hydraulic, or whatever new tech comes down the block... all that matters is that it does the job in the described manner. It meets the goals of its interface. In hiding implementation behind the interface, you fend off premature optimization, and stave off technical debt by keeping things small enough to refactor at will. It is this standardization that allows you to add a Ground Fault Interrupter to a box that was designed before they became available. Aggregation is how you can have a series of fields in a form, all of different types, yet it all is a form. If one of those fields has a list of strings... nothing breaks, and you don't have to re-arrange everything to make it work. Example: Your breaker panel has any mix of 120 and 240 and GFI breakers, some even do 3phase power. Delegation is how the fields in a form let the details of where on the screen, and how to resize, just work. Example: Your breaker panel has X number of slots, provides a UL approved housing for them, with a reliable User interface. OOP isn't the problem, the teaching is.

apta 6y ago

> What's funny is seeing languages like Java trying to "undo" the arguable "mistake" of abstract classes by adding more and more power into interfaces: default methods, etc. Default methods are how Java-like languages are able to have mixins. They are extremely handy and quite safe to use as far as I can tell. golang on the other hand shows its extreme weakness in modeling non-trivial domains, and the code base quickly becomes very verbose and tedious to work in.