4 ms·

One problem with OOP is that it's highly dependent on getting it right. If your design is correct, that's great, but otherwise you end up in increasingly hot w

by johnrob 15y ago

One problem with OOP is that it's highly dependent on getting it right. If your design is correct, that's great, but otherwise you end up in increasingly hot water. The problem I have with OOP for new projects is that it's hard to see the correct design until you have enough mileage.

hippich 15y ago
If you do not see correct design - you do not have enough information to start project anyway. Usually, this happens when modeled business process is a mess.
- johnrob 15y ago
  The trick is to use a prototyping-friendly paradigm, and mentally write it off as a research project.
davesims 15y ago
Bad design is usually inexperienced design. 99% of the design problems you'll encounter have been encountered before and are probably cataloged. If you have doubts, read up, and bring in other experienced coders. In fact, if you don't have doubts, you're probably in trouble and need to bring in other coders. If you're not using UML or at least sketching class relationships out in some visual form, you're likely to get it wrong. Good OOP is hard, and requires experience and at lot of reading and concentration to get right. And even then, it usually requires a good bit of collaboration to get right, even for very experienced architects. But once a good clear design has been identified, it's much faster to code and much much easier to maintain.
- cop359 15y ago
  " 99% of the design problems you'll encounter have been encountered before and are probably cataloged. " Bonus: It's already been done! http://en.wikipedia.org/wiki/Design_Patterns_(book) http://en.wikipedia.org/wiki/Design_Patterns_(book) I heard that when they wrote the book they basically mailed a whole bunch of people in the field to find out all the patterns people were using and they weren't able to find more then 23. After getting 23 every other pattern they would hear about would be just an iteration of one of the ones they had. Full Disclosure: I haven't actually read the book yet. But I'm planning to...
  - mattmanser 15y ago
    Have you read this recently? It impressed me 4 years ago, now I honestly think it's a relic of a bygone era. Language advances, different API design and dynamic programming and anonymous functions have got rid of a lot of the problems that you actually had to do these shitty patterns for. UML also sucks and is dead, again, not sure why anyone would bother with it. When is the last time you saw a UML article or GoF article on HN? Wake up, they're both dead concepts. I'm not even sure why patterns have died, they just have. Probably because people just program that way now anyway. Yes, they were useful, but they're not needed any more. People don't write code like that any more because they don't really have to.
    - davesims 15y ago
      Maybe it's that patterns are so common place we take for granted that someone had to name them. I guarantee you've used Proxy, Observer, Factory, Abstract Factory, Facade, Bridge or some approximation of one of these if you've coded more than 100 lines of Java in the last year. If I say "ActiveRecord" or "DataMapper" you probably think Ruby on Rails, not Chapter 10 of Patterns of Enterprise Application Architecture. If I say "Factory" you're probably not thinking Chapter 3 of GOF. When you think about node.js or EventMachine, do you think about the definition of the Reactor Pattern in POSA Volume 2? Patterns aren't dead. They won.
      - gambler 15y ago
        There is a fundamental problem with Deign Patterns: the knowledge and effort required to apply them appropriately vastly exceeds the knowledge necessary to effortlessly re-create them on the spot.
      - paganel 15y ago
        > If I say "Factory" you're probably not thinking Chapter 3 of GOF Honest question, what does this pattern accomplish? I'm asking this because I just saw a bunch of Factory-like classes in some PHP code I was trying to port to Python, and for the life of me I couldn't understand why the original programmer had made it so complicated and convoluted, when he could have done it all in 30 lines of code. And a second question for whoever might have the free time to answer it: does anybody actively use inheritance (or, why not, multiple inheritance) on a daily basis and in the same time do they feel like it helps them? (as in: does the size of their code base gets significantly smaller? does the code fits better in one's head? things like that).

by johnrob 15y ago

hippich 15y ago

If you do not see correct design - you do not have enough information to start project anyway. Usually, this happens when modeled business process is a mess.

johnrob 15y ago
The trick is to use a prototyping-friendly paradigm, and mentally write it off as a research project.

davesims 15y ago

Bad design is usually inexperienced design. 99% of the design problems you'll encounter have been encountered before and are probably cataloged. If you have doubts, read up, and bring in other experienced coders. In fact, if you don't have doubts, you're probably in trouble and need to bring in other coders. If you're not using UML or at least sketching class relationships out in some visual form, you're likely to get it wrong. Good OOP is hard, and requires experience and at lot of reading and concentration to get right. And even then, it usually requires a good bit of collaboration to get right, even for very experienced architects. But once a good clear design has been identified, it's much faster to code and much much easier to maintain.

cop359 15y ago
" 99% of the design problems you'll encounter have been encountered before and are probably cataloged. " Bonus: It's already been done! http://en.wikipedia.org/wiki/Design_Patterns_(book) http://en.wikipedia.org/wiki/Design_Patterns_(book) I heard that when they wrote the book they basically mailed a whole bunch of people in the field to find out all the patterns people were using and they weren't able to find more then 23. After getting 23 every other pattern they would hear about would be just an iteration of one of the ones they had. Full Disclosure: I haven't actually read the book yet. But I'm planning to...
- mattmanser 15y ago
  Have you read this recently? It impressed me 4 years ago, now I honestly think it's a relic of a bygone era. Language advances, different API design and dynamic programming and anonymous functions have got rid of a lot of the problems that you actually had to do these shitty patterns for. UML also sucks and is dead, again, not sure why anyone would bother with it. When is the last time you saw a UML article or GoF article on HN? Wake up, they're both dead concepts. I'm not even sure why patterns have died, they just have. Probably because people just program that way now anyway. Yes, they were useful, but they're not needed any more. People don't write code like that any more because they don't really have to.
  - davesims 15y ago
    Maybe it's that patterns are so common place we take for granted that someone had to name them. I guarantee you've used Proxy, Observer, Factory, Abstract Factory, Facade, Bridge or some approximation of one of these if you've coded more than 100 lines of Java in the last year. If I say "ActiveRecord" or "DataMapper" you probably think Ruby on Rails, not Chapter 10 of Patterns of Enterprise Application Architecture. If I say "Factory" you're probably not thinking Chapter 3 of GOF. When you think about node.js or EventMachine, do you think about the definition of the Reactor Pattern in POSA Volume 2? Patterns aren't dead. They won.
    - gambler 15y ago
      There is a fundamental problem with Deign Patterns: the knowledge and effort required to apply them appropriately vastly exceeds the knowledge necessary to effortlessly re-create them on the spot.
    - paganel 15y ago
      > If I say "Factory" you're probably not thinking Chapter 3 of GOF Honest question, what does this pattern accomplish? I'm asking this because I just saw a bunch of Factory-like classes in some PHP code I was trying to port to Python, and for the life of me I couldn't understand why the original programmer had made it so complicated and convoluted, when he could have done it all in 30 lines of code. And a second question for whoever might have the free time to answer it: does anybody actively use inheritance (or, why not, multiple inheritance) on a daily basis and in the same time do they feel like it helps them? (as in: does the size of their code base gets significantly smaller? does the code fits better in one's head? things like that).