Problems With Existing Oop Evidence

Here's a list of common problems I find with evidence presented for OOP as found in the top OOP authors and various pro-OO websites. Note that not all OOP proponents make or hold these claims. They are merely commonly-reoccurring claim patterns I have encountered in my e-journeys.

• Not clear on what is being measured. Often there is what appears to be vague brochure talk. Example: "Encapsulation results in code that it's nicely packaged." How is "nice" measured? What is it being compared to?
  • Encapsulation is hardly unique to OOP. For 'nicely packaged' one would usually be measuring the cleanliness of interface, likely in terms of the number of exposed implementation details (e.g. global variables, types, procedures, etc.) that might change over time. One hardly needs to measure; by definition, you have encapsulation if and only if you are able to prevent coupling to these implementation details. Hiding implementation details is "nice" because if they are hidden you can (without risk of breaking dependent software) change them or swap them out for another implementation. No reason to demand empirical evidence where deductive logic will suffice.
    • The applicability to the real-world may be the part that requires empirical analysis.
    • If you consider the difficulty of replacing mixed (non-encapsulated) code - e.g. replacing 30 random functions out of a project with a hundred files, some of them from different packages - vs. doing the same with encapsulated code (replacing 30 functions whose implementations are all in one file), it is by deductive logic clear that the encapsulated code requires only touching one file whereas the non-encapsulated code may involve touching as many as thirty files. I have no reason to believe the logic will fail me here. But feel free to give it some rigorous testing if you wish.

    • Also, proponents of dynamic OOP languages may have a different emphasis on what "encapsulation" is about.
    • I do not see how that is relevant unless your goal is to raise a LaynesLaw debate. If one is talking about "Encapsulation results in code that is nicely packaged", one is necessarily talking about encapsulation in the context of the packaging of code.

  • A better place to demand evidence would be the implicit assertion that OOP supports encapsulation more readily or in more situations than <alternative paradigm of choice>. As an OO guru, I suspect that the answer after investigation would be: OOP isn't better at encapsulation for static configurations (where plain old interface-based static modularity will suffice), but supports encapsulation and composition for dynamic or data-driven configurations (ConfigurableModularity) far more readily than most other paradigms (strongly excepting DataflowProgramming).
  • But these are the kinds of things that most GoldenHammers claim. Some kind of demonstration would typically be requested.
  • DependencyInjection frameworks, UnitTesting with MockObjects, etc. provide such demonstrations.

• Examples appear tilted toward SystemsSoftware, not the business domain. I don't dispute that OO may work well in systems software, but what about us millions who don't work in the domain of systems software? Is OO not meant for us? You should have told us that before we bought your book.
  • Related discussions in or moved to OopNotForDomainModeling and OopBizDomainGap.

• Toy examples used to justify OOP. True, many of them are just training examples, but there is rarely a disclaimer about that and they often read as if the toy example is sufficient proof of OOP being better.
  • Reading individual examples as though they are intended to individually be sufficient proofs of OOP's superiority is an error analogous to that of the blind men describing an elephant. Reading training examples as though they are intended to be proofs of anything is an error analogous to analyzing a training-manual for an abacus as though it were intended to be a proof that the abacus is superior to the calculator. The problem is with the reader, TopMind, not with the examples.
  • As they are written, newbies can easily mistake them for real evidence, and apparently do based on their stances. It is bad form, regardless of my existence.
  • I'll grant that point, though I don't believe any other programming methodologies - including your examples for TableOrientedProgramming - do any better with regards to disclaimers, so I sense a great deal of hypocrisy in your argument.

• Examples assume unmeasured or unjustified changes patterns. For example, the "toy" shapes examples assume that new shapes are more likely to be added than new methods. If this assumption is wrong, then the "code change visit points" counts actually favor the procedural version. (It's impossible to test frequency with toy examples anyhow, because in practice they don't exist in the field.)
  • While the ExpressionProblem is well understood, you seem to be assuming that adding new methods to objects is the OOP equivalent to adding new procedures in procedural. It is not. Adding new FunctorObjects is equivalent to adding new procedures. Such FunctorObjects can be created quite easily without experiencing the ExpressionProblem.
  • I'm not sure if "equivalence" is an issue. The typical textbook example uses case statements on "shape type". I agree there are many ways to do it in both paradigms, but I'm considering how typical examples present it.
  • And yet you can find common examples supporting the more process-oriented patterns, especially when integrating with common frameworks (WCF, COM, DDS). You'll find common examples of FunctorObjects in STL's 'for_each' and 'sort' algorithms, and 'execution in a kingdom of nouns': http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html . Java has its 'Runnable' interface for a reason. I don't know all the reasons students are taught examples like animals, vehicles, and shapes first - it isn't an approach to my approval - but there is plenty of evidence to indicate that students are fully expected to advance in the subject to utilize FunctorObjects for the purpose of adding new 'procedures'. As a consequence, I must still reject that your comparison of approaches is a reasonable one.

