3 ms·

I've found that most people who think Java is overly OO are actually writing procedural programmers, who use objects as ornamentation. It is fundamental to OO

by hodwik 11y ago

I've found that most people who think Java is overly OO are actually writing procedural programmers, who use objects as ornamentation. It is fundamental to OO that implementation details are not exposed. Accessor methods are, by their very definition, not Object Oriented. It's okay to use them, but you're not doing OO, and you very likely shouldn't be using Java if that's the case.

wtetzner 11y ago
Except that encapsulation doesn't make a lot of sense when you're just modelling information. For example, suppose you have an Employee class that contains the employee ID, name, birth day, etc. Employee records don't do anything. They're just data. Hiding that data makes no sense if the point of their existence is just to hold the data.
- hodwik 11y ago
  You don't simply model information in an OO language, everything is an object, you're supposed to model your domain. I don't reach into the employee class and "get" the employee ID so I can do something with it. The employee class knows what to do with their own ID. Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious. Low-level accessors to an "object's" state are almost never an accurate representation of the domain you are modeling -- they're bad design. If you need them, you've probably missed a piece of the puzzle. That being said, most programmers don't need to be doing OO at all. The level of guarantee it provides is, for most people, not worth the cost. In those cases, don't use Java. We will all be having this same argument about functional languages in 10 years. Mutability is not functional, if you're relying on mutability you're probably just doing procedural code wrapped up in functional decorations.
  - wtetzner 11y ago
    > everything is an object Well, if we're talking Java, not everything is an object. None of the primitive types are, and Java has static methods. > Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious. OK, so I picked a bad example. What if you're dealing with records of tree data? Are you suggesting that modelling the domain means that trees should know what to do with the information about their diameter? In what way is that modelling a domain? In software we're rarely writing simulations of the real world, and even then, it doesn't always make sense to have objects hide information that other agents could just observe about them. We're usually dealing with information, not actors.

by hodwik 11y ago

wtetzner 11y ago

Except that encapsulation doesn't make a lot of sense when you're just modelling information. For example, suppose you have an Employee class that contains the employee ID, name, birth day, etc. Employee records don't do anything. They're just data. Hiding that data makes no sense if the point of their existence is just to hold the data.

hodwik 11y ago
You don't simply model information in an OO language, everything is an object, you're supposed to model your domain. I don't reach into the employee class and "get" the employee ID so I can do something with it. The employee class knows what to do with their own ID. Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious. Low-level accessors to an "object's" state are almost never an accurate representation of the domain you are modeling -- they're bad design. If you need them, you've probably missed a piece of the puzzle. That being said, most programmers don't need to be doing OO at all. The level of guarantee it provides is, for most people, not worth the cost. In those cases, don't use Java. We will all be having this same argument about functional languages in 10 years. Mutability is not functional, if you're relying on mutability you're probably just doing procedural code wrapped up in functional decorations.
- wtetzner 11y ago
  > everything is an object Well, if we're talking Java, not everything is an object. None of the primitive types are, and Java has static methods. > Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious. OK, so I picked a bad example. What if you're dealing with records of tree data? Are you suggesting that modelling the domain means that trees should know what to do with the information about their diameter? In what way is that modelling a domain? In software we're rarely writing simulations of the real world, and even then, it doesn't always make sense to have objects hide information that other agents could just observe about them. We're usually dealing with information, not actors.