serial komik – Myth Guide – Object Oriented Myths

This guide describes where to find more informationon the myths listed on the Criticism of Object Oriented Programming page. (Please wait until theentire pages are loaded, because many of theselinks are in the middle or end of cited page.)

  • Myth: OOP is a proven general-purpose technique

    OOP may shine in certain niches, but there is noevidence that it improves software in general in any measurable way.

    See: Research Lacking, Goals and Metrics

  • Myth: OOP models the real world better

    See: Modeling the Real World

  • Myth: OOP makes programming more visual

    Although most “serious” OO proponents don’t believe this,it is commonly held among managers and new programmers,and is a big part ofthe reason for OOP’s rapid acceptance into the marketplacein my opinion.

    See: The GUI Connection

  • Myth: OOP makes programming easier and faster

    “Easier” is too vague a claim to study. My interpretationis that one really means that OOP “better fits the wayhumans think”, which is covered below.

    Regarding “faster”, most proponents claim that rapiddevelopment comes only after “reuse” builds up, so thatexisting building blocks can be “snapped into place”.Very few will claim that it is faster from the ground up,and may even be slower. I see nothing about OOP thatmakes for rapid development. Procedural componentshave been around and successful for quite a while,even in languages without “modern” proceduralfeatures. However, the biggest difficulty in obtaininga Lego block “snap-together” approach to softwarebuilding is related to the multifaceted interactionsneeded in real business software. Relational techniquesdo this better because theconnectivity and viewpoints can be”calculated” on-the-fly rather than hard-wiredinto code structures and rigid OO interfaces.

    See: Up-Front Modeling, Reuse Notes and Wiki Discussions, Components, Abstraction

  • Myth: OOP eliminates the “complexity” of “case” or “switch” statements

    This claim results in some of the most lengthy andheated debates I have everbeen in. Some issues relate to certain syntax of certainlanguages, such as C’s silly, archaic “break” statement. Outside of language-specific syntax,it appears to mostly be an issue of “aspect grouping”. There are(at least) two dimensions involved in examples compared, and one must pick which dimensionto favor at the expense of the others. In other words, there isno free lunch. Program code is pretty much a one-dimensional mediumand we are trying to project two dimensions onto it. Somethingis going to have to be sacrificed. Further, IF or CASE statements”degenerate” better when all the typical things thatgo wrong with polymorphism in the real world happen.Thus, IF/CASE is often better future-proofing.

    See: Single Choice Principle,Shapes Example,Aspects

  • Myth: OOP reduces the number of places that require changing

    I have not seen any examples where OOP improves the change impactscore given a typical set of realistic changes. I do find, however,that change impact examples in OOP textbooks and trainingmaterials tend to mostly showchange impact examples that favor OOP, ignoring non-OO-favoringchanges. In other words, there seemsto be some bias in the type ofexamples chosen for change impact illustrations. I cannotdetermine whether this bias is intentional or a “copy-cat”phenomena.

    It may be that by simply making people aware ofa particular problem pattern, they simply noticeit more than the other tradeoffs.This is sort of analogous to a shampoothat fixessplit-ends,but makes hair less shiny.If the ads keep emphasizing the splits ends,then people may pay more attention to thatthan the lack of shine, and visa versa.

    See: Change Patterns, Goals and Metrics, Shapes, Single Choice Principle

  • Myth: OOP increases reuse (recycling of code)

    Reuse is one of the biggest claims of OOP. However, reuseclaims have mellowed over the years as reality has set in.Some OO fans don’t even include it on their OO benefits listanymore.

    Some proponents have suggested that the biggest area ofOO reuse is with components. However, exactly how OOPcomponents are more “reusable” than non-OOP componentshas never been made clear. Some will argue that OOPcomponents are easier to have their “implementations swapped”.However, I have yet to find a common business need forswapping implementations to identical interfaces inmy domain. What manager is going to authorize havingtwo implementations of the same thing? Most examples used to illustrate swapping areeither unrealistic, or outside the stated domain.

    See: Wiki Reuse Discussion and Notes,Components,The Driver Pattern,Dr. Dobb’s Article – ‘Such Much OO, So Little Reuse’

  • Myth: Most things fit nicely into hierarchical taxonomies

    To their credit, many experienced OOP professionals agree thatheavy or deep hierarchies or taxonomies are over-hyped inmany OOP training materials. However, they appear unwillingto do anything to reduce such hype. Some suggest thatsuch are “just meant to introduce concepts only”.Many new OOP programmers still keep trying to force theirapplication models into animal-like or nature-like taxonomiesbecause they never saw any disclaimers or warnings.OOP without lots of inheritance and hierarchies iskind of “de-clawed” anyhow, making OOP less unique.

    See: Hierarchy-Happy, Subtype Proliferation Myth, People Type Experiment

  • Myth: Sub-typing is a stable way to model differences

    The “delta rule” is that you can take an existing class and only have to specify what is different to get new variationson the same thing. Although appealing as an idea, it hasnumerous problems in reality. One is the “Fragile ParentProblem”, where shops are too afraid to change a parentclass in fear of breaking lots of children. Second, is granularity issues, where doing things like overridingonly 1/3 of a method requires an interface overhaul,or results in duplicating the 2/3 that is the same.Further, the differences of multiple variationsmay not necessarily fit orstay in a tree-like pattern, creating duplication ormass code shuffling (“refactoring”). The real worlddoes not change in a tree-shaped manner for the mostpart. At least not the one I observe.

    See: Method Granularity, Fragile Parent Problem, Hierarchy-Happy

  • Myth: Self-handling nouns are more useful than self-handling verbs

    Some OO fans believe that grouping operations by or around nouns (entities) is somehow more magical or natural than grouping by tasks, which is thetraditional approach. I find grouping operations by noun ratherartificial because most operations in my domain involve multiplenouns, and the nouns involved may change over time. Thus, there is usually no “one right noun” to group it by.

    actionA( noun1, noun2, noun3)   // procedural  noun1.actionA( noun2, noun3)    // OOP

    I personally find the first approach more naturalin most situations.

    See: Sentences, The Noun Shuffle, Aspects

  • Myth: Each operation has one natural “primary noun”

    OO tends to believe that there is a natural associationbetween operations and the single “thing” that these operations operate on. It is sometimes also called “responsibility-driven design”. I agree that thereis sometimes a natural relationship in lower-leveldevice-driver-like API’s,but much less so at the domain (business) level. At the domainlevel the relationship between nouns and verbsis often shifting (dynamic) and many-to-many overthe longer run. The one-to-one or one-to-many associationoften assumed by OO is artificial. Even if there isa simple relationship at the time of design, it maynot last, resulting in a lot of code change to “upgrade”to many-to-many.

    The principles of information-hiding generallydictate that we hide specifics of implementation.If so, then the nouns used to carry out givenoperations should also be hidden from the interface if possible.However, OO requires one to “care” about whichprimary noun an operation is attached to. In manycases this is excess coupling of nouns and verbs. Example:

    system.print(x);  // unnecessary noun  print(x);        // how it should be  print(x, driver=system);  // optional different driver

    (See prior “self-handling” myth for related links)

  • Myth: OOP does automatic garbage-collection better

    I am not quite sure what claimers mean by this because theyrarely stick around to defend their claim. However, I haveheard it claimed at least twice.

    In my designs, most of the significant “instances” are in tables, andnot language-specific RAM structures. Thus, most complex”garbage collection” is part of managing thedatabase or table files (depending on the kind ofdatabase engine used). Also, garbage collection is avery language-specific issue.

    See: Memory Recovery Notes, Table Oriented Programming

  • Myth: Procedural cannot do components well

    The literature implies that OOP creates a “clean wall”between the component and the component user (reflectingsome of the vocabulary of “encapsulation”). However,functions have been doing this for a long time. But, OOPproponents claim that functions don’t manage state (inter-process data) verywell. I have not been given enough specific examples of functions failing from the claimersto verify this. (Although some of the few problems shownwere language-specific and not paradigm-specific.) Also, the use of tables as a communicationand state management mechanism is under-used, especiallyfor in-house components. Part of this is the “bigiron” mentality of many current database enginevendors.

    See: Components, Translation Layers

  • Myth: OO databases can better store large, multimedia data

    See: Meyer’s OOSC2, page 1051 Response

  • Myth: OODBMS are overall faster than RDBMS

    See: Meyer’s OOSC2, page 1051 Response, further down.

  • Myth: OOP better hides persistence mechanisms

    OO fans often say that OOP better “wraps the persistence (data storage) mechanism”. What they often mean is that it allegedly hides the database implementation so that database vendors/engines can be swapped without API change. In practice this is tough regardless of paradigm because many of the features are too different. The same interface will likely not work as-is under a new database system. It is one thing to wrap implementation, but another to wrap interfaces. The old API may assume a service or feature that the new database simply does not provide, for example.

    Further, databases are not just about persistence. Think of a database as a “state manager” (state roughly is the same as “data”) or “attribute manager”, and NOT a “persistence manager”. If a RDBMS ran entirely in RAM, the application developer would not know the difference. If anything, RDBMS abstract (hide) the fact that disk persistence is or isn’t being done. This is something that “raw” OOP has a hard time with. (Some RDBMS vendors are working on a RAM-only version of their database engines for certain kinds of needs.)

    OO is also a kind of state manager since it is customary to wrap state within classes in OOP. OO and databases tend to fight over the right to manage state. “Hiding” the state manager by re-writing one from scratch in OOP is not hiding, but simply exchanging one state manager (DB) for another (OOP code). OO fans often incorrectly call databases a “low level implementation”. Good database systems are not low level, except maybe to those who do not understand how to use them effectively.Relational databases hide indexing andad-hoc or virtual cross-referencing techniques better than most OOP, for example. And, OOP is notoriously messy or inconsistent withmany-to-many relationships.

    See Also: Why Procedural/Relational, Standard Collection Features, Invoice Detail Example

  • Myth: C and Pascal are the best procedural can get

    It is a fairly common debating flaw of OO proponents to usefeatures, or the lack of features, of specificprocedural languages as alleged evidence against non-OOP paradigms. Comparisons between C and C++are probably the most common. Many of the complaints fromOOP fans against procedural seem based onthe less flexible procedural languages and/orlack of skill in using some of the more modernfeatures/techniques. Often they look more likethe Luddite than me.

    See: Helpful Procedural/Relational Features

  • Myth: Only OOP offers automatic initialization

    This claim came from somebody commiting the above sin: comparingC to C++. Constructors and destructors are very similar to event-driven-programming events (which are not an OOP concept), and similar to RDBMS “triggers”, such as ON INSERT, ON UPDATE, and ON DELETEtriggers.

    Initializers or defaults could also be built into array or structure declarations inprocedural languages. The fact that theyare not found in most languages is not the fault of procedural, but of thelanguage vendor. (Whether they are a common need or not is another issue.)OOP does not demand that constructors be present in a language anymore thanprocedural does. It is a feature that could be added to any paradigm.(Ironically, OOP’s hype killed progress in many procedural languages.)

  • Myth: SQL is the best relational language

    I listed this myth becomesome have suggestedthat SQLcan get too convoluted or is too hard to learn, and thusthey argue one should consider using language-specificcollections (such as arrays) andloops instead of full-blown SQL.Ironically, complaints can often be heard that”proper OO is hard to learn”.

    However, I perfectly agree that SQL is far from the idealrelational language and also that existing RDBMS coulduse some improvements that would make software developmentand maintenance easier. For example, if more RDBMS providedtemporary or user-definable “views”, then larger SQL expressionscould be simplified by being divided up into smaller SELECTstatements without bothering the DBA to create a view.

    But even with its flaws, SQLis often superior than the OO practice ofreinventing a databaseand/or query system from scratch in myopinion.

    See: Alternatives to SQL, Criticism of SQL, Table Q & A

  • Myth: OOP would have prevented more Y2K problems

    See: Response to Meyer’s Y2K claims

  • Myth: OOP “does patterns” better

    The OO crowd appears more likely to view “patterns” as codingpatterns, while procedural/relational (P/R) tends to view themas mostly relational, Boolean, and set-based formulasor queries.P/R also tends to view them as “virtual”, “local”, and/or”as-needed” (HAS-A) insteadof global (IS-A). It is my opinion thatthe “virtual formula” approach is more change-friendly,compact, and cleaner in most cases.

    See: Procedural/Relational Patterns

  • Myth: Only OOP can “protect data”

    In practical business applications, a classis not likely to be thesole owner of any important piece of data. Thus, a classmay wrap a view or be a proxy for the data, but not actually “own” the data itself.If you want a flexible protection system that is notlimited to just basic nesting patterns, then ACL’s (AccessControl Lists) would probably be the best way togo. One could then have fine control over whichmodule, routine, method, class, etc. had access towhich user/resource. However, neither paradigm has ACL’s built in, and thuscannot claim high-level protection out of the box.See Data Protectionfor more on this.

    Further, even if OOP achieved pure wrapping ofdata somehow, that approach has downsides. One is anincreased need toreinvent database-likeprotocols/methods, bloating-up interfaces,and the other is an increasedrisk of needing to do theNoun Shuffledance.

    Many of the OO protection claims can also be done onRDBMS using triggers, referential integrity, views,and stored procedures. For example an “Updatetrigger” can ensure that any and all new records pass agiven test. Further, these applyto multiple languages using the same data, unlikemost OOP.

  • Myth: Implementation changes significantlymore often than interfaces

    Object oriented literature seems overly obsessed with theidea of a stable interface wrapping and hiding a turbulent, bubbling implementation. However, they actually bubble together,in my experience. In other words, significant changes inimplementation are quite likely to result in significantchanges to the interface also.

    I don’t see anything inOOP that assists with interface change management morethan other paradigms. In many cases it just seems toproduce excessive layers, which require a lot of workwhen interfaces change because the change affectspotentially each layer. (Layering is not native tojust OOP, but OO fans are more likely to get carriedaway due to excessive “hide at all costs” indoctrination.Layering also has limitations overmulti-viewpoint abstraction.)

    Some OO practices also increase the interfacesize beyond what is necessarily.Repeating collection-oriented operationsin many classes and componentsinstead of using existing collection engines to managecollections is an example of this.Lack of interface factoring (consolidation) is just asproblematic as lack of implementation factoring.However, OOP doctrine tends to ignore the first.

    See also: Driver Pattern

  • Myth: Procedural/Relational ties field types and sizes to the code more

    See: Zip-code Example

  • Myth: Procedural cannot extend compiled portions very well

    See: Compiled Unit Separation

  • Myth: No procedural language can re-compile at the routine level

    See: Compiled Unit Separation

  • Myth: Procedural/Relational programs cannot “factor” as well

    Although “factoring” has grown to mean a lot of things, themost consistent “core” meaning is removing repetition ofcode or code patterns to one or fewer spots. This tends tomake the code smaller and reduce the number of spots thathave to be changed for any given change.

    I have yet to see any code evidence that OOP clearly reduces repetition over other paradigms inthe stated domain.I have seen cases where it may tradeone type of repetition for another, such as withaspect intersections, but not produce a clear net reduction.

    I have also seen cases where the OO fan hasonly had exposure to poor procedural programmingtechniques and/or languages. In other words,they often compare bad procedural/relationalcode to decent OOP code.

    See: Repetition Factoring, Inheritance vs. Defaults, Inheritance Code-Size Study, Interface Bloat

  • Myth: OOP models human thought better

    This claim is especially common in the older OOPliterature. I don’t know exactly how they cometo this conclusion, unless it is subjective.I don’t question that some people may indeedthink better under OOP.

    See: One Mind Fits All?

  • Myth: OOP is more “modular”

    “Modular” is kind of a vague term. It oftenimplies a Lego-like building-block structurethat allows one to snap together pre-built componentsand/or provide divisions to better manage andthink about things.

    I find that the ideal grouping of something tends tobe relative to particular needs. There isusually no one ideal “global” grouping becausemultiple aspects are usually involved with anythingnon-trivial; thus, our grouping choice is usuallya compromise. Factoring a significant portion of informationinto relational tables assists with such relativism becauseone can issue queries or views to bring about the desired”virtual” grouping on an ad-hoc basis.

    Further, OOP seems to lack a grouping partition sizebetween class and application. This makes it hard forme to navigate a “sea of classes”.

    See: Encapsulation, Components, Aspects

  • Myth: OOP divides up work better

    This is yet another claim that is poorlyarticulated. I find that dividing up thecode into task units (task-based modules)does a pretty good job of dividing updevelopment labor. Inter-task communicationcan often nicely be handled viatable/database “messaging”.

    See: P/R Business Modeling

  • Myth: OOP “hides complexity” better

    See: Abstraction

  • Myth: OOP better models spoken language

    This is a claim that I don’t see often, but those who hold itseem pretty adamant about it.

    See: Modeling Sentences

  • Myth: OOP is “better abstraction”

    See: Abstraction

  • Myth: OOP reduces “coupling”

    “Coupling” is another one of those buzz-words that is sometimes waved about like a magic sword. It generally refers to things being tied together so that if one changes, it may impact the other. Not surprisingly, reducing coupling in one spot often increases it in another. Thus, measuring the total impact can get sticky. Besides, couplingis sometimes a good thing because it allows groups of things tobe moved or handled as a unit instead of repetitiously handlingeach item by itself. Coupling is something to bemanaged, not gotten rid of. OO’s encapsulation is evena form of coupling. (Whether encapsulationis a “good” form of coupling or not is another topic.)

    Some say that “proper OOP” will reduce coupling. My observation is that the change patterns they assume in their calculations or reasoning are not very realistic, at least not in the stated domain. They are unknowingly increasing some forms of coupling, such as coupling to assumptions of continued mutual exclusion, assumptions that one aspect will remain more important than others, and excessively tight integration to complex protocols.

  • Myth: OOP does multi-tasking better

    It is sometimes claimed that OOP can better launchand/or manage multiple processes within an application.I have not seen enough examples from the business worldto fully evaluate this claim, but will point out thatone can often use a database to manage communicationbetween multiple processes. There are many features, suchas transaction management, provided by most databases thatcan greatly reduce the amount of application code devoted tomanaging inter-process communication. Seeconcurrency comment in OOSC2.

  • Myth: OOP scales better

    The claim is that OOP is better for buildinglarge systems and/or large applications. Scaling comparisons tend to be a can of worms because ofthe different techniques and styles in partitioningbetween paradigms. Also, batch, client/server, andweb applications tend to have differentpartitioning strategies from each other.Looking at EXE sizemay be useful for client/server comparisons, butnot for web applications which may rely mostly on a bunch ofscripts and use mostly the database to communicate statebetween scripts instead of language structures in RAM.

    Decent procedural/relational tends to rely onthe database(s) as the primary “backbone” to gluerelatively independent tasks or events together, and notapplication code. OOP seems instead towant “one big EXE”. Many of scaling failures ofprocedural that led some to turn to OOP were becauseusage of databases was not well-understood back then.Using databases reduces the need for large in-memory (application)constructs.

    Anyhow, comparingthe size of the two is often comparing apples and oranges.Is three-hundred Microsoft Access applications hooked to alarge database via ODBC a “large system”, abunch of “small systems”, or both? (I am notpromoting Microsoft tools here; just providing foodfor thought.)

    See: Size comment from OOSC2

  • Myth: OOP is more “event driven”

    My search for a consistent definition of”event driven” has failed to turn up anythingworth repeating. Getting objects to respondto GUI events usually requires a non-trivialframework. Such frameworks can be built anumber of ways in a number of paradigms.

    See: Event Tables

  • Myth: Most programmers prefer OOP

    To be fair, there are no known good surveys on developers’ opinions on OOP. To complicate matters, here are some other factors that mayaffect any measurement or survey:

    • Many “high-level” OO gurus say that most actual production code written in OOP languages, such as Java, tends to be procedural in nature. In other words, many programmers are using OOP syntax, but not much OO beyond that without even knowing that it is not really OO (or just “OO-Lite”).

    • Many programmers switched to OOP because they and/ortheir shop didn’t know good procedural/relational techniquesor used only lame procedural languages.They are comparing decent OO to bad p/r because they don’tknow any better. This problem is made worse by the factthat most software engineering training focuses on theOO paradigm, ignoring the others. In other words, the OOPhype is becoming a self-fulfilling prophecy by smotheringeducation in the alternatives.

    • Most programmers I know simply “go with the flow”.If assembly languages came back in style, they would gladlyflock to them if it increased their paychecks and/or madethem more employable. They would tend to answer a surveywith whatever is in style because that is where they areheaded. In my observation, the choice of paradigm is mostlydetermined by what managers prefer, and they are moreeasily swayed by toy examples, clever cliches, andbrochure-talk than programmers. But, programmers generally haveto go along with the preferences of those who hire and fire.

    • Being popular is not necessarily the same as “being good”.

    See Also: Pro-OO Debate Tactics,PaulGraham on “Being Popular”

  • Myth: OOP manages behavior better

    This is a claim that I have heard more of recently.For the most part, I find behavior and data interchangeable.One can shift the application toward a more code-centric(behavioral) design or toward a data-driven design, if you know how.I lean toward data-driven designs because data iseasier to customize one’s view of than code. Thereare more “maths”, tools, and techniques to browseand manipulate data views than there are codetools. Things that don’t convert smoothlyto easy-to-view data includeInterweaving Orthogonal Conditions.But, I don’t see how OO improves these either. Subtype theoryand its related polymorphic dispatching are just not powerful enoughto deal with multiple dynamic dimensions without making a mess.And, “responsibility-driven design” (see above “primary noun” myth)assumes a tight one-to-one relationship between nouns and verbsthat really often should be prepared for many-to-many in my observation.

    See:Code Neutering,Data Dictionaries

  • Myth: OOP gets stains out of clothing better

    This myth is still under research. It may turn out tobe the only myth that is accurate. I will keepyou posted.

  • Disclaimer About Myth Frequency

    Not all myths discussed are necessarily shared by all or evenmost OO proponents. They are based on “common notions” foundin the business and programming world as I have observed them.I am making no claims as to the frequency of beliefs in the myths.My frequency of encounter may differ from yours. I didnot make these myths up, yet I still get hammeredfor stating them.For example, the “garbage collection” myth is often criticized as a rarely-held myth. Yet it consistently comes up about once every 6 months or so in debates and commentary. I am just the messenger.Discussingmyths is not the same as “punching a straw-man”, which someOO proponents claim I am doing by mentioning myths. Otherpopular sites talk about myths without citingthe sources for all myth statements.Why am I held to a higher standard? If you do not share beliefin a given myth, then simply ignore that section. I don’t knowwhy this bothers some readers so much. I get constant complaintsabout it. Note that some of these myths are shared byBertrand Meyer.

    OOP Criticism © Copyright 1999, 2000, 2001, 2002 by Findy Services and B. Jacobs

    serial bacaaan komik – Software, Science, and Math

    uch as Artificial Intelligence, where the answer is not necessarily “fixed”. The “answer” is judged more or less on a continuous scale. In these situations different algorithms are compared and the results are ranked. For example, a metric similar to a lab-rat maze test for intelligence testingcan be performed to evaluate performance.However, just because a given algorithm is known to be better, this does not tell us if it is the “right” or only possible algorithm. It might be the “best known” at a given point in time, but not much can be concluded beyond that. As expounded upon later,we don’t know what we don’t know.