• Language-specific strawman - Often times a limited or poor procedural language is used to represent "procedural". The most common examples are the "break" statement and lack of named parameters. See CeeIsNotThePinnacleOfProcedural. A bad language does not make a bad paradigm.
  • Don't forget that this applies also to OOP. For example, Java is often used to represent "OOP".

• Fail to address realistic "granularity of variation". In practice when new features appear, the difference between things is usually smaller than the method's granularity. Thus, one needs to override 1/3 of a method, for example. The XP crowd simply shouts "just refactor the granularity to be smaller". But this is not change-friendly code. Thus, either withdraw the "easier to change" claim, or justify having ever smaller and smaller methods, plus the effort to shrink them. An IF statement around the area of difference appears far simpler than re-shuffling all the related methods. Something smells here.
  • I have rarely seen a feature that can be added by overriding 1/3 of one method, excepting if that method is GodCode (like the evaluation function for a language). Are your pet variation-patterns somehow more realistic? What sort of features are you imagining?
  • I suspect also that you assume some sort of context (for definition see ExplicitManagementOfImplicitContext) to support something like a FeatureBuffetModel in procedural. That same pattern can be used easily enough in OOP (e.g. via ContextObject). Language support for the class of CrossCuttingConcerns addressed by context is pretty much orthogonal to both OOP and Procedural.
  • Discussion moved to OopAndVariationManagement.

• Reinvent databases. As the needs grow over time, often a lot of "pseudo-query" methods start to appear. It seems more logical to me to use a database instead rather than reinvent one the slow way. Databases give entities lots of features out-of-the-box. But I see OOP reinventing them the hard way. I don't see valid justification for this. Reinventing what a database does is not "reuse". "I don't like SQL" is not a good-enough reason. Sometimes SQL is the simplest (and most efficient) path. In practice, RDBMS are a common business tool, OODMBS have mostly failed, and thus OOP must find a way to get along with RDMBS for good or bad. Too many OO books either pretend like RDBMS don't exist, or include tons of repetitious code to "hide" them. This is not efficiency and simplicity.
  • Reinvention of databases implies OO is being used for domain objects, which many OO gurus would not recommend doing so any more than you would. But I do agree that this appears to be a problem in practice, indicating some failures in the education of OOP. OTOH, I've also seen reinvention of databases in procedural, functional, and just about every other paradigm. In accordance with DesignPatternsAreMissingLanguageFeatures and MissingFeatureSmell, I suspect that FirstClass support for a database and query language abstraction should really be part of programming languages in general.
  • Possibly related: OopNotForDomainModeling

• Pop psychology - If OO better models how people think, then you need to cite some studies which directly back your claims. I see instead made-up pop-psychology. And you need to show that it applies to every developer, not just some.
  • Agreed. This has always been a ridiculous claim, though I'll admit that I've never seen anyone but TopMind say that people have claimed "OO better models how people think". I suspect he could find an example of it being said, but it's worth noting that this was not an argument made by the initial developers of OOP (Nygaard, Kay, etc.). It is more likely part of the OOP market buzz that was introduced fifteen years later.
  • It's been a top vote getter in our own wiki poll: OoBestFeaturePoll. Hopefully this means there are plenty of pro-head-model people to bounce this issue off of here. -t
  • Touché. Though I'm curious as to whether they believe it models the way they think about the domain, or whether they believe it models how they think about the program. UML, for example, is a common OOD language that makes it quite clear that one is modeling such things as: "actors, business processes and system's components, and activities as well as concrete things such as programming language statements, database schemas, and reusable software components." (http://en.wikipedia.org/wiki/Unified_Modeling_Language#Overview) - i.e. it models the program and its environment as a system of interacting components, including modeling inputs and outputs associated with the domain, but does not model the domain.

• Real-World Matching - It is often claimed that OOP "better matches the real world". How exactly this is being measured is not clear. Further, sometimes the real-world is limiting. Modeling a library card catalog is a poor choice when we now have multi-indexing in cyberland.

• Programmer as data-entry clerk - Many examples seems to assume that the programmer will be maintaining product classifications in code, such as "types" of coffee. Unless OOP is a programmer jobs program, the end user is supposed to be the one who adds new products and product classifications for the most part. (OopNotForDomainModeling may apply here also.)

• More to come

--top

[EditHint: Merge with ArgumentsAgainstOop. No need for yet another topic repeating your arguments, is there?]

