Arguments Against Oop
    Summary of Criticisms Against OO
    As agreed in AcceptableCriticismOfOoOnWiki, below is a list of criticisms raised against ObjectOrientedProgramming. The opposing twin of this topic is BenefitsOfOo.
    Note that not every critic will agree with all of these, nor will all OO proponents agree with all the characterizations of OO given here. This is simply a collection of criticisms put forward. To keep this page clean, please put debates in the sections below, rather than embedded in the list itself. (See PageAnchor “replies”) I moved the longer ones below, but left some short ones in place. [EditHint: somebody rearranged the replies into a single topic for pro and con replies and it’s now very confusing and very long. (I’m angry about it.) Needs a rework.]
    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. See LimitsOfHierarchies, ThereAreNoTypes, SwitchStatementsSmell. Even if domain trees were found, I am not sure they belong hard-wired in code. Generally one should not hard-wire non-trivial taxonomies/classification-systems into code. This is what databases are for so that one can get different views of the same data depending on use and context. (Note that many OO proponents use organizational techniques other than hierarchies. However, loss of hierarchies takes with it promises of something simpler than a big messy graph.)
    PolyMorphism - Sub-type polymorphism suffers many of the same problems as inheritance: its “taxonomy” is artificial. Sets are seen as more powerful than lists of mutually-exclusive types or type hierarchies. For one, they handle orthogonality (current or future) better than polymorphism. However, the logical extension of sets leads to relational more or less. OO seems to introduce DiscontinuitySpikes (more change effort) when something goes from IS-A to HAS-A. (There are other kinds of polymorphism besides sub-type, but sub-typing is the most common.) See PolymorphismLimits.
    Encapsulation
    Grouping related behavior - There is no single “right” grouping because grouping needs are relative and situational. However, “task” grouping is usually more stable than noun-based grouping. Procedural modules can be used to group related functions. See: [in progress, prior material was deleted]
    Protection of “innards” - Database triggers, referential integrity, and stored procedures can provide similar protection on a larger scale and in multiple languages. On a smaller scale the innards are no more “naked” in procedural than they are in say SmallTalk programs. See: GateKeeper.
    CantEncapsulateLinks anyhow. OO does not address managing inter-object links in a consistent and robust way.
    Concurrency Issues - We might distinguish OOP from ActorsModel in that OOP objects, in practice, use synchronous messaging (effectively, procedure calls) - i.e. an external ‘thread’ can be involved in a ‘stack’ of OO messages at once. This is good for performance-in-the-small, but is also a major source of concurrency bugs (deadlock, race conditions, reentrancy issues) and scalability issues.
    ReinventingTheDatabaseInApplication - and poorly (slow, buggy, small scale, lack consistency properties and concurrency control of dedicated database systems) becomes a common AntiPattern in many OO projects. Some OOP languages or libraries offer persistence (ImageBasedLanguage, HiberNate, GemStone) which can avoid some hassles, but one still ends up reinventing any ad-hoc query and crud operations (because DatabasesAreMoreThanJustStorage).
    Does Not Model Human Mind - The human mind is delightfully capable of holding many ‘views’ or ‘models’ of our perceptions at once - based on the patterns we need to emphasize for whichever problem we are solving. In a sense, an object in human perception is just one way of viewing the world. OO forces us to pick just one ‘model’ and entrench it in our program. The use of stateful objects and encapsulation both prevent us from effectively supporting multiple ‘views’ by functional or logical transforms. In a very real sense, objects are often ‘intuitive’ in a bad way that can easily lead us to error.
    Besides this, how we view things is primarily a function of how we learn to view things - i.e. the patterns that prove most useful to us are the ones that stick in our brains. Because of this, even though fundamental cognition in humans is relatively consistent across the species (with rare exceptions - just as there are exceptions to the ‘2 arms, 2 legs, 1 heart’ rule), such things as culture and prior work experience can have a significant impact on whether OO objects feel so natural to us that some might make hand-wavy allegations that OO models the human mind, or whether we might vehemently deny it.

    反对Oop的争论
    对OO的批评总结
    正如AcceptableCriticismOfOoOnWiki中所达成的那样，下面列出了针对ObjectOrientedProgramming提出的批评。这个主题的对立双胞胎是BenefitsOfOo。
    请注意，并非每个评论家都会同意所有这些，所有OO支持者也不同意这里给出的OO的所有特征。这只是提出的一系列批评。为了保持这个页面的清洁，请在下面的部分中讨论，而不是嵌入在列表中。 （参见PageAnchor“回复”）我移动了下面较长的那些，但留下了一些短的。 [EditHint：有人将回复重新排列成一个主题，用于赞成和回复，现在它非常令人困惑且很长。 （我很生气。）需要返工。]
    继承 - 在某些领域，现实世界不会以分层方式形成和改变。树木可能在精神上“吸引人”，但它们过于人工，不能随着变化和新细节而弯曲。请参阅LimitsOfHierarchies，ThereAreNoTypes，SwitchStatementsSmell。即使找到域树，我也不确定它们是否属于代码中的硬连线。通常，不应该将非平凡的分类法/分类系统硬连接到代码中。这就是数据库的用途，以便根据使用和上下文可以获得相同数据的不同视图。 （请注意，许多OO支持者使用除了层次结构之外的组织技术。但是，层次结构的丢失需要一种比一个大的凌乱图形更简单的东西。）
    多态性 - 子类型多态性遇到许多与继承相同的问题：它的“分类法”是人为的。集合被视为比互斥类型或类型层次结构的列表更强大。首先，它们比多态性更好地处理正交性（当前或未来）。但是，集合的逻辑扩展会或多或少地导致关系。当从IS-A到HAS-A时，OO似乎会引入DiscontinuitySpikes（更多的改变努力）。 （除了子类型之外还有其他种类的多态性，但是子类型是最常见的。）参见PolymorphismLimits。
    封装
    分组相关行为 - 没有单一的“正确”分组，因为分组需求是相对的和情境性的。但是，“任务”分组通常比基于名词的分组更稳定。程序模块可用于对相关功能进行分组。请参阅：[正在进行中，之前的材料已删除]
    保护“内部” - 数据库触发器，参照完整性和存储过程可以在更大规模和多种语言中提供类似的保护。在较小的范围内，内脏在程序上不再像在SmallTalk程序中那样“裸露”。请参阅：GateKeeper。
    无论如何，CantEncapsulateLinks。 OO没有以一致和健壮的方式处理对象间链接。
    并发问题 - 我们可能将OOP与ActorsModel区分开来，因为OOP对象在实践中使用同步消息传递（实际上是过程调用） - 即外部“线程”可以同时涉及OO消息的“堆栈”。这对于小型性能有利，但也是并发错误（死锁，竞争条件，重入问题）和可伸缩性问题的主要来源。
    重新创建数据库应用程序 - 并且很差（缓慢，错误，小规模，缺乏一致性属性和专用数据库系统的并发控制）成为许多OO项目中的常见AntiPattern。一些OOP语言或库提供了持久性（ImageBasedLanguage，HiberNate，GemStone），它可以避免一些麻烦，但仍然最终重新发明任何即席查询和crud操作（因为DatabasesAreMoreThanJustStorage）。
    不模仿人类思维 - 人类的思维能够立刻拥有我们认知的许多“观点”或“模型” - 基于我们需要强调的模式来解决我们正在解决的问题。从某种意义上说，人类感知中的一个对象只是观察世界的一种方式。 OO迫使我们挑选一个“模型”并将其固定在我们的计划中。有状态对象和封装的使用都阻止我们通过功能或逻辑转换有效地支持多个“视图”。从一个非常真实的意义上讲，对象通常是“直观的”，可能很容易导致我们出错。
    除此之外，我们如何看待事物主要取决于我们如何学习观察事物 - 即对我们最有用的模式是坚持我们大脑的模式。正因为如此，即使人类的基本认知在物种间相对一致（少数例外 - 正如“2臂，2腿，1心”规则的例外），文化和以前的工作经验等事情都可以对OO对象是否对我们来说感觉如此自然有一些影响很大，以至于有些人可能会对OO模拟人类思维，或者我们是否会强烈否认它进行手工波动的指控。

    I’d like links to some evidence that “cognition in humans is relatively consistent across the species” if the environment is filtered out as a factor. I’m not even sure that is legally testable outside of Nazi Germany-like techniques. However, for the sake of this discussion, perhaps the nature-vs-nurture issue should be put aside and merely state that developers, as is, think differently. The cause of the difference is mostly irrelevant to this topic and perhaps a distraction. It’s TMI for the topic at hand. -t
    Basic human thought processes, skill acquirement, recognition and learning and so on are the same across the species based on studies in labs and even under MRI. Most are even common across many animals. Study the subject in your own time if it interests you. Different human developers will think about different things - i.e. approaching a common problem from different perspectives. They may have different skill sets to apply, and use different tools to aide their action. But they do not think differently - not in terms of fundamental cognitive mechanisms.
    I’d have to question that. There are many ways to model processes and abstractions in one’s head. Even notation-wise, sets can be modeled as graphs and vice verse. Music scores can be modeled as d-shaped marks or as time-versus-frequency bars (sometimes called “piano-roll view”). Neither is necessarily or summarily “wrong”, just different. There is no good data on whether in-born individual traits will make one gravitate toward one or the other in the absence of environmental influences. Studies of separated-at-birth twins suggests that some of it may be in-born. -t
    The topic line here is “OO Does Not Model The Human Mind.” This claim is very different from “The Human Mind Does Not Model OO.” An ability to model an OO process in our heads is a skill. Whether OO models our heads is a question of hard, low-level, cognitive psychology. People do have predispositions for different skills, but that isn’t relevant under the topic line.
    Continued at, and eventually moved to OopAndHumanThoughtProcess.
    A paradigm to model human thought processes would involve recognizing ad hoc patterns in large bodies of data and taking action - i.e. closer to rules-based programming, or temporal logic programming. OO does much to hinder this. Of course, the question of whether a paradigm that models human thought would be a GoodThing is distinct from the question of whether a given paradigm roughly models human thought.
    Behavioral Tilt is Limiting - Behaviors are difficult to pick apart, analyze, share, compare… difficult to query in rich ways. I’ve read a paper describing a search engine where one could query a code-base with something like: give me a function for roman numerals that, given the values 1,3,4,6 will return “I”, “III”, “IV”, and “VI” respectively. The search engine would then use ‘roman’ and ‘numerals’ as search terms in comments and identifiers and would test discovered functions to see if they fit the criterion. However, this sort of query becomes less feasible to perform as behaviors gain dependencies upon objects, global values, deep libraries, and preconditions. Simple data types are much easier to work with, share (with other languages and processes and tools), query, and reason about… and it seems reasonable, therefore, that we should put as much of an application into plain-old-data as we can make fit… and that we should find ways (idioms, patterns, language designs) that allow us to fit even more of an application into data. OO over-emphasizes behavior - as a first resort, when it should be nearer a last resort.
    Related: DataCentricThinking, CodeAvoidance, InterfaceFactoring.
    Lack of Modeling Consensus - There is a wide variety of opinions about how to do “OO modeling”. Some tilt toward the “physical-model” birth of OO in Simula-67, while others prefer ResponsibilityDrivenDesign, for example. Thus, we have both a physical tilt and a social tilt of opinions. Yet others say that OO is simply a way to organize code and should not be a higher-level modeling statement. See OopGoesHalfWay.
    Lacks Normalization Rules - OO has nothing equivalent to relational NormalForm rules and guidelines to produce consistency and reduce known duplication.
    King Noun is Artificial - OO generally assumes there is one PrimaryNoun per action or operation. This assumption is often artificial. There is no such identifiable force of nature or human interaction. The nouns that participate in any given action are often numerous and changing. It is sometimes said that one should group code by the most stable factors. “Task” or “operation” is more stable than nouns or entities for the most part. One should be able to swap/change the noun(s) without changing the calling code. This is InformationHiding. In the real world, the relationship between nouns and actions is often many-to-many, and OO has generally been problematic with many-to-many relationships. ManyToManyChallenge.
    如果将环境过滤掉作为一个因素，我想要一些证据表明“人类认知在整个物种中相对一致”。除了纳粹德国式的技术之外，我甚至不确定这是否具有法律效力。然而，为了这个讨论，也许应该抛开自然与培育的问题，并且只是说开发人员的思维方式不同。差异的原因大多与这个话题无关，也许是分散注意力。这是手头话题的TMI。 -t
    基于实验室甚至在MRI下的研究，基础人类思维过程，技能获取，识别和学习等在整个物种中是相同的。大多数动物甚至很常见。如果您感兴趣，请在您自己的时间内研究该主题。不同的人类开发人员会考虑不同的事情 - 即从不同的角度处理共同的问题。他们可能拥有不同的技能组合，并使用不同的工具来帮助他们采取行动。但他们没有不同的想法 - 不是基本的认知机制。
    我不得不质疑。有很多方法可以在一个人的头脑中建模过程和抽象。即使是符号表示，集合也可以建模为图形和反之亦然。乐谱可以被建模为d形标记或时间 - 频率条（有时称为“钢琴 - 滚动视图”）。无论是必然的还是即时的“错误的”，都是不同的。在没有环境影响的情况下，没有关于出生的个体特征是否会使一个人倾向于一个或另一个的良好数据。对分娩双胞胎的研究表明，其中一些可能是在出生时。 -t
    这里的主题是“OO不会塑造人类心灵”。这种说法与“人类心灵不会模仿OO”非常不同。在头脑中建立OO过程的能力是一项技能。 OO是否模仿我们的头脑是一个困难，低级，认知心理学的问题。人们确实有不同技能的倾向，但这在主题界线下并不重要。
    继续，并最终转移到OopAndHumanThoughtProcess。
    模拟人类思维过程的范例将涉及识别大量数据中的特定模式并采取行动 - 即更接近基于规则的编程或时间逻辑编程。 OO在很大程度上阻碍了这一点。当然，关于模仿人类思想的范式是否是GoodThing的问题不同于给定范式是否粗略地模拟人类思想的问题。
    行为倾向是限制 - 行为很难分开，分析，分享，比较……难以以丰富的方式查询。我已经阅读了一篇描述搜索引擎的论文，其中人们可以通过以下方式查询代码库：给我一个罗马数字函数，给定值1,3,4,6将返回“I”，“III” ，“IV”和“VI”。然后，搜索引擎将使用“罗马”和“数字”作为注释和标识符中的搜索项，并测试已发现的函数以查看它们是否符合标准。但是，当行为获得对象，全局值，深层库和前提条件的依赖性时，这种查询变得不太可行。简单的数据类型更容易使用，共享（与其他语言，进程和工具），查询和推理…因此，我们应该将尽可能多的应用程序放入普通的应用程序中，这似乎是合理的 - 数据，因为我们可以使… …我们应该找到方法（成语，模式，语言设计），使我们能够将更多的应用程序适合数据。 OO过分强调行为 - 作为第一手段，它应该更接近最后的手段。
    相关：DataCentricThinking，CodeAvoidance，InterfaceFactoring。
    缺乏建模共识 - 关于如何进行“OO建模”有各种各样的意见。一些人倾向于在Simula-67中出现OO的“物理模型”，而其他人更喜欢责任驱动设计。因此，我们既有物理倾斜，也有社会意见倾斜。还有人说OO只是一种组织代码的方式，不应该是更高级别的建模声明。见OopGoesHalfWay。
    缺乏规范化规则 - OO没有任何等效于关系NormalForm规则和指南来产生一致性并减少已知重复。
    King Noun是Artificial - OO通常假设每个动作或操作都有一个PrimaryNoun。这种假设通常是人为的。没有这种可识别的自然力量或人类互动力量。参与任何特定行动的名词往往数不胜数且不断变化。有时候人们应该用最稳定的因素对代码进行分组。 “任务”或“操作”在大多数情况下比名词或实体更稳定。一个人应该能够在不改变调用代码的情况下交换/更改名词。这是InformationHiding。在现实世界中，名词和动作之间的关系通常是多对多的，并且OO通常在多对多关系中存在问题。更多的挑战。

    Counter view moved to PrimaryNoun.
    Marries you to NounModel - Related to above, procedural tends to divorce (decouple) the code “shape” from the NounModel. If the noun-model changes, the impact tends to be less than it would be in OOP. One may have to change query code, but they don’t have to change the formal relationship between procedures and modules. (In procedural the NounModel is mostly in the database, at least in biz apps.)
    This seems redundant. Refactor these arguments, minimize rants. TimeToMakeItShort.
    No Empirical Evidence for OO - The case for OO is mostly based on ArgumentFromAuthority and “toy” examples that some feel distort the probability of certain change patterns. See OoEmpiricalEvidence.
    OO is Xenophobic - In practice information needs to be shared between many tools and many languages and possibly many paradigms. Data-messaging is generally easier for this than behavior-based messaging, and data-centric approaches tend to rub against OO encapsulation philosophy. OO that force ‘values objects’ for messages compromise the EverythingIsa object concept. See also “Standardized Attribute Management” below.
    this seems redundant with the ‘behavioral tilt’.
    TextbookOo is Deceiving - The simple structures and concepts in OO training material fall by the wayside in the real world, leaving one with a tangled mess that is nowhere near as simple and clean as the examples. Many managers are easily mislead by such examples. ObjectOrientedDesignIsDifficult
    OO is often hard to teach - Beyond TextbookOo examples, OO is hard to “get right” and/or it is tough to articulate in clear language and with open inspection why OO is (allegedly) better. Attempts to justify OO often have an eastern wispy feel rather than a western reductionalist approach favored by modern science.
    This is not easily justifiable, and is a hand-wavy claim itself. I suggest we remove it.
    Counter view: That is because OOP should be taught with design patterns. Imagine teaching procedural programming without teaching the methodologies to attack problems (divide and conquer etc.)
    Visitor is hardly a simplification technique, and there are no clear guidelines for when to apply which pattern. I find the existing guidelines much vaguer and open-ended than relational normalization techniques. (See DoubleDispatchExample)
    If the confusion demonstrated on this page is any indication, OO is probably a lot harder to teach than it is to learn. {meaning?}
    Global Abstractions - OO tends to assume or strive toward central global abstractions, which are insufficient to handle a multifaceted, relative, and interweaving world. In contrast, DataCentricThinking tries to make one’s view be supplied in an as-needed basis based on situational criteria.
    Lacks standardized collection handling - OO has failed to create consistent collection/relationship handling techniques. How multiple objects interact and relate seems to be left up indidivuals with no consensus forming. Each language or shop reinvents its own libraries and conventions, and these often don’t scale beyond the language or RAM without one ending up reinventing a database-like-contraptions from scratch. The “reinvention” of such CollectionOrientedVerbs for each and every class is seen as a violation of OnceAndOnlyOnce by some. It “smells” of a larger repeating concept that is not being extracted/factored out to a central protocol or standardized feature set. See InterfaceFactoring, OoConflictsWithCollectionOrientation.
    Standardized Attribute Management - I’m not sure if this belongs under collection handling or the “xenophobic” item or both. But a frustration I have with OOP is that one cannot study all the attribute assignments (set/get’s) with other tools because they are “locked” into an app-language-specific format. If they were in relational form or XML, one could use a standard off-the-shelf table viewer or XML editor/viewer to edit, study, search, sort, query, report on, etc. the soup of attributes. Instead I have to rely on language-specific tools, if there are any. It’s not logical for each app language or IDE to reinvent all those collection-oriented idioms (although the stubborn companies will try). -t
    OO runs too slow - I don’t necessarily agree with this or even care that much. But others have made such a claim and so I shall at least document that fact that the claim appears from time to time.
    计数器视图已移至PrimaryNoun。
    嫁给NounModel - 与上面相关，程序倾向于将代码“形状”与NounModel离婚（解耦）。如果名词模型发生变化，其影响往往小于OOP。可能必须更改查询代码，但它们不必更改过程和模块之间的正式关系。 （在程序上，NounModel主要在数据库中，至少在商业应用程序中。）
    这似乎是多余的。重构这些论点，尽量减少咆哮。 TimeToMakeItShort。
    没有OO的经验证据 - OO的案例主要基于ArgumentFromAuthority和“玩具”示例，有些人认为这些示例会扭曲某些变更模式的可能性。见OoEmpiricalEvidence。
    OO是仇外的 - 实际上，信息需要在许多工具和许多语言之间共享，并且可能需要许多范例。与基于行为的消息传递相比，数据消息传递通常更容易，而以数据为中心的方法往往会违背OO封装理念。迫使消息’值对象’的OO会破坏EverythingIsa对象概念。另请参见下面的“标准化属性管理”。
    这似乎与“行为倾斜”有关。
    教科书是欺骗 - OO训练材料中的简单结构和概念在现实世界中落在了一边，留下一个混乱的混乱，远不如示例那么简单和干净。许多经理很容易被这些例子误导。 ObjectOrientedDesignIsDifficult
    OO通常很难教 - 除了教科书之外，OO很难“正确”和/或很难以清晰的语言表达，并且公开检查为什么OO（据称）更好。为OO辩护的尝试往往具有东方纤细的感觉，而不是现代科学所偏爱的西方缩减主义方法。
    这不容易证明是合理的，并且本身就是一种手持式的说法。我建议我们删除它。
    反制视图：这是因为应该用设计模式教授OOP。想象一下教授程序编程而不教授攻击问题的方法（分而治之等）
    访问者几乎不是一种简化技术，并且没有明确的指导方针来确定何时应用哪种模式。我发现现有的指南比关系规范化技术更加模糊和开放。 （参见DoubleDispatchExample）
    如果在这个页面上显示的混乱是任何迹象，OO可能比学习更难教。 {含义？}
    全局抽象 - 面向对象倾向于假设或努力实现中心全局抽象，这不足以处理多方面，相对和交织的世界。相反，DataCentricThinking尝试根据情境标准根据需要提供一个视图。
    缺乏标准化的集合处理—OO无法创建一致的集合/关系处理技术。多个对象如何相互作用和相互关联似乎是在没有共识形成的情况下留下的。每种语言或商店都会重新发明自己的库和约定，而这些通常不会扩展到语言或RAM之外，最终不会从头开始重新构建类似数据库的装置。这种CollectionOrientedVerbs对每个类的“重新发明”被一些人视为违反了OnceAndOnlyOnce。它“气味”更大的重复概念，没有被提取/分解到中央协议或标准化特征集。请参阅InterfaceFactoring，OoConflictsWithCollectionOrientation。
    标准化属性管理 - 我不确定这是属于收集处理还是“仇外”项目或两者兼而有之。但是我对OOP感到沮丧的是，人们无法使用其他工具研究所有属性赋值（set / get），因为它们被“锁定”为特定于应用语言的格式。如果它们是关系形式或XML，则可以使用标准的现成表查看器或XML编辑器/查看器来编辑，研究，搜索，排序，查询，报告等属性的汤。相反，我必须依赖特定于语言的工具，如果有的话。每个应用程序语言或IDE重新发明所有那些以集合为导向的习语是不合逻辑的（尽管顽固的公司会尝试）。 -t
    OO运行速度太慢 - 我不一定同意这一点，甚至不太关心。但是其他人提出了这样一个主张，所以我至少会记录这个主张不时出现的事实。

    Later on you say that persistence should be handled by the RDBMS… I can not imagine anything slower than that for the vast majority of the tasks you want to perform.
    To some extent I agree, but it is hard to call OO the “paradigm of the future” if you use it only because current chips are not fast enough to handle relational-based abstraction. Higher abstraction usually requires more horse-power. Most bottlenecks I encounter have to do with collection-handling issues, not processes themselves, and DB’s tend to do well on larger datasets (if decent indexing, normalization, etc.) Thus, OO may be faster when processing 5 items, but not when processing 5000. The 5 item scenario is usually not the bottleneck anyhow. In short, it scales better.
    Some of the justification given for OO comes from lackluster specific languages or lackluster specific implementations. For example, CeeIsNotThePinnacleOfProcedural.
    Fails DivideAndConquer of data and operations - If you split things into data and behavior, then you can apply the best data tools (RDBMS) to the data and the best behavior tools to the behavior. ComparativeAdvantage. OO tends to intermix them, dragging them both down to the lowest common denominator. For example, data schemas (noun relationships) are pretty compact as database schemas, but not so if dispersed around in application code.
    OO forces one to think too much about “persistence”. In database-centric approaches, persistence is an almost automatic by-product of using the database. (However, some databases don’t support temporary tables very well.) But in OO you are often forced to think about when and where to “save” stuff to disk, complicating the design. Modern caching techniques allow databases to use RAM or disk automatically without the app developer having to select one or worry about it. OO has yet learned to take advantage of such technology.
    That’s too slow.
    See speed comment above [EditHint: Perhaps move these con’s and replies below to keep the primary list uncluttered]
    Structured programs still have to talk to DBAMs and somebody has to build the DBAMs. OO doesn’t make any of this different. The DB access code inside an object method looks just like the corresponding code in a subroutine.
    OO being (allegedly) good at building an internal DBMS engine does not necessarily mean it is good at every other domain. (See OopNotForDomainModeling.)
    Heavy integration of data and behavior reduce cross-language sharing of protocols and data. (CrossToolTypeAndObjectSharing)
    Since most businesses store attributes in RDBMS, there is often a “paradigm conversion tax” between OO and the RDBMS in terms of complexity and speed.
    OO does not offer any kind of CollectionOrientedProgramming short-cuts. For example, it usually takes a lot of code to iterate through or get summary information about each subclass of a master class. Some feel these kinds of things should be built into something that claims to be a “modern paradigm” or language. But encapsulation seems to disallow it from OO. See near bottom of RelationalBreaksEncapsulation. [Perhaps merge this item with “Lacks standardized collection handling”]
    OOP is for some reason a very productive “fad factory”. It generates all kinds of buzzwords and ill-defined concepts that everybody is encouraged to use, but the why’s, when’s, and how’s are not very well defined. This includes patterns, SOA, responsibility-driven design, MVC, etc.
    OO is not suitable for writing application code. OO tends to focus on reuse, stability of the conceptual model and minimization of dependencies. These aspects are not very useful for application code. There are good reasons to use OO for writing reusable platforms or libraries. However, OO has been sold and advertised for all kinds of purposes, usually far exceeding the real scope where it can be applied. Perhaps this can be extended in WhenToUseWhatParadigm.
    OO is Anti-Declarative - OO tends to view things as behavioral wrappers around state. This is against the idea of attribute-driven programming and/or specification. One could create OO frameworks that are mostly assignments to attributes, but this essentially turns it into a database of sorts, but without the query-ability of databases.
    OOP can be too much set-up code for single-spot and single-time usage. Not every piece of code is meant or fit for a generic kit or tool, but is often very domain-specific and task-specific. See ComparingDynamicVariables and YagNi for more.
    See below for a list of ways OOP allegedly violates OnceAndOnlyOnce.
    后来你说应该由RDBMS来处理持久性……我无法想象比你想要执行的绝大多数任务更慢的事情。
    在某种程度上我同意，但是如果你只使用它而不是因为当前的芯片不够快以处理基于关系的抽象，那么很难将OO称为“未来的范例”。更高的抽象通常需要更多的马力。我遇到的大多数瓶颈都与收集处理问题有关，而不是处理本身，而DB往往在较大的数据集上做得很好（如果体面的索引，规范化等）。因此，OO在处理5个项目时可能会更快，但不会在处理5000.无论如何，5项方案通常不是瓶颈。简而言之，它可以更好地扩展。
    为OO提供的一些理由来自于乏善可陈的特定语言或缺乏特定的实现。例如，CeeIsNotThePinnacleOfProcedural。
    失败DivideAndConquer数据和操作 - 如果将事物分解为数据和行为，则可以将最佳数据工具（RDBMS）应用于数据，并将最佳行为工具应用于行为。比较优势。 OO倾向于混合它们，将它们拖到最低的公分母。例如，数据模式（名词关系）作为数据库模式非常紧凑，但如果分散在应用程序代码中则不是这样。
    OO强迫人们过多地思考“持久性”。在以数据库为中心的方法中，持久性几乎是使用数据库的自动副产品。 （但是，有些数据库不能很好地支持临时表。）但是在OO中，你经常被迫考虑何时何地将内容“保存”到磁盘上，使设计复杂化。现代缓存技术允许数据库自动使用RAM或磁盘，而无需开发人员选择或担心它。 OO还学会了利用这种技术。
    那太慢了。
    请参阅上面的速度评论[EditHint：也许移动这些内容并在下面回复以保持主列表整洁]
    结构化程序仍然需要与DBAM交谈，并且有人必须构建DBAM。 OO没有做出任何不同的事情。对象方法中的DB访问代码看起来就像子例程中的相应代码。
    OO（据称）擅长构建内部DBMS引擎并不一定意味着它在所有其他领域都很擅长。 （请参阅OopNotForDomainModeling。）
    数据和行为的高度集成减少了协议和数据的跨语言共享。 （CrossToolTypeAndObjectSharing）
    由于大多数企业在RDBMS中存储属性，因此在复杂性和速度方面，OO和RDBMS之间通常存在“范例转换税”。
    OO不提供任何类型的CollectionOrientedProgramming快捷方式。例如，通常需要大量代码来迭代或获取有关主类的每个子类的摘要信息。有些人觉得这些东西应该被建成一种自称为“现代范式”或语言的东西。但封装似乎不允许它来自OO。请参阅RelationalBreaksEncapsulation附近的底部。 [也许将此项目与“缺乏标准化收集处理”合并]
    OOP出于某种原因是一个非常富有成效的“时尚工厂”。它会产生各种流行语和不明确的概念，鼓励每个人使用，但是为什么，何时以及如何定义不明确。这包括模式，SOA，责任驱动设计，MVC等。
    OO不适合编写应用程序代码。 OO倾向于关注重用，概念模型的稳定性和依赖性的最小化。这些方面对应用程序代码不是很有用。有充分的理由使用OO编写可重用的平台或库。但是，OO已经出售和广告用于各种目的，通常远远超出可以应用的实际范围。也许这可以在WhenToUseWhatParadigm中扩展。
    OO是反声明的 - OO倾向于将事物视为围绕国家的行为包装。这违反了属性驱动编程和/或规范的想法。可以创建OO框架，这些框架主要是对属性的赋值，但这实际上将其转换为各种类型的数据库，但没有数据库的查询能力。
    对于单点和单次使用，OOP可能是太多的设置代码。并非每一段代码都适用于通用套件或工具，但通常非常特定于域并且特定于任务。有关更多信息，请参阅ComparingDynamicVariables和YagNi。
    请参阅下面的OOP据称违反OnceAndOnlyOnce的方式列表。

    Two themes tend to stand out: artificialness and inconsistency. OO is based on some ideas that are catchy on a small scale or in toy examples, but they don’t scale to the real world well, requiring many layers of indirection to work around their limits. Lack of consistency makes it harder to understand and navigate OO designs and study OO in general. Every OO modeler ends up modeling their own head, so you have to learn a new head from scratch each time you encounter a new OO application.
    A proposed remedy for the above points is a UnifiedDataModel to create a true DataEcosystem.
    Oh, there are a lot of different proposed remedies. Perhaps we need a section to list them.
    Ways in which OO allegedly violates OnceAndOnlyOnce:
    Puts similar-looking behavioral wrappers around attributes, such as accessors.
    Does not factor out similarities in CollectionOrientedVerbs-ish aspects of interfaces (InterfaceFactoring).
    Often echos relationships that are already stored in a database. See CantEncapsulateLinks, MirrorModel.
    Repeats attributes over and over un-necessarily compared to table versions of multiple dispatch, such as the VisitorPattern. See CodeGenerationIsaDesignSmell near PageAnchor “attribute_repeat”, and DoubleDispatchExample.
    Quotes
    Quotes and articles about the harmfulness of OO: http://harmful.cat-v.org/software/OO_programming/
    A quote from a blog that is not directly about OOP, but makes a reference to it. Source: http://www.joelonsoftware.com/articles/APIWar.html
    “A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it’s not really the productivity booster that was promised.”
    Nice quote, but as an argument against OOP, it’s a classic ArgumentFromAuthority.
    Nothing wrong with that. ArgumentFromAuthority is valid evidence for the real world, but weak evidence.
    Yes there is something wrong with it. It’s not evidence at all, even though it’s being used as if it was evidence.
    I disagree, but this topic is probably not the best place to discuss that. Tell me that you’ve never asked a friend for recommendations.
    Of course I’ve asked friends for advice. However, advice is not evidence, so I don’t see how that is relevant.
    It depends on the context and/or community and/or forum. I’d prefer to let the reader decide which kind of evidence they want to keep or ignore rather than a self-elected filterer.
    While it may depend on context, it does not depend on community. While a given community might be willing to treat it as evidence, that community would be committing a fallacy each time it does so. And I am letting the reader decide, I haven’t deleted your contributions have I? Keep in mind, that I have just as much right to point out your illogical arguments as you have to make them.
    Yes, it’s committing a “fallacy” based on commonly-accepted formal debate rules. But those rules themselves are ArgumentFromAuthority.
    Even if it were just based on commonly accepted debate rules (which it isn’t, it’s based on the fact that it’s an unsound argument), it still wouldn’t be an ArgumentFromAuthority since no authority has been invoked.
    So the formal debate rules are not tied to anything? That’s not an improvement. And who said this wiki “must” conform to formal debate rules anyhow? Nevermind, I don’t want to argue about arguing anymore. That’s what wives are for.
    “It’s based on the fact that it’s an unsound argument” is “not tied to anything”? And I, too, don’t think that wiki needs to conform to formal debate rules. (Do you really want to wait till we have judges before we argue, and have only limited amount of time to form a response?). But even outside of formal debate, a fallacy is still a fallacy.
    A fallacy is only a “fallacy” against a standard. If you are not clear on the reference standard, it generally comes across as confrontational (although, I suspect you wear that as a badge of honor).
    {A “fallacy” is any form of argument that is misleading, i.e. where extrapolation leads one to bad conclusions. It doesn’t matter whether the conclusion is true or not. I.e. “the sky is blue because Alan Kay says so” is a fallacy, not because the sky isn’t blue, but because the argument itself suggests things are true merely because Alan Kay says them. Are you using some other standard for “fallacy”?}
    两个主题往往脱颖而出：虚假和不一致。 OO基于一些在小规模或玩具示例中引人注目的想法，但它们不能很好地扩展到现实世界，需要多层间接工作来绕其极限工作。缺乏一致性使得更难理解和导航OO设计并总体上研究OO。每个OO建模师最终都会为自己的头部建模，因此每次遇到新的OO应用程序时都必须从头开始学习新的头部。
    针对以上几点提出的补救措施是使用UnifiedDataModel来创建真正的DataEcosystem。
    哦，有很多不同的建议补救措施。也许我们需要一个部分来列出它们。
    OO涉嫌违反OnceAndOnlyOnce的方式：
    在属性（如访问器）周围放置类似外观的行为包装器。
    不会在接口的CollectionOrientedVerbs-ish方面（InterfaceFactoring）中分解出相似之处。
    通常是已存储在数据库中的回声关系。请参见CantEncapsulateLinks，MirrorModel。
    与多个调度的表版本（例如VisitorPattern）相比，重复使用重复属性。请参阅PageAnchor“attribute_repeat”附近的CodeGenerationIsaDesignSmell和DoubleDispatchExample。
    行情
    关于面向对象的危害性的行情和文章：http：//harmful.cat-v.org/software/OO_programming/
    来自博客的引用不是直接关于OOP，而是引用它。资料来源：http：//www.joelonsoftware.com/articles/APIWar.html
    “我们很多人在20世纪90年代都认为，在程序编程和面向对象编程之间会有一场大战，我们认为面向对象编程会大大提高程序员的工作效率。我也这么认为。有些人仍然认为。事实证明我们错了。面向对象编程很方便，但实际上并不是承诺的生产力助推器。“
    好的引用，但作为反对OOP的论据，它是一个经典的ArgumentFromAuthority。
    没有错。 ArgumentFromAuthority是现实世界的有效证据，但证据不足。
    是的，它有问题。这根本不是证据，即使它被用作证据。
    我不同意，但这个话题可能不是讨论这个问题的最佳场所。告诉我你从未向朋友询问过推荐。
    当然我已经向朋友们征求意见了。但是，建议不是证据，所以我不明白这是如何相关的。
    这取决于背景和/或社区和/或论坛。我宁愿让读者决定他们想要保留或忽视哪种证据，而不是自选的过滤器。
    虽然它可能取决于背景，但它不依赖于社区。虽然某个社区可能愿意将其视为证据，但该社区每次都会犯下谬误。我让读者决定，我还没有删除你的贡献吗？请记住，我有权利指出你不必要的不合逻辑的论点。
    是的，这是基于普遍接受的正式辩论规则的“谬误”。但这些规则本身就是ArgumentFromAuthority。
    即使它只是基于普遍接受的辩论规则（它不是，它基于这是一个不合理的论点这一事实），它仍然不会是ArgumentFromAuthority，因为没有调用任何权限。
    那么正式的辩论规则与任何事情无关？这不是一个改进。谁说这个维基“必须”符合正式辩论规则无论如何？没关系，我不想争论争论了。这就是妻子的意思。
    “这是基于这样一个事实：这是一个不合理的论点”“与任何事情无关”？我也不认为维基需要遵守正式的辩论规则。 （在你争论之前，你真的想等到我们有法官，并且只有有限的时间来形成回应吗？）。但即使在正式辩论之外，谬误仍然是一种谬论。
    谬误只是违背标准的“谬误”。如果你不清楚参考标准，它通常会出现对抗（虽然，我怀疑你把它当作荣誉徽章）。
    {“谬误”是任何形式的误导性论证，即推断导致一个不好的结论。结论是否正确无关紧要。即“天空是蓝色的，因为艾伦凯这么说”是一个谬论，不是因为天空不是蓝色，而是因为论证本身表明事情只是因为艾伦凯说他们。你是否正在使用其他标准的“谬误”？}

    “Conversation mode” generally is going to have unstated assumptions, overgeneralizations, and incomplete info. If you shout “fallacy! fallacy!” all the time during that, then you will be lumped with the jesus-shouters on the street corner. This is not court. It’s better to ask for clarification or give an example that “breaks” a statement as written.
    None of those describe the base situation here. You posted a quote, that is someone’s opinion, as an argument against OOP. There’s nothing to clarify as the quote was perfectly clear. Requiring a counter-proof (which is what “giving an example that ‘breaks’ the statement” is) is not required, shouldn’t be required, and in this case would be quite difficult to obtain. Simply pointing out the flaw in the argument is sufficient. I don’t go out of my way to offend people, but if you’re offended by having the flaws in your argument pointed out, then I’m afraid you’re just going to have to be offended. (By the way, I’ve stated the reference standard twice now. I really doubt I could make it any clearer by repeating it a third time).
    Well, I disagree it is an objective “flaw”, as already stated. Too many people think things are “objective” when they are not. If you wish to produce a formal proof that it’s objectively flawed, please do, but not in this topic.
    {You tend to call things “subjective” when they are not. That’s just you railing against the English language. A fallacy isn’t subjectively an invalid form of reasoning: there is no such thing as a form of reasoning that’s sound/valid for Top but unsound/invalid for someone else - that is, where validity and soundness depends upon which subject is performing the reasoning. That said, I suspect your goal isn’t to argue so much that ArgumentFromAuthority is sound/valid so much as to say that expert opinions have a place in a discussion such as this one - not as arguments, but rather in their capacity as (supposedly) informed opinions. Smoke is circumstantial evidence of fire. Negative opinions about OOP serve, similarly, as evidence that there are some flaws - not necessarily fundamental to OOP, but perhaps common among its popular implementations. Problem is, if this was your intent, you worded it poorly when you said: “ArgumentFromAuthority is valid evidence”; you should have said instead that “ExpertOpinion (opinions formed in professional capacity by people with experience and information) can serve as strong circumstantial evidence.”}
    I agree I worded it poorly. I’m sorry. -t
    While I agree that expert opinions have some place, I’m not sure that blog quotes really count as that either. I’d also probably cut you some more slack if you hadn’t also argued that references to published technical works didn’t count as evidence. (From BookStop, “A BookStop is not accepted in formal debating either. It would be considered ArgumentFromAuthority.”)
    {Those are very reasonable points. And I’d say that blog quotes from an article from an expert that expresses and justifies an opinion would qualify as expert opinion, and I’d even grant that Joel is a reasonably well-informed expert. But the above quote from JoelSpolsky is not from an article focusing upon expressing and justifying an opinion on OOP. It mentions OOP in passing only to suggest OOP has not been as significant to ‘productivity’ as GarbageCollection.}
    An expert on what? From what I’ve been able to determine, his opinions carry the same amount of weight that any senior developers would. I’ll listen, and take what he says seriously, but I’ll do my own research to back it up. I certainly won’t take something he says as true without some verification. For example, his September 23, 2009 blog entry was very troublesome (I’d say my single biggest time waster is dealing with the code left behind by “Duct-tape programmers”. Yes, sometimes you have to do it, but trying to claim it’s a good thing?)
    I don’t see how the main topic affects the value of statements made about OOP. True, it makes the link less valuable for the topic, but not the quote itself. But does that itself somehow ding it down below a threshold of some kind?
    {An “expert opinion” means more than mere “opinion”. It’s an opinion made in professional capacity, informed by the available facts, and subject to request for justification. Joel’s article makes no attempt to justify or explain this quote about OOP. That does, indeed, make the quote itself far less valuable. Pulling a quote out of context isn’t a praiseworthy act, either.}
    I disagree with both of these assertions. About the context, the quote is not misleading by virtual of it being isolated. Thus, I see no sin.
    {I see. TopMind thinks that off-hand comments carry the same weight as expert opinions, and that quoting people out of context is neither misleading nor a sin. Mind if I quote you on that in ObjectiveEvidenceAgainstTopDiscussion?}
    “对话模式”通常会有未说明的假设，过度概括和不完整的信息。如果你喊“谬论！谬误！”在那段时间里，你将会在街角与耶稣大厦混在一起。这不是法庭。最好要求澄清或举例说明“打破”陈述的陈述。
    这些都没有描述这里的基本情况。你发布了一个引用，这是某人的意见，作为反对OOP的论据。没有什么可以澄清的，因为引用非常明确。要求反证明（这是“给出一个’打破’陈述’的例子”不是必需的，不应该被要求，并且在这种情况下将很难获得。简单地指出论证中的缺陷就足够了。我不会冒险冒犯别人，但如果你因为你的论点中的缺陷而被冒犯，那么我担心你只会被冒犯。 （顺便说一下，我现在已经两次说过参考标准。我真的怀疑我可以通过第三次重复它来使它更清晰）。
    好吧，我不同意这是一个客观的“缺陷”，正如已经说过的那样。太多人认为事情是“客观的”，当他们不是。如果您希望提供一个客观存在缺陷的正式证据，请执行此操作，但不能在此主题中进行。
    {当你不这样做时，你倾向于把事情称为“主观的”。那只是你对英语的抨击。谬误在主观上不是一种无效的推理形式：没有一种推理形式对于Top而言是合理的/有效的但对其他人来说是不健全/无效的 - 也就是说，有效性和健全性取决于哪个主体正在执行推理。也就是说，我怀疑你的目标不是争论太多，以至于ArgumentFromAuthority是合理/有效的，以至于专家意见在这样的讨论中占有一席之地 - 不是作为论据，而是作为（据说是知情的意见。烟雾是火灾的间接证据。类似地，关于OOP的负面观点也表明存在一些缺陷 - 不一定是OOP的基础，但在其流行的实现中可能很常见。问题是，如果这是你的意图，当你说：“ArgumentFromAuthority是有效的证据”时，你的措辞很差;你应该说“专家意见”（由具有经验和信息的人以专业身份形成的意见）可以作为强有力的间接证据。“}
    我同意我措辞不好。对不起。 -t
    虽然我同意专家意见有一些地方，但我不确定博客引用是否也算得上。如果你还没有认为对已发表的技术作品的引用不算作证据，我也可能会让你更加松懈。 （来自BookStop，“正式辩论中也不接受BookStop。它将被视为ArgumentFromAuthority。”）
    {这些是非常合理的。而且我会说博客引用来自专家的一篇文章，该文章表达并证明了一个意见是合格的专家意见，我甚至认为乔尔是一个相当知情的专家。但JoelSpolsky的上述引用并非来自一篇专注于表达和证明OOP意见的文章。它提到OOP仅仅表明OOP并不像GarbageCollection那样对“生产力”有重要意义。}
    什么专家？根据我的判断，他的意见与任何高级开发人员相同。我会听，并认真对待他说的话，但我会做自己的研究来支持它。如果没有一些验证，我当然不会接受他说的那样的话。例如，他2009年9月23日的博客文章非常麻烦（我说我最大的时间浪费在处理“管道磁带程序员”留下的代码。是的，有时你必须这样做，但试图声称这是件好事？）
    我没有看到主题如何影响关于OOP的陈述的价值。没错，它会使链接对主题的价值降低，但不会使引用本身。但是，它本身是否会以某种方式将其降低到某种阈值以下？
    {“专家意见”不仅仅意味着“意见”。这是一种以专业身份提出的意见，由现有事实提供信息，并要求提供理由。乔尔的文章没有试图证明或解释有关OOP的这句话。事实上，这确实使得报价本身的价值更低。将报价脱离背景也不是值得称赞的行为。}
    我不同意这两个断言。关于上下文，引用并不是因为虚拟被隔离而误导。因此，我认为没有罪。
    {我懂了。 TopMind认为，副手评论的重要性与专家意见相同，引用人们脱离背景既不会误导也不会犯罪。请注意，如果我在客观证据中反对热门话题引用你的话？}

    The paraphrasing is inaccurate, or at least misleading. Anyhow, I ran out of patience to argue about arguing here, and will thus let it sit for now. -t
    EditHint: Spin this section off into a topic related to ArgumentFromAuthority.
    The first half seems accurate enough. When it suits your purposes, you’ll promote using the off-hand comments while also trying to dismiss published studies. The second half seems a bit unfair. Neither quote on this page lost it’s meaning when you quoted them. And I can’t think of any time where you clearly misquoted someone.
    What published studies with source code showing OOP better?
    Who said anything about “published studies with source code showing OOP better”? I would be rather surprised if such a thing existed because in order to show something “better” in a study, one usually has to cover a much wider variety of code than one could reasonably include (as in actually put in the paper) in the study. But this just reinforces my point. You are already attempting to dismiss published studies by placing unreasonable requirements for acceptance.
    Could somebody please clarify the statement “while also trying to dismiss published studies”. And please stop deleting this question until it is fully answered. Thank You. -t
    I deleted the line the led from “existing published studies”, since that line was a result of a mistake. And, I meant that you have argued that certain forms of evidence (which include published studies), shouldn’t be used. The quote I included earlier is one instance. The SelfStandingEvidence page is another.
    I don’t see such. Please use PageAnchors to reference such studies. If I try to guess what you are referring to, it’ll probably lead to yet another fat argument about nothing.
    I’m not talking about any particular study, so there wouldn’t be anything to put in a PageAnchor. As for not seeing it, the very opening of SelfStandingEvidence (“Self-standing evidence is the opposite of ArgumentFromAuthority. Such evidence is self-contained and does not require or assume other sources except maybe a basic domain dictionary.”) would (if accepted) preclude references to published studies, as the study is an “other source” orther than a “basic domain dictionary”.
    How it relates to this topic, I have no idea. Not sure I want to anymore. I never outright dismissed “published studies” either, for that matter. -t
    {Why do you infer that “formal debate rules are not tied to ‘anything’” from “formal debate rules are not tied to ‘authority’”? That seems rather daft and illogical to me. And maybe you’re right: this wiki shouldn’t conform to debate rules; instead, we should give wiki-space and consideration to all opinions, without any rules to point at to claim some opinions unreasonable or unprofessional and thus deserving of dismissal and deletion. On that note: OOP and procedural are both bad because they haven’t been touched by the FlyingSpaghettiMonster’s noodly appendage. SpaghettiCode, on the other hand, is good because it’s very noodly. This must surely be given some weight in ArgumentsAgainstOop, right?}
    Again, I’ll let the reader decide how they weigh the elements.
    [Why does OOP inspire such fervour in you?]
    May I ask if this relates to the immediate topic above, or is this a “new” question?
    [This is a “new” question. On a case-by-case basis, I can certainly appreciate choosing an alternative to OOP based on some mathematical, logical, or business rationale or the result of a cost-benefit analysis. However, on a number of Wiki pages you appear to react to it on an emotional level. Why is this? Perhaps a new page would be appropriate to discuss this, such as WhyOopMakesTopMad, or some such?]
    Debunking OOP hype is a hobby of mine. The hype mucked up some of my favorite tools and trends, so I set out to make the hypsters more accountable for their claims. -t
    [Ok, but why react emotionally? Why not simply illustrate how your favourite tools and trends are/were superior (or at least equivalent) using some well-defined metrics?]
    Where did I act overly emotional? And, I feel that software engineering is mostly about psychology, not universal principles of nature outside of humans (as individuals and as a group). Thus, objective metrics of the kind we find in other fields generally don’t exist. See DisciplineEnvy and PsychologyMatters for more. OOP proponents often make statements that imply objectivity, such as “OOP increases modularity”. But they cannot deliver the evidence in an objective way. If they said, “it personally helps my mental modularity (MentalIndexability)”, then I don’t have an argument. It’s the implied extrapolation to all beings that makes me sit up.
    这种释义是不准确的，或者至少是误导性的。无论如何，我没有耐心争论在这里争论，因此现在就让它坐下来。 -t
    EditHint：将此部分转移到与ArgumentFromAuthority相关的主题中。
    上半场似乎足够准确。如果它适合您的目的，您将推广使用副手评论，同时也试图驳回已发表的研究。下半场似乎有点不公平。当你引用它们时，这个页面上的引用都没有丢失它的含义。我无法想到你明显错误引用某人的任何时候。
    哪些已发表的研究与源代码显示OOP更好？
    谁说过“有关源代码显示OOP更好的已发表研究”？如果存在这样的事情，我会感到非常惊讶，因为为了在研究中表现出“更好”的东西，人们通常必须涵盖范围更广泛的代码，而不是合理地包括（如实际上放在论文中）研究。但这只是强调了我的观点。您已经尝试通过提出不合理的接受要求来解雇已发表的研究。
    有人可以澄清声明“同时也试图驳回已发表的研究”。并且请在完全回答之前停止删除此问题。谢谢。 -t
    我从“现有已发表的研究”中删除了该行，因为该行是错误的结果。并且，我的意思是你认为不应该使用某些形式的证据（包括已发表的研究）。我之前包含的引用是一个实例。 SelfStandingEvidence页面是另一个页面。
    我没有看到这样的。请使用PageAnchors参考此类研究。如果我试着猜测你所指的是什么，它可能会引发另一个关于什么都没有的肥胖论点。
    我不是在谈论任何特定的研究，所以不会有任何东西放在PageAnchor中。至于没有看到它，SelfStandingEvidence的开头（“自立证据与ArgumentFromAuthority相反。这些证据是自包含的，不需要或假设其他来源，除了可能是基本的域名词典。”）会（如果被接受） ）排除对已发表研究的参考，因为该研究是“其他来源”，而不是“基本领域词典”。
    它与这个话题有什么关系，我不知道。不确定我想要了。就此而言，我从未完全驳回“已发表的研究”。 -t
    {为什么你推断“正式的辩论规则与”任何事情“没有关联”“正式辩论规则与’权威’无关”？这对我来说似乎相当愚蠢和不合逻辑。也许你是对的：这个维基不应该符合辩论规则;相反，我们应该给予维基空间并考虑所有意见，没有任何规则指出一些不合理或不专业的意见，因此应该被解雇和删除。在那个问题上：OOP和程序都很糟糕，因为FlyingSpaghettiMonster的附属物没有触及它们。另一方面，SpaghettiCode很好，因为它非常好。这肯定会在ArgumentsAgainstOop中给予一定的权重，对吧？}
    同样，我会让读者决定他们如何衡量元素。
    [为什么OOP会激发你的热情？]
    请问这是否与上述直接主题有关，还是这是一个“新”问题？
    [这是一个“新”问题。根据具体情况，我当然可以根据一些数学，逻辑或商业原理或成本效益分析的结果来选择OOP的替代方案。但是，在许多Wiki页面上，您似乎会在情感层面上对此作出反应。为什么是这样？也许一个新的页面适合讨论这个，比如WhyOopMakesTopMad，或者其他一些？
    揭穿OOP炒作是我的一个爱好。炒作混淆了我最喜欢的一些工具和趋势，所以我开始让这些主持人对他们的主张更负责。 -t
    [好吧，但为什么情绪反应？为什么不使用一些明确定义的指标简单地说明您最喜欢的工具和趋势是如何优越（或至少相当）？
    我在哪里表现得过于情绪化？而且，我觉得软件工程主要是关于心理学，而不是人类以外的普遍自然原则（作为个体和团体）。因此，我们在其他领域中找到的那种客观指标通常不存在。有关更多信息，请参阅DisciplineEnvy和PsychologyMatters。 OOP的支持者经常发表暗示客观性的陈述，例如“OOP增加模块性”。但他们无法以客观的方式提供证据。如果他们说，“它个人帮助我的心理模块性（MentalIndexability）”，那么我没有争论。这是对所有生物的隐含推断让我坐起来。

    {Your “feelings” about psychology are “overly emotional” already. You have faith that PsychologyMatters, but you don’t believe any objective evidence is required to make this view a reasonable or convincing one. Your belief system is anti-science, anti-reasoning, anti-intellectual… you might as well start a religion. Without any objective assertions, you can’t disprove PsychologyMatters any more than you could disprove ReligionMatters in software engineering. OOP proponents, at least, use logic to demonstrate certain forms of runtime-ConfigurableModularity that do not exist without the relevant OOP techniques (fundamentally: binding behavior to references polymorphically). You seem to ignore evidence that doesn’t come with ‘numbers’, but that’s because you blindly ignore that formal proof is at the very top of the EvidenceTotemPole. Of course, OOP techniques - binding behavior to references - can be implemented in any TuringComplete system (and even many not-TuringComplete systems), rather than just OOPLs. Appealing to that doesn’t change the relevant facts; it only says that you can do OOP without a dedicated syntax via a framework and SelfDiscipline. Anyhow, if you’re going to say something “personally helps my MentalIndexability”, then you should be able to prove it in a psychology lab - i.e. performing recall and recognition and access time tests. And if you’re going to claim some psychology benefit is “nature” (as opposed to “nurture”), then you had damn well better be able to provide convincing evidence for it - which means controlling for education and experience.}
    I am not “anti-science”. I am just realistic about where (traditional) science can’t work (TooManyVariablesForScience).
    {You hold views based on faith. If you were “just realistic”, then you would not say that PsychologyMatters. You’d make no assertions based on faith! Being “just realistic” also means skepticism about where psychology would ‘matter’. Instead you’d “just” say that you are skeptical of the virtue of science in SoftwareEngineering decisions. You might also say: “As a realist, I can’t argue that PsychologyMatters… but, as a human, I do favor some aesthetic elements of programs.” By calling yourself a realist alongside your professed beliefs, you’re speaking obvious untruths to the world, and I suspect you’re lying most of all to yourself.}
    And you’ve opened too many cans of worms to address in a single paragraph. I suggest we find a more appropriate topic for each rather than create another ThreadMess here. If you have some objective evidence for OOP, perhaps it deserves its own topic. And if we design software based on only what we can scientifically measure, then we risk SovietShoeFactoryPrinciple. Our economy does not depend on micromanaging decision calculations, so why should complex software? -t
    {More fallacies, TopMind? This time: FalseDichotomy and FalseAnalogy.}
    Yes yes, I always say bad and wrong stuff because I am bad and wrong and purposely set out to be bad and wrong. Antagonistic Jerk!
    {I consider sophistry a banning-worthy offense. It is very offensive. I consider barging into a conversation and inflicting your ignorance upon the audience to be less offensive, but hardly endearing. So: it doesn’t matter whether you do it on purpose; either way, you earn chastisement.}
    I have similar views about you, but don’t believe that insults “fix” people unless done right (which I doubt you have the people skills to do, being the Asberger type). If I insult, its purely to relieve my stress, not to fix. (And “sophistry” is yet another one of those vague insult words you like so much.)
    {(A) Designing software based on what we can deduce and measure doesn’t mean designing software based only on what we can deduce and measure (FalseDichotomy). (B) Our economy is not a piece of technology, and we have very little opportunity to ‘design’ it - the economy is very subject to political pressures outside of any potential designer’s control (FalseAnalogy).}
    And software is not subject to political pressure outside of designer’s control? As a software designer, a very large part is usually outside of my control unless it’s say a personal open source project. I won’t claim my statement 100% fallacy-free, but that is not one of them. Also note that an imperfect analogy is not the same as a useless analogy. Don’t force Boolean onto non-Boolean concepts.
    {That depends on the size of the ‘software’ unit and whether you consider requirements to be part of the software or not. But it remains that technology implementation is in the hands of a few designers - an individual architect or a small group - and nothing similar can be said of the economy.}
    {你对心理学的“感受”已经“过于情绪化”了。你相信心理学有所作为，但你不相信需要任何客观证据来使这种观点成为合理或令人信服的观点。你的信仰体系是反科学的，反推理的，反知识的……你也可以开始一个宗教。没有任何客观断言，你不能反驳心理学数据，而不是在软件工程中反驳宗教信徒。 OOP的支持者至少使用逻辑来演示某些形式的运行时 - ConfigurableModularity，这些形式在没有相关OOP技术的情况下是不存在的（从根本上说：多态地将引用绑定到引用）。你似乎忽略了没有“数字”的证据，但这是因为你盲目地忽略了形式证据就在EvidenceTotemPole的最顶层。当然，OOP技术 - 对引用的绑定行为 - 可以在任何TuringComplete系统（甚至许多非-TuringComplete系统）中实现，而不仅仅是OOPL。对此提出上诉并不会改变相关事实;它只表示你可以通过框架和SelfDiscipline在没有专用语法的情况下进行OOP。无论如何，如果你要说“亲自帮助我的MentalIndexability”，那么你应该能够在心理学实验室证明它 - 即进行回忆和识别以及访问时间测试。如果你要声称一些心理学的好处是“自然”（而不是“培育”），那么你最好能够为它提供令人信服的证据 - 这意味着控制教育和经验。}
    我不是“反科学”。关于哪里（传统）科学无法运作，我很现实（TooManyVariablesForScience）。
    {你持有基于信仰的观点。如果你“只是现实”，那么你就不会说那是心理学的。你不会根据信仰做出任何断言！ “正当现实”也意味着对心理学“重要”的怀疑态度。相反，你只是“说”你对SoftwareEngineering决策中的科学美德持怀疑态度。你可能也会说：“作为一个现实主义者，我不能争辩说心理学博士……但是，作为一个人，我更喜欢一些程序的美学元素。”通过将自己称为现实主义者和你自称的信仰，你对世界说出了明显的不实之词，我怀疑你最重要的是对自己撒谎。}
    你已经打开了太多的蠕虫来解决一个段落。我建议我们为每个主题找到一个更合适的主题，而不是在这里创建另一个ThreadMess。如果你有一些OOP的客观证据，也许它值得拥有自己的话题。如果我们仅基于我们可以科学测量的东西来设计软件，那么我们就冒着苏联风险原则的风险。我们的经济不依赖于微观管理决策计算，为什么要复杂的软件呢？ -t
    {更多谬论，TopMind？这一次：错误的二分法和虚假的法律。}
    是的，我总是说错误和错误的东西，因为我是坏的，故意的，故意是坏事和错误。对抗的混蛋！
    {我认为诡辩是一种禁止犯罪的罪行。这是非常令人反感的。我考虑闯入谈话并使你对观众的无知变得不那么冒犯，但几乎不可爱。那么：你是否故意这样做并不重要;无论哪种方式，你都会受到惩罚。}
    我对你有类似的看法，但不要相信侮辱“修复”人，除非做得对（我怀疑你有人的技能，做Asberger类型）。如果我侮辱，它纯粹是为了减轻我的压力，而不是为了解决。 （而“诡辩”是你非常喜欢的另一个模糊的侮辱词。）
    {（A）基于我们可以推断和测量的内容来设计软件并不意味着仅根据我们可以推导和测量的内容设计软件（FalseDichotomy）。 （B）我们的经济不是一项技术，我们很少有机会“设计”它 - 经济很可能受到任何潜在设计师控制之外的政治压力（FalseAnalogy）。}
    软件不受设计师控制之外的政治压力？作为一名软件设计师，除非是个人开源项目，否则很大一部分通常不在我的控制之内。我不会声称我的声明100％无谬误，但这不是其中之一。还要注意，不完美的类比与无用的类比不同。不要将布尔值强制转换为非布尔概念。
    {这取决于’软件’单元的大小，以及您是否认为要求是软件的一部分。但是，技术实施仍然掌握在少数设计师手中 - 一个独立的建筑师或一个小团体 - 对经济而言，没有类似的说法。}

    As software designers, we have to weigh boat-loads of factors, some which we have full control over, some we have some control over, and some we have no control over. These must all be weighed and acted upon. Software is a system, and the economy is a system. Whether we call it “technology” or not is mostly a name-game. Software can be ran entirely manually if one has the patience. The computer is not necessary.
    {Sure, there are many factors, some of which are more controllable (easy to predict and adjust) than others. That’s a common property for “engineering”. SoftwareEngineering, in that sense, is far more similar to bridge and architectural engineering than it is to the economy. There are very few factors of the economy that individuals have even ‘some’ control over.}
    I dissagree with the bridge analogy. Physics is the primary force bridge engineers are up against and it generally doesn’t change; but psychology is the primary force that SE’s are up against (machine performance being the 2nd.) There’s already a long topic on that and I’ll link to it when found. -t
    {I think your disagreement flawed. First, you fell back on faith that PsychologyMatters, despite it being in dispute, without any evidence whatsoever - that’s what we call HandWaving. Second, aesthetics matter to bridge and architecture design, too. Third, the primary forces that SE’s are up against are typically the same forces that bridge designers are up against: limited time, limited budget, requirements to interface/integrate with the outside world, and a wide number of implementation strategies to decide between.}
    The default is not that psychology doesn’t matter. Most rational people will agree that the open issue is “how much”. As far as the bridge analogy, I’ll withhold commenting until I find the related topic.
    (Moved further discussion to LinusTorvaldsOnVisualBasic)
    Binding Behavior to References (BBR)
    [sub-topic being refactored]
    Of course, OOP techniques - binding behavior to references - can be implemented in any TuringComplete system (and even many not-TuringComplete systems), rather than just OOPLs. Appealing to that doesn’t change the relevant facts; it only says that you can do OOP without a dedicated syntax via a framework and SelfDiscipline.
    And binding behavior to references existed long before OOP. If anything, later languages limited the binding to supply “discipline” above machine/assembler address pointer spaghetti.
    What? Do you mean before it was called OOP? Because many people would argue that early use of OOP techniques began with binding behavior to references. And what any ‘language’ or ‘syntax’ does is provide some discipline to remove need for SelfDiscipline. But ‘BBR’ was listed as a ‘technique’ and not a definition of OOP; the above should have read “OOP techniques - such as binding behavior to references - […]”. OOP means having references to program elements (NygaardClassification), having behavior (including access to state) associated (polymorphically) with these references (rather than injected by the holder of the reference), and the ability to communicate references.
    We both seem to agree that OOP at least attempted to introduce discipline to BBR. But this would imply that BBR is not by itself “OOP”. OOP is an approach to trying to tame BBR. The “problem” is managing them through navigational paths (OO) rather than relational and/or sets, not the mere existence. In other words, I don’t like the way OOP manages the references, but am not bothered by existence of them by itself (if used appropriately). -t
    Agreed. Related: the ‘no composer’ argument at the top. The need to “manage” references in OO is painful, and evil. I prefer my OO mixed with a healthy dose of FP + LogicProgramming + DataflowProgramming, along with an object-configuration builder to build large object configurations declaratively (no assignment operations, no managing order-of-operations). OOP has, without a doubt, many problems. That’s true for any single paradigm.
    (Moved rest of discussion to ScalingOopDiscussion.)
    See also OopArgumentsDebatesAndDiscussion, OoLacksConsistencyDiscussion, OopNotForDomainModeling
    CategoryOopDiscomfort, CategoryObjectOrientation
    SeptemberZeroNine
    Last edit May 17, 2013, See github about remodling.
    作为软件设计师，我们必须权衡大量因素，一些我们可以完全控制，一些我们有一些控制，一些我们无法控制。这些必须全部权衡并采取行动。软件是一个系统，经济是一个系统。我们是否称之为“技术”主要是名称游戏。如果有耐心，可以完全手动运行软件。电脑不是必需的。
    {当然，有许多因素，其中一些比其他因素更易控制（易于预测和调整）。这是“工程”的共同属性。从这个意义上说，软件工程与桥梁和建筑工程更相似，而不是经济。个人甚至“控制”的经济因素很少。}
    我不同意桥梁比喻。物理学是桥梁工程师面临的主要力量，它通常不会改变;但心理学是SE面临的主要力量（机器性能是第二位的。）已经有一个很长的话题，我会在找到它时链接到它。 -t
    {我认为你的分歧有缺陷。首先，你失去了相信心理学，尽管它存在争议，但没有任何证据 - 这就是我们所说的HandWaving。其次，美学对桥梁和建筑设计至关重要。第三，SE所面临的主要力量通常与桥梁设计师所反对的力量相同：时间有限，预算有限，与外部世界接口/整合的要求，以及由之间决定的大量实施策略。
    默认情况并非心理学无关紧要。大多数理性的人会同意公开的问题是“多少”。就桥梁类比而言，在发现相关主题之前，我将不做评论。
    （进一步讨论Linus Torvalds On VisualBasic）
    绑定行为与参考（BBR）
    [子主题被重构]
    当然，OOP技术 - 对引用的绑定行为 - 可以在任何TuringComplete系统（甚至许多非-TuringComplete系统）中实现，而不仅仅是OOPL。对此提出上诉并不会改变相关事实;它只表示你可以通过框架和SelfDiscipline在没有专用语法的情况下进行OOP。
    并且在OOP之前很久就存在对引用的绑定行为。如果有的话，以后的语言限制绑定提供机器/汇编程序地址指针意大利面上方的“纪律”。
    什么？你的意思是它被称为OOP吗？因为许多人会争辩说，早期使用OOP技术始于对引用的绑定行为。任何“语言”或“语法”的作用都是为了消除对SelfDiscipline的需求而提供一些纪律。但’BBR’被列为’技术’，而不是OOP的定义;以上内容应该是“OOP技术 - 例如对引用的绑定行为 - […]”。 OOP表示对程序元素（NygaardClassification）的引用，具有与这些引用相关联（多态）的行为（包括访问状态）（而不是由引用的持有者注入），以及传递引用的能力。
    我们似乎都同意OOP至少试图向BBR引入纪律。但这意味着BBR本身并不是“OOP”。 OOP是一种试图驯服BBR的方法。 “问题”是通过导航路径（OO）而不是关系和/或集合来管理它们，而不仅仅是存在。换句话说，我不喜欢OOP管理引用的方式，但不会因为它们本身的存在而烦恼（如果使用得当）。 -t
    同意。相关：顶部的’无作曲家’论点。在OO中“管理”引用的需要是痛苦的，也是邪恶的。我更喜欢我的OO与健康剂量的FP + LogicProgramming + DataflowProgramming以及对象配置构建器以声明方式构建大对象配置（没有赋值操作，没有管理操作顺序）。毫无疑问，OOP存在许多问题。任何单一范式都是如此。
    （将其余讨论转移到Scaling Oop Discussion。）
    另请参阅Oop参数争论和讨论，OoLacks一致性讨论，Oop不适用于域建模
    类别Oop不适，类别对象取向
    SeptemberZeroNine
    最后编辑2013年5月17日，请参阅github有关改造的信息。