5 ms·

Ok, so there are a few comments claiming that this kind of revelation only seems valid because the author hasn't seen OO done right, or has only seen bad OO cod

Ok, so there are a few comments claiming that this kind of revelation only seems valid because the author hasn't seen OO done right, or has only seen bad OO code. As someone who has gone through a similar shift and feels disenchanted with a lot of the OO code I deal with on a daily basis, but is still very much aware of my own inexperience and naivete, I'm wary of these claims but I'm curious. So what's some really great, clean, elegant object oriented code that I could read to better understand what makes up good OO design? What are the books one should read to develop a deeper understanding of OO's qualities? It doesn't matter what language or platform they focus on, since I think the fundamentals ought to be independent, and I'm willing to work hard. Rails internals, Django internals? Some Java framework? Or is there some awesome piece of Smalltalk code out there that demonstrates the roots of OO? Is the Gang of Four book still relevant? Where do you go for getting the bigger design picture? For context, I've done a lot of Java (Android) but I don't think I've been exposed to good large scale design in Java (I've read Effective Java and Java Concurrency in Practice, but both of those deal with the nuts and bolts of programming in the small) Most of my functional programming experience is with Clojure, which is very opinionated and takes a radical approach to OO, and I think the bar has been set kind of high by Rich Hickey. Please don't tell me to go get a job at Google or your company where the code is beautiful all the time; that's just not fair.

raganwald 14y ago
there are a few comments claiming that this kind of revelation only seems valid because the author hasn't seen OO done right, or has only seen bad OO code That argument is also known as, “No True Scotsman.” People regularly jeer at it when process proponents defend their practices by saying “Yes, that project failed, but you weren’t doing Waterfall/XP/Scrum/Spiral right.” But there’s no reason why we shouldn’t poke it with a sharp stick when defending a technical argument. If so many people are "Doing OOP Wrong," shouldn’t we have serious reservations about it? I’m sure that if we pick any practice, we can cherry-pick and find some great code written with it. But what good is it if such examples are rare?
- pgsandstrom 14y ago
  Just as you might dismiss the arguments as "No True Scotsman" you could dismiss the original post as anecdotal evidence. The presence of a fallacy does not directly affect the truth of the point being made.
  - raganwald 14y ago
    No, but if all the arguments for and against boil down to anecdotal evidence and fallacies, why are we bothering with a discussion at all?
benjiweber 14y ago
I recommend Domain Driven Design by Eric Evans. There is an argument that OO is bad because it's so hard to do well. I have yet to be convinced that the same doesn't apply to Functional Programming.
- batista 14y ago
  Yes, but the difference is Functional Programmers don't have to actually build anything. They made a well funded mess in the eighties with the AI research, and now they can just feel superior to anybody else while producing a tiny percentage of production code in all fields combined, and not very good or popular one at that. The most popular or useful thing a functional programmer can build (or has every built, Emacs aside) is his own functional language. /s
  - dman 14y ago
    I find it ironical that you are typing this into hacker news.
    - batista 14y ago
      Well, I posted it tongue in cheek. I love me some Scala. What I find surprising is the lack of downvotes!
dustingetz 14y ago
i've been exploring these ideas myself, and i sort of think everyone is asking the wrong question. its not OOP vs OOADP (or whatever), its a reflection on OOP as it exists today, which for better or worse is mostly java. OOP in java is broken - not because an expert can't wield java effectively, but because someone with only java experience will probably not be able to learn effective OOP on their own, because the things java makes easy - the "opinions" of the language - are often not in line with the most elegant "mental" solution, due to things like no concept of mutability, excessive reliance on objects with state instead of functions on data structures. the things java makes easy become idiomatic, and the things that aren't easy become non-idiomatic... these driving forces create a feedback loop that creates an entire ecosystem of programmers and codebases that are decidedly crappy. Combatting macroeconomics problems requires marcoeconomic solutions; education at the individual level isn't sufficient, we need a way to shift the balance of the feedback loop by creating a mainstream language which influences people towards good code. Clojure, as you point out, has taken great care to have sensible idioms, Clojure is an awesome language in that simply trying to learn it makes you a better programmer, because Hickey has infused it with his opinions of what is excellent code. whether or not OOP can be done right isn't an interesting question. I'd rather ask what factors in modern mainstream languages are encouraging poor code, and whether its possible to learn from this and design a language/ecosystem that doesn't suffer from these problems. Scala & Clojure have this as a stated goal.
jcromartie 14y ago
I haven't seen a good OO codebase either. I've been working with them professionally for about a decade. I've seen what I think are good OO APIs. But I haven't found a project with decent code yet.

raganwald 14y ago

there are a few comments claiming that this kind of revelation only seems valid because the author hasn't seen OO done right, or has only seen bad OO code That argument is also known as, “No True Scotsman.” People regularly jeer at it when process proponents defend their practices by saying “Yes, that project failed, but you weren’t doing Waterfall/XP/Scrum/Spiral right.” But there’s no reason why we shouldn’t poke it with a sharp stick when defending a technical argument. If so many people are "Doing OOP Wrong," shouldn’t we have serious reservations about it? I’m sure that if we pick any practice, we can cherry-pick and find some great code written with it. But what good is it if such examples are rare?

pgsandstrom 14y ago
Just as you might dismiss the arguments as "No True Scotsman" you could dismiss the original post as anecdotal evidence. The presence of a fallacy does not directly affect the truth of the point being made.
- raganwald 14y ago
  No, but if all the arguments for and against boil down to anecdotal evidence and fallacies, why are we bothering with a discussion at all?

benjiweber 14y ago

I recommend Domain Driven Design by Eric Evans. There is an argument that OO is bad because it's so hard to do well. I have yet to be convinced that the same doesn't apply to Functional Programming.

batista 14y ago
Yes, but the difference is Functional Programmers don't have to actually build anything. They made a well funded mess in the eighties with the AI research, and now they can just feel superior to anybody else while producing a tiny percentage of production code in all fields combined, and not very good or popular one at that. The most popular or useful thing a functional programmer can build (or has every built, Emacs aside) is his own functional language. /s
- dman 14y ago
  I find it ironical that you are typing this into hacker news.
  - batista 14y ago
    Well, I posted it tongue in cheek. I love me some Scala. What I find surprising is the lack of downvotes!

dustingetz 14y ago

i've been exploring these ideas myself, and i sort of think everyone is asking the wrong question. its not OOP vs OOADP (or whatever), its a reflection on OOP as it exists today, which for better or worse is mostly java. OOP in java is broken - not because an expert can't wield java effectively, but because someone with only java experience will probably not be able to learn effective OOP on their own, because the things java makes easy - the "opinions" of the language - are often not in line with the most elegant "mental" solution, due to things like no concept of mutability, excessive reliance on objects with state instead of functions on data structures. the things java makes easy become idiomatic, and the things that aren't easy become non-idiomatic... these driving forces create a feedback loop that creates an entire ecosystem of programmers and codebases that are decidedly crappy. Combatting macroeconomics problems requires marcoeconomic solutions; education at the individual level isn't sufficient, we need a way to shift the balance of the feedback loop by creating a mainstream language which influences people towards good code. Clojure, as you point out, has taken great care to have sensible idioms, Clojure is an awesome language in that simply trying to learn it makes you a better programmer, because Hickey has infused it with his opinions of what is excellent code. whether or not OOP can be done right isn't an interesting question. I'd rather ask what factors in modern mainstream languages are encouraging poor code, and whether its possible to learn from this and design a language/ecosystem that doesn't suffer from these problems. Scala & Clojure have this as a stated goal.

jcromartie 14y ago

I haven't seen a good OO codebase either. I've been working with them professionally for about a decade. I've seen what I think are good OO APIs. But I haven't found a project with decent code yet.