4 ms·

I've experienced this myself in the "religion" of OOD (in which I admit I used to be a fervent believer). I once showed my brother a Ruby script I'd written wi

I've experienced this myself in the "religion" of OOD (in which I admit I used to be a fervent believer). I once showed my brother a Ruby script I'd written with lots of clean encapsulation and a pile of reusable code -- and then he showed me how he would have hacked it together in 1/10 the code by NOT trying to design it to be "extensible." There's obviously a balance that you can strive for -- sometimes it IS best to design code to be reused. But in this case, unless my code were reused something like 20 times, I would have ended up with NET fewer lines of code by simply taking the NON OOD approach. And fewer lines of code means fewer opportunities for bugs. At this point I try to mix OOD with other paradigms, taking advantage of the strengths of each. Sometimes OOD IS the right answer still, but honestly most of the time it isn't. And OOD is verbose compared to other paradigms, especially when you're using a paradigm-agnostic language. (I suspect if you tried to code in Java this way it would fight you at every step, for instance.)

felipemnoa 14y ago
>>and then he showed me how he would have hacked it together in 1/10 the code by NOT trying to design it to be "extensible." Hacks like this do come back and bite you in the rear big time when latter on you want to extend it. Unless you are planning to trow it away or never modify it, it is a really bad idea.
- Scaevolus 14y ago
  Programs have inertia roughly proportional to their size. Extending a small program is almost always easier than a large program-- except for the special case where the large program was designed with the specific extension you're making in mind.
  - astrodust 14y ago
    You sound like a person who's never had to debug a hairball of a Perl program that looks more line-noise than source code. You can do just as much damage by being too concise as being too verbose.
    - mistermann 14y ago
      > You can do just as much damage by being too concise as being too verbose. Very true in my experience. Why do something in 3 lines of easy to understand code whose intention is obvious, when you can do the same thing with a clever and obscure one-line hack that will impress your colleagues?
      - SomeCallMeTim 14y ago
        FYI, in the comparison above, there were no clever one-line hacks that were completely unreadable. OO code just takes more lines.
- mistermann 14y ago
  Can you give an example of how a lack of consideration of extensibility might come back to bite one? And please not a contrived straw man example that is obvious to everyone reading, something that one might legitimately do in the real world for reasons of simplicity and expediency, that could turn out to be a genuinely painful experience when it becomes necessary to extend. (Obviously I don't expect an essay, but I'd appreciate if you could try to give us an idea in a reasonable amount of text.)
- SomeCallMeTim 14y ago
  The point is that there's a time and place for OOD, but small scripts that may or may not even be reusable isn't often one of them. But you can write as much code as you feel comfortable with, I won't stop you. I'm instead using the insights I learned above to write less code. And sometimes awkward things result, and I refactor. But a lot of the time the "awkward thing" is trying to get OO code to conform to a problem that doesn't benefit from it.

felipemnoa 14y ago

>>and then he showed me how he would have hacked it together in 1/10 the code by NOT trying to design it to be "extensible." Hacks like this do come back and bite you in the rear big time when latter on you want to extend it. Unless you are planning to trow it away or never modify it, it is a really bad idea.

Scaevolus 14y ago
Programs have inertia roughly proportional to their size. Extending a small program is almost always easier than a large program-- except for the special case where the large program was designed with the specific extension you're making in mind.
- astrodust 14y ago
  You sound like a person who's never had to debug a hairball of a Perl program that looks more line-noise than source code. You can do just as much damage by being too concise as being too verbose.
  - mistermann 14y ago
    > You can do just as much damage by being too concise as being too verbose. Very true in my experience. Why do something in 3 lines of easy to understand code whose intention is obvious, when you can do the same thing with a clever and obscure one-line hack that will impress your colleagues?
    - SomeCallMeTim 14y ago
      FYI, in the comparison above, there were no clever one-line hacks that were completely unreadable. OO code just takes more lines.
mistermann 14y ago
Can you give an example of how a lack of consideration of extensibility might come back to bite one? And please not a contrived straw man example that is obvious to everyone reading, something that one might legitimately do in the real world for reasons of simplicity and expediency, that could turn out to be a genuinely painful experience when it becomes necessary to extend. (Obviously I don't expect an essay, but I'd appreciate if you could try to give us an idea in a reasonable amount of text.)
SomeCallMeTim 14y ago
The point is that there's a time and place for OOD, but small scripts that may or may not even be reusable isn't often one of them. But you can write as much code as you feel comfortable with, I won't stop you. I'm instead using the insights I learned above to write less code. And sometimes awkward things result, and I refactor. But a lot of the time the "awkward thing" is trying to get OO code to conform to a problem that doesn't benefit from it.