6 ms·

Same story repeating over and over again. Initial hype. Then abuse and overuse. Disillusionment. Decline. At some point people will finally figure out what OOP

• dennisgorelik 6y ago
  It is better not to put business logic into data model - in order to: 1) Keep your business logic simpler. 2) Keep your data model simpler. If you put both business logic and data model in the same class, then: - When you investigate data references pointing to your class -- you will see references noise from your business logic. - When you investigate business logic references pointing to your class -- you will see references noise from your data model. 3) Combined "business logic + data model" class is much harder to refactor. So, technically, you can combine business logic and data model in the same class. But practically, such code combining will significantly complicate maintainability of your code.
• valbaca 6y ago
  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)
• Rochus 6y ago
  There is no relation to the paper. Recommend that you first take a look at it.
• deleted 6y ago
  [deleted]