Name: Anonymous 2012-11-14 7:22
For my first 20 years in this business, I created non-OO solutions because... well... the OO stuff wasn't mainstream enough for me to get at it.
For the last 10 years, I've been creating OO solutions because it's easier.
Programming is hard. It's a knowledge capture exercise. You're encoding knowledge in a programming language. The presence of OO languages, non-OO languages, functional languages, procedural languages, declarative languages says that no single language is ideal across all problem domains.
Sometimes you find yourself doing something complex in a not-so-OOP language and it's hard. Perhaps because non-OO languages actually are harder to work with. OO is just common sense encapsulated.
If you read enough non-OO code, you can learn enough non-OO design patterns that will allow you to work around the limitations of non-OO languages. Most good non-OO designers tend to use a lot of OO features but they're forced implement them in a non-OO language. And some of them gripe that they're not doing OO. Actually, they are, they just aren't using an OO language to implement their OO design.
Folks gripe about OO. Here's the standard litany.
1. It didn't/doesn't deliver on the "promise". Often they cite reuse as the promise of OO. The issue is that "reuse" isn't clearly-enough defined. Inheritance is the primary method of reuse in OO programming. Write it once and all subclasses reuse it. Other reuse may or may not happen and OO has little to do with that.
2. They have an example of egregiously bad OO design. Yep. And there are egregiously bad non-OO designs, too. Bummer on the "some people can't code" thing. I'm not sure I'd indict the approach because of someone abusing it.
3. They cite historical precedent: "Lots of good code was once written without OO". Yep. Lots of good code was written prior to compiled languages. Indeed, lots of good code was toggled in on the front panels of computers that didn't boot from disk drives. And, lots of good mathematical procedures were done with slide rules. And lots of good stuff was done with paper and pencil.
4. They find flaws in the single-inheritance model of Java. Yep. The real world seems to be multidimensional. Which means we either need multiple inheritance, or we need slightly smarter design patterns (like Strategy or Composite) to cope with the complexity of the real world.
5. They find examples of OO practice in a non-OO context and say "see, OO didn't help here." For example, the C libraries often encapsulate opaque data structures behind a well-designed set of method functions, very much like C++, but without the formalisms. This isn't an indictment of OO -- indeed, the encapsulation and library structure is OO, it just happens to be done "the hard way" without inheritance or language support. That doesn't detract from OO, it only says that there are multiple ways to implement an OO design, including non-OO programming languages.
6. They deprecate OO languages as syntactic sugar. This is point 2 -- you can find shoddy OO design. You also find shoddy non-OO design. Any tool can be abused. Abuse isn't inherent in OO.
Some folks claim OOP is all fluff without substance. Then, they design a clever library of related functions that encapsulate a data structure and use function pointers to allow someone else to extend the library by adding new features. OO done the hard way, gotta love folks who like to make a hard job harder.
For the last 10 years, I've been creating OO solutions because it's easier.
Programming is hard. It's a knowledge capture exercise. You're encoding knowledge in a programming language. The presence of OO languages, non-OO languages, functional languages, procedural languages, declarative languages says that no single language is ideal across all problem domains.
Sometimes you find yourself doing something complex in a not-so-OOP language and it's hard. Perhaps because non-OO languages actually are harder to work with. OO is just common sense encapsulated.
If you read enough non-OO code, you can learn enough non-OO design patterns that will allow you to work around the limitations of non-OO languages. Most good non-OO designers tend to use a lot of OO features but they're forced implement them in a non-OO language. And some of them gripe that they're not doing OO. Actually, they are, they just aren't using an OO language to implement their OO design.
Folks gripe about OO. Here's the standard litany.
1. It didn't/doesn't deliver on the "promise". Often they cite reuse as the promise of OO. The issue is that "reuse" isn't clearly-enough defined. Inheritance is the primary method of reuse in OO programming. Write it once and all subclasses reuse it. Other reuse may or may not happen and OO has little to do with that.
2. They have an example of egregiously bad OO design. Yep. And there are egregiously bad non-OO designs, too. Bummer on the "some people can't code" thing. I'm not sure I'd indict the approach because of someone abusing it.
3. They cite historical precedent: "Lots of good code was once written without OO". Yep. Lots of good code was written prior to compiled languages. Indeed, lots of good code was toggled in on the front panels of computers that didn't boot from disk drives. And, lots of good mathematical procedures were done with slide rules. And lots of good stuff was done with paper and pencil.
4. They find flaws in the single-inheritance model of Java. Yep. The real world seems to be multidimensional. Which means we either need multiple inheritance, or we need slightly smarter design patterns (like Strategy or Composite) to cope with the complexity of the real world.
5. They find examples of OO practice in a non-OO context and say "see, OO didn't help here." For example, the C libraries often encapsulate opaque data structures behind a well-designed set of method functions, very much like C++, but without the formalisms. This isn't an indictment of OO -- indeed, the encapsulation and library structure is OO, it just happens to be done "the hard way" without inheritance or language support. That doesn't detract from OO, it only says that there are multiple ways to implement an OO design, including non-OO programming languages.
6. They deprecate OO languages as syntactic sugar. This is point 2 -- you can find shoddy OO design. You also find shoddy non-OO design. Any tool can be abused. Abuse isn't inherent in OO.
Some folks claim OOP is all fluff without substance. Then, they design a clever library of related functions that encapsulate a data structure and use function pointers to allow someone else to extend the library by adding new features. OO done the hard way, gotta love folks who like to make a hard job harder.