Oop Arguments Debates And Discussion
Oop Arguments Debates And Discussion[EditHint: This is TooBigToEdit. Somebody dumped the pro's and con's replies into a single mega-topic. It needs to be split up again, or somehow re-factored into smaller units. See OopDebateMetaDiscussion about potential organization of OO discussions.]
moved from ArgumentsAgainstOop
Debates and Discussion
[needs some cleaning and consolidation]
The primary complaint seems to be that OO is not relational. That's as valid as saying that OO design is not structured design. The reality is that the code inside an object is structured (or should be). Similarly, there is nothing standing in the way of the data in an OO design being managed in a relational database. The problems show up when you try to make the object model and the data model look alike. They shouldn't. --MarcThibault
OO tends to "hard-wire" relationships into the application code structure. If these relationships continue to reflect the world being modeled over time, then there is no penalty, and maybe even some performance and integration benefits. However, if the relationships change in importance or different users need vastly different perspectives, then relational will shine because it was intentionally designed to create virtual ad-hoc views without having to physically re-arrange the content and representation.
Although this sounds great, but how is that different from using MVC and writing new Views of the Model as needed? Furthermore, many OO patterns are precisely FOR de-coupling relationship, such as the MVC pattern, the Visitor pattern, and the Strategy pattern, etc. Base on what do you claim that "OO tends to hard-wire relationships..."?
Can you tell me a programming style that does not tend to "hard-wire relationships into the code structure?" Part of programming is determining where you need flexibility and where you don't. This decision does not appear to be unique to Object Oriented Programming.
In database-centric styles, the NounModel is handled by the database, not in the application code. A lot of features and services that a database can handle is simply not part of the application code or greatly reduced. Things like the Visitor Pattern become mostly a query against a table or two. The application uses the result without any further worry about the structure of the source tables. It is a separation of Church and State that I find simplifies analysis and structure. One can code tasks with little or no concern about where they got their input from. OO Visitor is a fricken mess. It results in code that is shaped like a particular data structure, which I don't want. I want to abstract out the data structure issues from what is being done with the information. The shape of the source data structure is an "input detail" that I like to abstract away (or make minor), not live inside of.
Further, in relational thinking, the data structure for a particular need is relative. The ideal structure for one use is different from that needed for another use. Relational allows one to create "virtual structures" or (result) views. If you can have virtual structures that change to fit your needs, then why have hard-wired structures like Visitor?
IMO, this is just playing word games. A DB view IS a "hard-wired" structure itself, it just lives inside the DB instead of inside some C++/Java code.
Yes, but the application programmer didn't have to make it from scratch. The application developer does not have to care if programmers at Oracle or MySQL had to bust their butts to make the magic of relational work. It ain't their concern.
When your need changes, you still have to make a change to your system, whether it is creating a new visitor class, a new MVC view class, or a new DB view, it is still a change and you still have to test it. Perhaps you can show how creating a DB view is less error prone than creating a new visitor class.
{The TOP approach allows multiple simultaneous viewpoints of the same structure. You don't build new structures or new indexes to get a different view for a particular usage.}
I don't know about error prone, but it is less disruptive to the larger-scale code structure. In procedural/relational, you don't change your code structure to get a different view since the code is shaped like tasks instead of data structures.
Please explain what do you mean by "code structure", and why is it bad to change it. What "code structure" am I changing when I add a new MVC View? But that still doesn't explain why it is better to create a new DB view than to create a new OO class.
Also, please elaborate how Visitor results in "code that is shaped like a particular data structure", because it seems one can equally make a claim that "TOP results in data structures that is shaped like code, which one doesn't want".
TOP code tends to look like:
rs = query("select * from foo where....")
while getNext(rs) { // for each record in result set
do_something_with(rs) ...
}
Changing the query statement does not change the code structure in most cases. You don't shift large blocks around. Procedural/Relational generally groups code by tasks, not data structures nor nouns nor entities. When you look at P/R code, you know that you are looking at mostly tasks and just tasks. Changes in those other things listed thus don't have large-scale structural impact on the code. P/R is generally an extension of the input-process-output mentality of the first computers. The improvement is mostly with query languages to pre-process the input in a more concise and powerful way so that the application does not have to. P/R makes better use of the power of relational, OO does not IMO, tying the shape/structure of the code too closely to the desired data structures.
OK, but how would do_something_with(rs) looks like when your view changes?
The view should generally only change if there is a "business reason". IOW, a new feature or factor or something.
ANYTHING in a working system, including the creation of a (e.g.) MVC View, should generally only change for business reason, so we now reach the conclusion that TOP just simply "hard-wire" the relations in the DB view instead of in C++/Java code compared to OOP?
What you are doing is simply moving the complexity from the code to the query. It is like saying that if we use an interpreted language, we can always write code in the form
do_this(...<interpreted code retrieved from configuration file>...) do_that(...<interpreted code retrieved from other configuration file>...) do_that_too(...<interpreted code retrieved from yet another configuration file>...)then we can change anything in the program "without changing code structure", even at runtime! Is this what you mean by "code structure"?
The larger-level code units or "blocks".
So the above example with interpreted language accomplishes the desired effect of changing anything in the program "without change code structure". Agreed?
And, I never find the need to "shift large blocks around" when I add MVC Views to my system, is there any example of where OOP leads to "shifting large blocks around"?
We would probably have to explore some specific examples. How would you code up the (hypothetical) modem example at http://geocities.com/tablizer/prpats.htm#dispatch?
Great, finally some concrete example. Assuming we agree that there are better ways to do multiple dispatch than any standard OOP methods, is that really an argument against OOP, or rather just simple common sense to pick the right tool for the job? I can simply encapsulate the whole DB operation for multiple dispatch within an object, OOP doesn't prevent me from using the right tool. OTOH, if there are problems best solved using OOP approaches, can TOP accommodate its use? If yes, then TOP and OOP simple compliments each other, and this whole exchange is not about "against OOP", but rather what compliments OOP.
See MixingParadigms
BTW, OO Visitor has been called the "whipping boy of patterns" even by some OO enthusiasts. Why you would pick that pattern as an example of OO being "good", I don't know.
Well, you picked Visitor, I didn't. You claimed that Visitor results in "code that is shaped like a particular data structure", which I have yet to see an explanation of why it does that, especially since the point of Visitor is to decouple an action from the collection type (i.e. the data structure), I would like to see what kind of particular data structure will Visitor's code mimic. If Visitor is already a prime example of OOP problems, go ahead and shoot it full of holes it so deserved.
It is unnecessarily complex.
So it didn't really result in "code that is shaped like a particular data structure", but is simply too complex.
It is complex mostly because it is shaped by a limited data structure: the dictionary (ObjectsAreDictionaries). Dictionaries don't handle multi-dispatch well.
But is that due to language constraint in Java/C++ or really a short coming of OOP? I heard that Visitor in SmallTalk is really much cleaner, perhaps other SmallTalk users can comment.
But is it the OO-ness of Smalltak that makes it smoother than stiff languages, or its meta ability? I think we'd need to see a specific example.
{Somebody snipped text that CalculatedRelations was referring to? I remember something here.}
Wouldn't the whole argument for TOP better if it starts out from "I have done lengthly and deep research on OOP and concluded that TOP would be better because ....<insert common weakness and problems of OO programs and how TOP solves them>"? How far would OOP gone if its champions start their pitch by stating how they cannot "get" structured/procedural programming and OOP suits them more?
It is often hard to tell if the problem is internal or external. They would not have pursued OO if there was not something that bothered them about what they were using. I agree that procedural/relational may not be optimized for physical and nature modeling. Thus, their decision was understandable for their niche.
None of the above are arguments against OOP. They all seem to boil down to some people don't get OO. The only thing that comes close is the section about OO hard-wiring relationships which has been refactored.
As a non-fan of OO, I don't claim to have any good objective arguments against it. I believe that BenefitsAreSubjective, but too many have PersonalChoiceElevatedToMoralImperative. Thus, I have no objective evidence against it other than to say that there is no evidence for it, or that it has not been shown to be objectively better than alternatives. See TableOrientedProgramming for a discussion on some reasoning behind *subjective* preferences other than OO. Perhaps this discussion should be changed too IsOoOverHyped?. IOW, its promotion has exceeded its objective benefits (few or none). Shouldn't the benefits of paradigms be considered equal, unknown, or subjective until shown otherwise?
About the best I can do on the objective front is to say that OO objects and classes are based primarily on dictionaries, and dictionaries are limited to one result row and one result column. These limitations limit the flexibility (see TableOrientedProgramming) compared to something that can return multiple match rows and multiple columns. In other words, the key structure of OO is objectively limited to returning 1 row and 1 column. One can perhaps argue that limiting the building block complexity to just dictionaries (1/1) allows certain economies of scale, but I have not seen such.
What about MultiMaps??
Do you by chance mean MultipleDispatch or DoubleDispatch? A question was raised in TableOrientedProgramming about them.
Nope. I think I've misunderstood what you meant by "OO objects and classes are based primarily on dictionaries, and dictionaries are limited to one result row and one result column." When you say "dictionary" do you mean hashmap? In what sense do you mean that objects and classes are based on dictionaries.
As I struggle to express higher-level concepts of more and more complex designs succinctly in code, I find that the most disturbing thing about the OO paradigm is the asymmetry of its model of polymorphism, and a resulting too-tight coupling of functions and data. By 'asymmetry', I am referring to the fact that type-based selection of algorithms is based only on the 'zeroth' argument of a method invocation, i.e. on the object whose method is being invoked. Semantically, this object is really just another argument to a function, but has a privileged role in the selection of an implementation of a method. This becomes more of a burden as you work on larger systems where different objects interact with each other in unique ways. In C++ we try to address these problems with things like the VisitorPattern and DoubleDispatch. AspectOrientedProgramming also tries to address the latter concern, coupling. These solutions feel awkward, at least when applied to C++. Templates with specialization can also provide some relief, but at a high cost in coupling and build times in current systems.
I think that multi-methods, which essentially provide a more symmetrical form of polymorphic algorithm selection, will eventually become part of mainstream languages. I would go so far as to say that the OO model should be stripped down so that 'objects' are demoted to data types, with encapsulated representation and a set of tightly-bound functionality for the generation and copying of values. Jettison member functions and replace them with multi-methods; provide good packaging tools (name spaces, modules) to organize and encapsulate with more succinct flexibility than objects alone can provide. The packaging constructs are needed for organizing large-scale programs, and seem to be missing from some otherwise promising languages I've looked at. With them, you could still encapsulate data definitions (classes) together with the most basic functions that operate on them (methods) within such packages, while still leaving the system much more open to elegant expansion.
To explain where I'm coming from: I have been a long-time proponent of object-oriented programming. Over the years, I've programmed extensively in PL/I, FORTRAN, LISP, PASCAL, Modula-2, and C. I moved to C++ as soon as I could, which for me was around 1994 for on-the-job programming. In recent years, all of my programming has been in C++, and much of it has been concerned with database work. Aside from LISP, I've also played around with other languages that support a more functional style of programming, like OZ [OzLanguage]. In the last few years, I've come to the opinion that OOP has been an important step in the evolution of programming paradigms, but it is not by any means the end of that journey. For the time being, I find that C++'s support for multiple paradigms and for low-level efficiency make it a very practical language for me to use on many projects.
A lot of my thinking in recent years has been influenced by studying the second edition of the TheThirdManifesto, reading between the lines of the model presented there, and comparing it to languages that I'm familiar with. I think mainstream programming languages could benefit from the kind of rigor that DateAndDarwen have applied here, although their sketch of Tutorial D (TutorialDee) does not present anything like a complete general-purpose programming language.
There are no doubt some languages, probably in the functional programming family, that approach what I describe here. If so, I'd love to get pointers to them.
-- DanMuller
Point to explore: Does OO assume there are "global abstractions"? Is a class interface such an assumption? (As opposed to AllAbstractionsLie.)
Many illustrations of OO's alleged power come from device-driver or device-driver-like examples. I find that these kinds of examples don't map well to custom business applications. If something is custom, then you are not going to write multiple implementations under the same interfaces. See also PolymorphismLimits.
OO seems to have problems handling non-orthogonality that functional does not. Developers like having "one proper view" of their code - and in OO that is often a class hierarchy or class interaction diagram. Unfortunately many details get left out by that approach. OO also has a problem handling non-oop functions. Say someone wants to override malloc to call their own function - that is near impossible to show in class diagrams properly. UML helps(or hurts) a little. . .
Discussion - Inheritance
The real world does not form and change in a hierarchical way in some domains. Trees may be mentally "catchy", but they are too artificial to bend well with change and new details.
I am not certain I understand this comment. What alternative to a hierarchy is being proposed for software architecture? Every model I have seen is based on hierarchy, OO has merely formalized the hierarchy rather than leaving it ad hoc. What would be a non-hierarchical way to represent code?
A network of nodes/modules/classes that doesn't use inheritance? But does this eliminate hierarchy? {see below}
Some of us criticize such as being a roll-your-own NetworkDatabase, which we feel lacks the organizational consistency of relational. Some point out that some "structures" may be too small or trivial to bother putting in a database. However, I have used NimbleDatabase systems that make creating and managing tables a snap. If it is really small, then most likely it is local and temporary, and thus the "protection" promised by encapsulation does not really apply. Maybe in a blue moon something might be widely used and small, but mixing paradigms for a few rare orphans is not worth it in my opinion. -- top
I am not sure I see the relationship between code organization and a database of any type. Could you expand upon this comment?
When I look at OO designs and API's, I see a lot of code-based structures that seem to mirroring or "being" a data structure. To me this is best done by a database of some kind. The "shape" of things is then an adhoc query rather than the shape of the code itself. A hierarchical classification of stuff is best kept as data so that we can also view it by other ways besides just a tree (or any other given shape). Viewpoints are relative, and our tools should reflect this. If you hard-code structures in your code, then you cannot easily get such viewpoints. Thus, code should not reflect non-trivial taxonomies or classification systems. The only structure that is perhaps better as code than as data is defining algorithms, at least on a smaller scale. See DataCentricThinking and CodeAvoidance.
But not all data can live in a database. And once again you're confusing the shape of the problem with the shape of the solution. Just because my house is shaped like a box doesn't mean my tools should be.
Most or even all data *does* live in a database: a hierarchical file database (which I have some complaints about). It is a matter of granularity.
No. Some data is born, lives and dies in RAM. Some data resides in files. The files may or may not be arranged in a hierarchy, but that says nothing about the structure of the data inside them. You're still missing the big objection. If it helps to structure code hierarchically, then we do so. If it doesn't, we don't. OOP doesn't force you to use inheritance, it merely provides it as a possibility. The shape of the data has as much to do with the shape of the code as the shape of my house has to do with the shape of my tools.
Inheritance was only an example.
[I am not certain I understand how code can "mirror" a data structure, except in cases where one can implement an operation as either an algorithm, or a table look up, or a combination of the two. I also do not see how the implementation of a particular method would be made more difficult through a hierarchy. Could you expand, because I feel I am missing the whole intent of your argument?]
I don't know if the implementation is the problem. The biggest problem is finding the method, groking it, and changing it. Hierarchies are an unnatural way to taxonomize most code beyond the implementation unit (function/method). Sure, if they were all simple little trees like those found in TextbookOo, then there would not be a problem. But if you have tangled trees in a BigSoupOfClasses, then managing it all can be rather difficult. -- top
There is a Jan2004 trade article saying MicroSoft is going away from OOP. Granted it is a bit attention grabbing, but still the increasing use of XML is not entirely pro OO. Any Comments?
Do you have a link? That aside, their use of XML tends to look like half baked OO object models most of the time. XML is sort of like OO for procedural programmers. :)
How so?
From what I've seen, they tend to make little hierarchical models of their data in xml format. Half the time it almost looks like a serialized object model. Then they pass it around and treat the nodes like objects, feeling good about having all their data easily available, essentially DataTransferObjects? in disguise. Most cases I've seen, would have been much better using objects rather than procedural code and xml. Problem is they still have to shuffle all that data around to find the methods that go with it.
"Easily available data" is an OO trait? Your definition of OO seems a bit unusual or perhaps a bit wider than average. How about a specific example.
No, you misread that, or I wasn't clear. Either way, I don't know how to be more clear, they treat XML nodes like domain objects, plain and simple.
You mean like?:
print(tagX.attributeY)Looks more like a dictionary array per tag to me. Then again, I am not much of a fan of XML (XmlSucks)
This is probably considered bad practice, but I'm doing a verbatim paste of what I wrote in ObjectOrientedProgramming because it seems to have great relevance here too:
My POV (so far:) is that OOP is wrongly named, and should have been called "Model Orientated Programming". The term "Object" is too restrictive, and gives the wrong focus when trying to understand what OOP is really all about:
An object is simply a concrete implementation of an abstract model that the programmer has in his or her mind. The methods of the object provide the ability to manipulate that model, thereby mapping that abstract model onto the implementation. Hence the "user programmer" manipulates that model (via the methods) and never has to worry about the implementation.
This idea was derived after I realized that an abstraction is simply a model (in your mind) which you then map onto something real (this provides interesting insight onto the nature of perception which isn't relevant here). As such, OOP provides a very good "implementation" of abstraction itself.
It is then clear why the ability to be able to associate 'internal' state with procedures creates the essence of OOP - without such state you cannot maintain a model (which by definition always has some state). You can of course explicitly provide a (shared) state to plain old procedures, thus creating a model, but it's a bit messy... In the case of a SingletonPattern object, such state does not need to be implemented using a block of memory (such as a Struct in C or Record in Pascal), but can instead be provided by global variables.
From such a definition it is clear that OOP's (or should that be MOP's? :) essential characteristics does not include inheritance. You could argue that it does include encapsulation & polymorphism, but I'll leave that up to the intellectual bean-counters out there (I'm more than happy with just stating that it is model orientated and so provides a good implementation of abstraction itself). -- ChrisHandley
This gets back to NobodyAgreesOnWhatOoIs because "modeling" is not a significant part of the definition/nature of OO according to many OO proponents. (The wide variations are also part of the "inconsistency" criticism raised above). Further, we need to distinguish between modeling the physical world and modeling one's mental view of the world. There are existing topics/debates on both of these. [links to be inserted.] My view is that the model-centric view has not been articulated clearly enough for detailed external comparison and analysis. Discussions tend to drift into the internals of the writers' heads rather than something we can objectively compare. -- top
Anyone trying to differentiate between "modeling the physical world" and "modeling one's mental view" is making a fundamental mistake; they are one and the same because our only perception of the world is through models! This is why the term "object" is so misleading - it implies a model of an abstract object, when it is in fact a generic model itself. -- ChrisHandley
You lost me here. -- unknown (top?)
I suppose that's not surprising, since it's so fundamentally against most people's world view. Dororthy Rowe has described what I said (and done so far better than what I could) in some of her books, and to go into any more detail here could get extremely off-topic. I could make a separate page to discuss it? BTW, she uses the term "structure (of meaning)" but this seems pretty equivalent to "model".
My usage of the term "model" is very broad, as it can quite easily mean a physical scale model (as is often used in science), a mathematical model, or simply a tenuous "mental model" in someone's head. I often like to think of the latter as being rather like a simple machine which a human can easily imagine/predict in his or her mind.
If you define abstraction as ignoring irrelevant details, then the model is the relevant details, and mapping is the process of associating the model to the thing being abstracted.
The implementation of an object gives the object the behaviour described by a simple model (be it an "infinite list" or "finite table" or "2D area" or whatever). Since the methods of an object are the only way of observing & interacting with an object, the methods are effectively mapping the model (in your mind) to the implementation of the object. I think I am repeating myself, so perhaps I ought to tidy this up, at least if I have managed to get across what I was trying to explain? -- ChrisHandley
Well, I tend to approach modeling more from a "declarative" perspective I guess. One collects attributes describing the nouns. Actions then act on these attributes as needed. I mentally tend to separate the attribute model from the behavior parts of the model to better grok the system. Perhaps this may not necessarily make the model more accurate (although in the real world the association between nouns and actions is usually not one-to-one and is fluid), but it does make it easier to grok IMO because one can apply the best attribute processing techniques (relational) to the attribute side and the best behavior processing techniques to the behavior side. DivideAndConquer. Some of you say that "OO is about behavior, not data", but it is about data as soon as you have relationships between classes/objects. Relationships are data, not behavior, and OO has no consistent rules for managing these "links". The "self handling noun" concept is nice, but it cannot apply easily to the links between the nouns. Trying to hide inter-object relationships behind behavior is not information hiding because you are not hiding the relationships. You can't really encapsulate relationships because more than one object is involved. The connection between them is naked in the code. If it was truly isolated (hidden away as an implementation detail), then you could get rid of the second object without affecting the first. OO provides no consistent guidance for managing relationships between objects/records/things. Relational does. -- top
An aside to what I said above:
(Single) inheritance is a cute way of organizing objects, so that you can efficiently share code & data with an incremental design strategy, but it is definitely not part of the basic requirements of OOP (MOP). You can imagine more complex (and much less efficient) sharing strategies (multiple inheritance being an unimaginative one). But (single) inheritance is a very easy to understand concept, which clearly doesn't conflict with using models for understanding, and indeed is commonly used in people's day-to-day understanding of the world, so that inheritance should be part of every OOP language even if it isn't actually fundamental. -- ChrisHandley
Also, I agree with you that trees are easy to understand as a concept. However, they fail to capture the structure and change patterns of the real world as I observe it, and thus degenerate into AddingEpicycles to handle real stuff over time. -- top
I would advocate the "use inheritance where inheritance will work". Inheritance is not a general programming solution, and all the OOP books saying so are doing OOP a great disservice. If you see OOP as MOP then inheritance is a nice bonus not a central feature. If inheritance causes problems, simply do not use it! -- ChrisHandley
I think that OOP provides a full (if basic) way of expressing an abstraction. So future advances in computer science will be in how to describe an abstraction (object) well in terms of other abstractions (objects); single inheritance is a good start, but it is certainly not the last word. Claims that inheritance is central to OOP are holding back such advances... -- ChrisHandley
How does one measure whether something is "more abstract" than another? See MeasuringAbstraction.
What has measuring "abstractedness" got to do with what I said? If you think I am claiming OOP is more abstract, then you are not quite right. What I am claiming that non-OOP languages are lacking some of the fundamental requirements of abstraction (specifically association of state with things that perform actions), which thus means attempts at abstractions in those language will never be flexible (or even good). So I am claiming that only OOP provides a way of fully implementing the process of abstraction. -- ChrisHandley
But if we are to change topic to MeasuringAbstraction, then my short answer would be that something is more abstract if it has less details. Of course, you can only compare the "abstractedness" of two things, if both things are abstracting the same thing - i.e. it is relative. And attempts to measure abstraction as an absolute value are meaningless. -- ChrisHandley
Are you suggesting that abstraction is not measurable? Or that amount of code (such as LOC) is a measurement of abstraction? An example would be helpful.
[Moved from ExtremeProgramming]
The real issue is that projects that use programming languages that provide native support for object-orientation and use class-based inheritance are doomed to fail because of their inherent reliance upon the proven false AristotelianClassicalModel?. In other words, no amount of mechanic monkey wrenching is going to fix a problem whose basis is rooted in the languages themselves. Class-based inheritance languages provide the wrong kind of abstractions for memory manipulation, electron shuffling and human ideas.
Since OO-language based projects do succeed, your assertion is FalseToFacts?.
Oh my, here's pity for the myopic. Perhaps an operational definition of 'doomed to fail' is in order or a contrary operational definition of 'success'. Simply, your notion of success is FalseToFacts?. Let's frame the concepts is simple terms.
No one can design and implement automobile brake systems or passenger airplanes like software systems expressed in programming languages that use class-based inheritance models. Is it acceptable for an engineer to explain to the family members of passengers of cars and planes that died travelling in vehicles that 'we didn't quite express the correct relationships between components (inheritance relationships) when we designed and implemented them, but with some revision (i.e., adding a new super-component) we'll get it right the next time."
Revising software because it didn't quite capture the essence of the problem might be your acceptable definition of success, but that notion is FalseToFacts? with respect to the essence of success, which is measure twice, cut once.
While your notion of success might provide employment for programmers and [un]knowledgeable consultants alike, it's expensive and unnecessary, unless of course, one uses programming languages with class-based inheritance models.
Some OO proponents say that "good" OO design does not use very much inheritance, or at least does not use deep hierarchies. They suggest combining multiple classes by co-referencing instead of inheriting. Such is still messy in my opinion, but it does not suffer LimitsOfHierarchies problems as much. -- top
While I'm going to try very hard not to use the 'T' word here - I find huge inconsistencies in what's written above. While the passage above seems to be in support of the original assertion that projects using OO languages are doomed because of the nature of OO, the justification is based on an implicit assertion that "successful" OO projects have all failed because they didn't work perfectly on the first run.
I'm curious about this topic in that I've been writing software for real world business systems since FORTRAN in the mid 70's and have been able to work with many of the different languages and concepts discussed. So far, I've found OO to be far and away the best paradigm for supporting the the full spectrum of concepts and organizational requirements of the types of problems I've come across.
OO IS NOT NECESSARILY many of the things that its detractors accuse it of being. OO in practice (and in theory, but the naysayers are selective in their j'accuse) allows one to take advantage of its features where applicable but does not impose them. With the exception that one must use classes in most OO languages.
The real promise of OO is that it helps one get to a correct design to a problem.
Well, how does one tell objectively that OO produces the "correct" answer and that all the others are false?
Why ask this question? I make no claim that there is only one correct answer.
Can you think of the bits of your problem as distinct "things"? If so, make them into classes, have their interactions become the methods and messages, and you're off to a good start.
Yes, I can, but I don't find it the most useful metaphore, partly because the relationship between verbs (actions) and nouns is not nearly as tight as OO often assumes or pretends. Plus, pure behavioral interfaces often needed in noun-centric grouping don't factor CollectionOrientedVerbs well I find. Joins and many-to-many relationships tend to be areas where they get ugly, for example.
top - metaphor? You need to get your head on straight about what OO is and is not.
If so, I am not alone. NobodyAgreesOnWhatOoIs.
OO is like all the other advances in programming languages in that it IS ONLY a way to help people in organizing and managing the inherent complexity in the systems they're faced with conceiving and creating. As such it's proven to do a better job than most other approaches. Yes, proven.
Well, I have heard that a jillion times from pro-OO-ers, but have never seen actual code that is clearly "better organized". You will need to come up with clearer descriptions and code examples in order to move skeptics, such as I.
top - a "jillion"? how many is that? and if your grammar reflects your programming - try "... move skeptics such as me."
Inheritance isn't suitable for your situation? Don't use it (maybe composition helps?); but don't complain that it's not suited for what it's not suited for.
Is OO the ultimate answer to all problems? No. Nothing is or will be.
Have a problem you need solved that OO doesn't help with? Good, it'll be plenty interesting.
At present I'm very interested in the developments in the Open Source world of Java projects, there's plenty of innovation going on incorporating all sorts of novel approaches to managing complexity within the world of objects. Maybe there's some life in the old girl yet. My particular dislike is for those who think that relational databases are the consummate programming medium, and who believe that the table metaphor is best suited as a foundation for programming concepts and languages. This attitude is ridiculous on its face, and should have been argued AGAINST long before it gained traction. The relational view of the world is about as far from the native human cognitive experience as anything out there.
Just what is the "human cognitive experience"? OO does NOT fit the way I think and does not seem to fit the way the real world changes over time either. If OO is all about fitting human psychology, then first you need to clarify what the universal psychology is and offer some validation. I won't dispute that OO might fit YOUR mind, but I am not you.
top - Human cognition is based in the identification of distinct objects in the world, with observable properties, behaviours, and interrelationships. The context within which something exists is relevant and meaningful. Degraded tables of similar things are devoid of behaviour and context.
That is false. Human cognition is based on a lot of different things, and different people have different cognition models. Example: http://www.grandin.com/inc/visual.thinking.html That article is very interesting. I'm also visually oriented, but to a far less developed degree. But it doesn't argue against my claim.
Using degraded tables to hold atomic data bits is useful for a couple of things, but completely useless for expressing relationships between elements, or of describing the behavioral characteristics - individual or collective - of the parts of a system. And, in the end, it's what the system can do that matters. Even when the can do is telling one what it knows.
I find the database can help simplify the "behavior" because on can reduce much of the problem to merely CollectionOrientedVerbs on the NounModel and attributes. It is like a player piano: if the notes are right, the piano engine plays them and the song writer does not have to worry as much about the mechanics of the piano machine. Related: IsDeclarativeLessExpressive.
top - Looking at CollectionOrientedVerbs I find nothing of value there. Is it your rhetorical reference to authority argumentative technique that you seem to accuse others of?
No, the point is to standardize and perhaps embed commonly-used collection-oriented idioms (via APIs or language itself) instead of reinvent them over and over again in different ways, which OO appears to do. OO offers no standardization.
Relational Databases serve two purposes: they keep data nice and snug, and they let you combine it in any combination you can dream up. However, the relational model REQUIRES YOU to know WHAT relationships between atoms are meaningful - it offers absolutely no help or guidance whatsoever.
Could you please clarify?
top - Given two tables, one an account table, the other a table containing transactions, IF there is a relationship between them that some of the transactions are associated to some of the accounts, that metainformation must be known outside the set of tables themselves. (And I thought the next paragraph was clear enough.)
Can you perhaps use pseudocode to demonstrate your point?
Unless you create other tables or views that represent the higher level information abstractions, which you then have to know about, unless.... It just gets tiring. And who really knows how to achieve 5th normal form, anyway.
Normalization is simply OnceAndOnlyOnce. Extreme normalization is often a bad thing. Let OnceAndOnlyOnce be your primary guide, not some dusty ol' DB book. OnceAndOnlyOnce should guide OO designs as well.
top - According to relational theory, the only reason relational databases is in any better than other database organizing principles is that, properly normalized, there can be guarantees of the absence of data anomalies. That's the whole point of their existence. Without that they have no advantage over other database types, and are manifestly inferior to many others in their lack of contextual information about the data relationships.
Referential integrity is only one of many selling points. Some of NimbleDatabase tools I have used in the past didn't even have RI, but still offered other benefits. And, one does not have to join on known or common keys/attributes if the task calls for it. That is not forced upon you by the relational model.
As a parting thought, network databases are much better things than relational dbs, but they got shuffled aside in the face of marketing hype and the "Predicate Calculus", and Oh! the irony of XML, a hierarchical self-describing data structuring mechanism, becoming the preeminent data transmission mechanism.
-- ChrisGerrard
Actually, your comments about relational databases reflect that you are at least as ignoramus on databases as top may be on other areas. The advantage of relational databases over the other databases is given by relational algebra or relational calculus which offer compositional mechanism with known algebraic properties for users to construct their queries based solely on logical properties of information, while it allows the DBMS engine to optimize the execution based on physical properties of data. So it's about EconomyOfExpression (elegance of notation), verifiability (it is easier to verify that a declarative query is correct than it is to verify the corresponding "walk the pointers" OO dog), and chiefly SeparationOfConcerns. Other databases and data models failed copiously with regards to these criteria, and it's no longer a matter of debate it is a matter of having minimal knowledge on the subject. Any wannabe who thinks to have something to say on the subject but is not aware of the historical background of hwo databases evolved and do not addresses the above fundamental issues related to databases, yet puts forward claims, only displays his ignorance.
Now go read a good book on databases, such as AnIntroductionToDatabases?, or FoundationsOfDatabases, and come back when you have something to say while minimally competent on the subject. -- CostinCozianu
Ouch. That's pretty harsh. I have studied a wee bit about databases, but am not aware of any literature about the superiority of the relational querying mechanism being superior to all other querying mechanisms, or in what dimensions the superiority exists. If there's anything out there I'd be happy to read it. And I'm not sure it's even relevant to bring the querying mechanism into the discussion, as, in my ignorant state, I'm tempted to think there are alternate (non-SQL) languages for interacting with relationally structured data. But what do I know? But I am very sure that SQL is not a very approachable tool for most people who simply want to get some data out of the database so they can see it. Although in the interest of disclosure I did work for quite a long time for a company that did very well as the vendor of a reporting language.
Costin's language is a touch harsh, but not incorrect in any way. Network databases do in fact have certain advantages in very special niches, but they were abandoned for general use for excellent reasons that are thoroughly covered in every intro to database text I've ever seen. Their disadvantages (and advantages, of course) were explained thoroughly even in the database texts that pre-dated the popularity of relational databases. Everything gets hyped, of course, but in this case relational won over network databases out of sheer technical merit. And yes, this is covered universal in intro texts.
It is furthermore true that no one has found a superior general replacement for relational databases. Various kinds of OO databases are superior in certain niches but not across the board. Similarly for various e.g. transparent persistence schemes.
None of that has anything to do with the merits and defects of SQL in particular. It won the day not because it was best (both Ingres and ChrisDate introduced superior languages), but for the usual: it's good enough, was supported by more vendors than alternatives, etc, but all that is pretty irrelevant to this discussion.
XML is extremely irrelevant to this discussion. Data transmission encodings have nothing whatsoever to do with anything else on this page, and to the extent XML is used for anything else, that's like using a wrench as a hammer, and discussion thereof should be too obvious to bother with.
Let's see: "Normalization is simply OnceAndOnlyOnce." Sorry, wrong again. That is true of a subset, absolutely not of the whole. "Extreme normalization is often a bad thing." True, although that's a pretty vague statement. The industry usually goes for roughly 3rd normal form, almost never for absolute normalization. "Let OnceAndOnlyOnce be your primary guide, not some dusty ol' DB book. OnceAndOnlyOnce should guide OO designs as well." Ok, but as Costin said, maybe you should dust off some new DB book.
And again: "top - According to relational theory, the only reason relational databases is in any better than other database organizing principles is that, properly normalized, there can be guarantees of the absence of data anomalies." Wrong again; that's one of their virtues -- "That's the whole point of their existence." Nope, absolute false. "and are manifestly inferior to many others in their lack of contextual information about the data relationships" In certain niches, yes. In general, false.
And all this is covered in basic texts. So I can sympathize with Costin's frustration and harsh language. -- DougMerritt
OOP seems fine for relatively simple interfaces to external services or tools. However, when it grows into a big data structure or a graph monstrosity, then it looses its appeal, in my opinion. My rule of thumb is that five base classes are the upper limit. There could be more sub-types without problems. Applications that use multiple independent groups of these five-max sets are fairly easy to follow. It may have a lot of such sets, but no set has more than the five base classes. When a set grows to more than five, it is either time to split them, or abandon OOP for that utility or framework. --AnonymousDonor
PageAnchor "replies"
Replies to opening list:
Inheritance
Let's say I have three different functions that do the same thing except in one spot. You can factor out the inside of a loop in a regular language, but in a functional language you can factor out the outside of a loop. Let's say I want to sum a list:
(define (sum lst)
(if (null? lst)
0
(+ (car lst) (sum (cdr lst)))))
(define (product lst)
(if (null? lst)
1
(* (car lst) (product (cdr lst)))))
Instead, you can do this:
(define (fold fn lst val)
(if (null? lst)
val
(fn (car lst) (fold (cdr lst)))))
Then you can do this:
(define (sum lst)
(fold + lst 0))
(define (product lst)
(fold + lst 1))
Folding is pretty cool, and seldom seen in OO, but it isn't hard. I think this would be done with a StrategyPattern. The strategy is a function object, with some "do it" method "A DoIt(B,A)", and the fold is another object (or static method). It's easy enough in a dynamically typed language or statically typed OO language with generics.
The Decline of Object Oriented Programming in the Enterprise by Allen Riddle - December 5, 2006
http://www.allenriddle.com/articles/ooInTheEnterprise
A claim that the current trends in OOP are getting OOP all wrong, that the current fads are really procedural in OO clothing, and that SmallTalk encourages the "right way".
LISP and SmallTalk are purpetually the "right way", and have been for decades, but most people keep ignoring them.
See ObjectOrientedProgramming and ObjectOrientedLanguage
Related: IsMicrosoftAgainstOo, BenefitsOfOo, DoubleDispatchExample, TableOrientedProgramming, ComparingParadigms, OoVsFunctional, ObjectOrientationIsDead, SetsAndPolymorphism, OoBusinessExamples
This page is partly factored, but still TooLargeToGrasp. Please RefactorMe.
Moved from WhyOopIsBetter. Top seems hellbent on leaving this page's bullet points without refute, while utterly violating the page's in support of OOP. Top didn't write the refutations below. -- NotTop
Top, this whole page exists precisely to voice your opposition to OOP. Stop defiling pages in support of OOP.
I am confused. Please clarify. I did not move this here. --top
Re: OO forces one to think too much about "persistence"
ArgumentsAgainstOop claims, 'OO forces one to think too much about "persistence".' To which I say: Say what? I've been in involved in two object-oriented projects in the last year, one in Javascript and one in Python. In the latter case, we were ripping out an SQL engine in favor of something actually suitable to the task. In neither case did I "worry about persistence." I needed to worry about race conditions, and protocol interpretation, and converting data formats, and keeping track of user chanegs, and flash wear, but never did I worry about persistence. Similarly, the closest I got to worrying about persistence when working on a text editor was when writing the code to implement Put.
Or, to not dance around the point -- are we really talking about object-oriented programming, or someone's problems with applying it in a particular context?
-- BillTrostWithout specific examples and scenarios, it's hard to evaluate your claims.
Without specific examples and scenarios, it's hard to evaluate your claims.
I meant your "ripping out an SQL engine" claim. Perhaps you just don't get SQL, not that it is inherently "bad" (although I'd like to fix some key SQL annoyances). Anyhow, a datapoint on "forces one to think about persistence" is the ORM (object-relational mapper) industry. There is no procedural-to-relational mapper industry. Why is this? Why does OO need fat bloated mappers that rival the complexity of a 1985 minicomputer OS but not other paradigms?
Oh, come on! Are people being deliberately obtuse? Javascript means web app, which means not very persistent, since the Javascript code vanishes when the user leaves the page. Javascript is object-oriented. Google maps is a Javascript application. How much can Google maps possible worry about persistence? It has nothing to persist! (There's your specific example. Go wild!)
For what little it's worth, we ripped out SQLite because we needed to make a schema change, and it was more humane to replace the underlying engine than to rewrite all the (rather poorly designed) tables and views.
-- BillTrost
Google Maps is not very representative example of the apps I see. But I will concede that different things need different things. Google maps is more or less "physical modeling", which is what OO was originally built for and does okay there because the physical world does not need "relative transformations" for the most part, at least if you are dealing with it as a physical model. (One if the things I like about relational is that it is one of the best "relative viewpoint transformation engines" that exists right now. I can't get OO to do that well.)
Back to persistence: My point was that IF and when persistence is needed, OO makes one freak out. When one uses an RDBMS, the DB is often both the "collection system" and the persistence mechanism all-in-one. Using one generally takes care of the other. That's not the case with OO because objects become your collection system and are not always easy to make auto-persistent because they tend to be behavioristic and navigational. It's harder to "save behavior" --top
EditText of this page
(last edited February 3, 2009)
or FindPage with title or text search