5 ms·

Wow, I am genuinely shocked by the comments in this thread. I didn't realise that so many people held the polar opposite view to me. It's a bit like suddenly

by MarkMc 14y ago

Wow, I am genuinely shocked by the comments in this thread. I didn't realise that so many people held the polar opposite view to me. It's a bit like suddenly finding out that all your friends are racist. I love object oriented programming. For me it aligns perfectly with the way I think - it allows me to produce a system of interrelated 'things' where each thing (or group of things) has a well-defined role and can hide its internal state and behaviour from other things. When I see how some code tackles a problem I get an emotional response from how 'clean' it is. Does it smell bad or is it a work of beauty and elegance? If the code feels wrong I get an urge to make it better and for me that process of improvement relies heavily on object-oriented concepts. I get a real buzz from creating a clean, elegant solution to a problem: Trying to do that without object-oriented features would be like trying to write a letter by holding the pen with my teeth. Ugh.

pacala 14y ago
You may enjoy learning a language with decent module system. Abstract APIs are not exclusive to OO. The confusing part about OO is that it conflates modules with data types, which causes even experienced people to botch their designs. Tongue in cheek: As long as you have enough discipline to write OCaml in whatever OO language your project happens to use, you are going to have a good time.
seanmcdirmid 14y ago
I'm also an object luver; I prefer to think about my designs in objects in a very anthropomorphic way. There are plenty of examples of bad and good designs in any language, while any paradigm is not a panacea. Bad OOP designs only dominate the industry b/c OOP dominates. You can build some beautiful systems with a functional programming language, especially if you are into formal mathematical elegance, I've ween some amazing things done with Haskell. But the systems I work with are very intrinsically stateful; objects just work better.
fauigerzigerk 14y ago
So what is the natural and clean design for an operation that represents the sale of a property? Say we have these objects: the buyer, the seller, the agent, the property and the contract. Which one of these would you prefer? property.sell(buyer, seller, agent, contract) seller.sell(property, buyer, agent, contract) buyer.buy(property, seller, agent, contract) agent.sell(property, buyer, seller, contract) contract.sign(property, buyer, seller, agent) The state of all the objects may be modified, and there are different types of properties, buyers, sellers and agents. So you might want polymorphism along any of those hierarchies.
- ajanuary 14y ago
  Which one is best: cats, alligators or pencils? You're question is about how best to model a domain of which you've given the scantest of details. Domain modelling is something you have to do in any programming paradigm and is equally as obtuse if you don't have proper knowledge of the domain. Come back with a more detailed description of the domain and then we can start comparing the emergant designs from OO and other paradigms.
  - fauigerzigerk 14y ago
    The point is, if several objects are involved, all of them get mutated and all of them are in a type hierarchy, you're going to have a hard time justifying which object should be the receiver of the message based on what feels more natural.
- MarkMc 14y ago
  Without knowing any more about the system I'd suggest: contract.sign(property, buyer, seller, agent) It seems that properties, buyers, sellers and agents could exist without 'knowing' about contracts, but a contract at some point needs to reference the other entities. Also, it seems odd that the contract can exist without knowing the details of buyer, seller, etc. I'd prefer: new Contract(property, buyer, seller, agent) and if possible make it immutable.
  - fauigerzigerk 14y ago
    I would tend towards this solution as well, but does it meet the "looks natural" criteria? Contracts that sign themselves? I think many classes we invent are nothing more than processes in disguise and we could just as well model them as functions. A simpler example. Should the BankAccount class have a transferTo(BankAccount other) method to transfer money into another account? What if there are different account types and the exact process depends on the types of both accounts? Of course it's possible to do it that way, but is it really the cleanest way to imagine this? I don't think so.
    - 14y ago
tikhonj 14y ago
"Trying to do that without object-oriented features would be like trying to write a letter by holding the pen with my teeth" I think what you're imagining here is Java without the OO bits. And that would be horrible! What you should imagine is Haskell. That's more like typing a letter instead of hand-writing it, to overstretch your metaphor. I've found that it's much easier to write much more elegant code in Haskell than it is in any OO language. Instead of writing a program without OO features, you're writing a program with advanced functional features. Rather than just being removed, the OO features are replaced.

by MarkMc 14y ago

pacala 14y ago

You may enjoy learning a language with decent module system. Abstract APIs are not exclusive to OO. The confusing part about OO is that it conflates modules with data types, which causes even experienced people to botch their designs. Tongue in cheek: As long as you have enough discipline to write OCaml in whatever OO language your project happens to use, you are going to have a good time.

seanmcdirmid 14y ago

I'm also an object luver; I prefer to think about my designs in objects in a very anthropomorphic way. There are plenty of examples of bad and good designs in any language, while any paradigm is not a panacea. Bad OOP designs only dominate the industry b/c OOP dominates. You can build some beautiful systems with a functional programming language, especially if you are into formal mathematical elegance, I've ween some amazing things done with Haskell. But the systems I work with are very intrinsically stateful; objects just work better.

fauigerzigerk 14y ago

So what is the natural and clean design for an operation that represents the sale of a property? Say we have these objects: the buyer, the seller, the agent, the property and the contract. Which one of these would you prefer? property.sell(buyer, seller, agent, contract) seller.sell(property, buyer, agent, contract) buyer.buy(property, seller, agent, contract) agent.sell(property, buyer, seller, contract) contract.sign(property, buyer, seller, agent) The state of all the objects may be modified, and there are different types of properties, buyers, sellers and agents. So you might want polymorphism along any of those hierarchies.

ajanuary 14y ago
Which one is best: cats, alligators or pencils? You're question is about how best to model a domain of which you've given the scantest of details. Domain modelling is something you have to do in any programming paradigm and is equally as obtuse if you don't have proper knowledge of the domain. Come back with a more detailed description of the domain and then we can start comparing the emergant designs from OO and other paradigms.
- fauigerzigerk 14y ago
  The point is, if several objects are involved, all of them get mutated and all of them are in a type hierarchy, you're going to have a hard time justifying which object should be the receiver of the message based on what feels more natural.
MarkMc 14y ago
Without knowing any more about the system I'd suggest: contract.sign(property, buyer, seller, agent) It seems that properties, buyers, sellers and agents could exist without 'knowing' about contracts, but a contract at some point needs to reference the other entities. Also, it seems odd that the contract can exist without knowing the details of buyer, seller, etc. I'd prefer: new Contract(property, buyer, seller, agent) and if possible make it immutable.
- fauigerzigerk 14y ago
  I would tend towards this solution as well, but does it meet the "looks natural" criteria? Contracts that sign themselves? I think many classes we invent are nothing more than processes in disguise and we could just as well model them as functions. A simpler example. Should the BankAccount class have a transferTo(BankAccount other) method to transfer money into another account? What if there are different account types and the exact process depends on the types of both accounts? Of course it's possible to do it that way, but is it really the cleanest way to imagine this? I don't think so.
  - 14y ago

tikhonj 14y ago

"Trying to do that without object-oriented features would be like trying to write a letter by holding the pen with my teeth" I think what you're imagining here is Java without the OO bits. And that would be horrible! What you should imagine is Haskell. That's more like typing a letter instead of hand-writing it, to overstretch your metaphor. I've found that it's much easier to write much more elegant code in Haskell than it is in any OO language. Instead of writing a program without OO features, you're writing a program with advanced functional features. Rather than just being removed, the OO features are replaced.