• I agree there is some overlap, but I meant this topic to discuss HOW and WHAT evidence is actually presented. Related to "oop topic cleanup": OopDebateMetaDiscussion.
• In that case, why are most of your complaints about the OOP claims rather than pointing at actual presentations of evidence and complaining instead about the form of presentation? Your stated purpose seems inconsistent with the points you raised above.
• Because if I don't know exactly why it's allegedly good, I cannot adequately address it. I can only address specific claims made.
• So you claim, but you failed to even once address a specific claim made. I see no references, no page numbers, no indications of specific claims, and thus cannot observe the evidence surrounding said specific claims. Instead, you reiterated in your own words what you believe to be claims about OOP, failed to reiterate any of the evidence presented around these claims, then attacked your own words. The 'StrawMan argument fallacy' comes to mind.
• Sigh. If you wanted page references, just ask for them. Don't accuse me of dastardly deeds as a first resort. That just triggers flame wars. It is reasonable to not provide citations in informal discussions unless it is challenged. Which specifically do you question the commonality of?
• I have no responsibility to judge your arguments by anything more than what you presented. It is reasonable to expect you to present or outline at least enough evidence to support the point you are trying to make without being challenged. You didn't even do that much. You say you were attacking "HOW" evidence is presented, but you never even so much as outlined how evidence was presented in any of the above points. How about you provide references for each of them?
• I disagree. If nobody disputes a point, there's no need to provide evidence. This is not an academic paper. And let's see if others agree by giving it time. Be patient, dude. And, if your "rules" for informal discussions differ than my rules, that still does not make me evil or bad. -t
• All your points are disputed. That's pretty much true by default when you're arguing against established evidence and arguments. Ah, well, your StrawMan points will stand on their own demerits.
• Established evidence???? Surely you jest. Besides, that's ArgumentFromAuthority even if it did exist.
• "Established" does not imply "valid", but it also doesn't mean "invalid", and I seriously doubt your sanity if you think all the evidence to be ArgumentFromAuthority. Regardless, unless you are the sort of sophist who intentionally would "counter" points that have never been raised and aren't likely to be raised, the only rational position is that your argument is already disputed by what other people consider to be established evidence.
• You are acting like a stuffy librarian. Suppose I claimed it was anecdotal evidence. This wiki does not forbid anecdotal evidence. Sure, it's weak evidence, per EvidenceTotemPole, but it's still evidence. If you delete my anecdotal evidence, then to be fair you should delete ALL anecdotal evidence on this wiki. Otherwise, it looks like you are merely picking on me because you hate me.
• [To be considered "anecdotal evidence", you have to present (a) anecdotes, and (b) evidence. Simply stating that your opinion is a result of what you "have encountered in [your] e-journeys" counts as neither.]
• Please clarify. They are anecdotes about common example or example patterns I have encountered. By the way, if you want specific page-numbered examples, see: http://www.geocities.com/tablizer/meyer1.htm
• [An "anecdote" is a specific story or incident, usually intended to make an obvious point, i.e., serve as evidence. To make your accounts anecdotal, they would generally be something like: "On page x, Meyer writes blah blah blah. Once, when I was working on a blah blah, we were dealing with the following problems: Blah, blah, and blah. So, we decided to use Meyer's example to guide us. Unfortunately, we discovered that when we did his blah, we couldn't do blah blah. And when we tried his blah blah, the blah became much more complicated. Worst of all, we discovered that blah blah blah occurred and we couldn't find a way around it. The problem is that toy examples are used to justify OOP. True, many of them are just training examples, but there is rarely a disclaimer about that and they often read as if the toy example is sufficient proof of OOP being better. Had we understood that the example on page x was just a toy, maybe we wouldn't have blah, blah blah."]
• I'd classify that as a "scenario", not as "anecdotal evidence". Now if the likelyhood of a scenario is in question, then anecdotal evidence would likely be used since it's nearly impossible to track actual frequencies in an auditable way.

Many of your complaints are resolved simply by not using OOP for domain objects. These include 'real-world matching', 'reinvention of databases', 'programmers as data-entry clerk', and the initial comment on OopBizDomainGap. These aren't "problems" OO gurus experience except when they truly need to reinvent a database because the SQL implementation or whatnot doesn't provide the relevant cross-cutting features (such as DeltaIsolation and subscription for ReactiveProgramming update).

You have to know any paradigm pretty darn well to become intimately familiar with its strengths and weaknesses. You have to know two paradigms pretty darn well to compare them fairly, because BadCodeCanBeWrittenInAnyLanguage. This issue is also implicit in the assumption that adding methods is equivalent to adding procedures. By analogy, if I was complaining that Relational is problematic because of GodTables, it would be analogous to your argument that OO is problematic because of lack of support for domain objects. For both GodTables and DomainObjects there are alternatives within the same paradigm.

As written, they then prematurely make claims of strength.

Please explain.