Well, let's start with the obvious:
- Everything is an object.
- Whoever complains about OO probably just doesn't get it.
- Whoever has troubles with OO surely doesn't get it.
- OO is cool. The alternatives are all old-fashioned and obsolete. I get a chuckle from this one, because I found the perfect example of OO is from philosophy: Plato's Ideals are classes
- OOP makes "procedural" programming obsolete; C programmers have fallen behind and should upgrade. (Related: CeeIsNotThePinnacleOfProcedural)
- Everybody should be doing OO. We should have OO databases, OO operating systems, OO AI systems, OO safety-critical software, OO toilet paper, etc... There are some who still don't get it and persist in their bad old habits, writing obsolete software systems.
- "This is not OO." ( translated: "I'm sure it's something wrong with it")
- We have to find the right abstraction.
- SQL is low level. We need to abstract the storage access with the CRUD interface: (create 1 object)/(read 1 object)/(update 1 object)/(delete 1 object). Now we got our fancy RDB back to a COBOL file, see how low level and obsolete it is ?
- Every table in a relational database needs an OID column, so that we can "identify" our objects.
Please add or comment on the above list.
I hope nobody minds that I toned down some comments, trying to preserve the flavor without provoking people. Can we get definitions that both OO detractors and OO supporters agree on?
- Everything is an object. And Object Oriented Programming is just the latest hack to get us as close to programming with that insight as is currently possible. - GeorgeSxCowan
What is the alternative? When i interview non-OO people and i ask them how do you develop software, they really have no idea. Maybe OO isn't the saviour of the world, but it at least gives you a vocabulary. -- AnonymousDonor
http://geocities.com/tablizer/bizmod.htm - and the author would be happy to answer specifics. See also ProceduralMethodologies.
- I particularly like the design methodology espoused by Abelson and Sussman in SiCp. In short, what it comes down to is that you design a programming language in which your problem has a simple solution. For complicated problems, the approach can be layered on top of itself. The problem is that this requires the use of a base programming language that easily lends itself to such an approach, without requiring you to actually go and write a parser, interpreter/compiler &c. In practice, this requires higher-order functions and fully general macros, otherwise you go nuts. The main languages that support such things are the various Lisp dialects (Scheme, Common Lisp, Dylan, &c.).
At a high level, object-oriented programming is one of many interesting ways of designing programs. Here are some ways that work especially well for certain problems, though some (including OO) are much more broadly applicable than these examples:
- Finite state machines for asynchronous networking
- Constraint programming for incremental data validation
- Pattern-action matching for text processing (like AWK)
- Object-oriented programming for stateful objects with specialized behavior (e.g. GUIs)
- Processes, streams, and pipes for connectable text-manipulation programs
At a lower level, you can implement all of these designs in most languages. Because tastes differ so much, it would be asking for trouble to suggest which is best for what. Instead, let's just acknowledge some fundamental options, each of which some people really love, each of which has many subcategories:
- Classes, objects, and messages
- Procedures, pointers, and system calls
- Monads, structured types, and lazy evaluation
- Lists, macros, and recursion
We all have our own favorites, and most of us won't have time or occasion to learn all the others, but it doesn't hurt to acknowledge each of them. Smart people are writing good programs in each of these ways, and no doubt countless others, every day.
Note that I did NOT create this topic. --top
What's wrong about having to find the right abstraction? And how is that specific to OO?