将 99 瓶（OOP）扔进垃圾桶

在询问“Good OOP”示例时，很多人会推荐 99 瓶 OOP 书籍。我舍不得买。通过名称和描述，我可以看出它将使用“99 Bottles of Beer”歌曲作为某种示例……坦率地说，这似乎完全没有效果。但由于人们不断提到它——我明白了。不出所料，我是对的：这本书确实令人困惑，而且……不好。 TL;DR：即使作为 OOP 的直言不讳的批评者，我也可以看到这本书对任何可以称为合理的 OOP 的东西都造成了巨大的伤害。为自己节省 40 美元，不要购买。如果你拥有它，把它扔进垃圾桶。如果你读过它——知道你学到了一堆关于 OOP 的废话，也许还有一些关于构建代码和编写测试的小知识。我选择了本书的 Ruby 版本，因为我认为它是最面向 OOP 的。哈哈，傻傻的乐观我。在第一章中，作者对比了生成“99瓶啤酒”歌曲文本的程序的4个版本。它们实际上都是相同的，其中 3 个有点太聪明了，一个明显是简单的赢家。 class Bottles def verses(upper, lower) upper.downto(lower).map {|i| verse(i)}.join("\n") end def verse(number) case number when 0 "没有更多的啤酒瓶在墙上，" + "没有更多的啤酒瓶。\n" + "转到存储并购买更多，" + "99 瓶啤酒在墙上。\n" 当 1 "1 瓶啤酒在墙上时，" + "1 瓶啤酒。\n" + "把它拿下来并通过它周围，​​" + "墙上不再有啤酒瓶了。\n" 当 2 "2 瓶啤酒在墙上时，" + "2 瓶啤酒。\n" + "取下一个并传递给周围，" + "墙上有 1 瓶啤酒。\n" else "墙上有 #{number} 瓶啤酒，" + "#{number} 瓶啤酒。\n" + "取下一瓶并传给周围， " + "#{number-1} 瓶啤酒在墙上。\n" end endend 令我震惊的是这段代码（或它的任何其他版本）绝对没有任何面向对象的内容。此类不是任何有意义的 OOP 意义上的对象。它只是一段代码分解成两个函数。它也可能是一个纯 FP 程序或一个过程编程代码。它是如此微不足道，它无关紧要。作者用了整整一章的时间来讨论此代码的所有四个呈现版本之间的无关紧要的差异。

第 2 章是关于测试/TDD。那个琐碎的代码。我已经翻白眼，后悔在这本书上花了 40 美元。这并不是说写作不好或不聪明。只是考虑到被测试代码的琐碎和荒谬，整个练习变成了一种嘲弄，IMO。在第 3 章中，作者宣布他们将采用第 1 章中被认为最简单和最好的代码版本，并在其上做一些进一步的 OOP 工作。因为……多变！哈！这可能是这本书最 OOP 的地方：采用一些抽象的目标，比如“可维护性”、“可重用性”、“可变性”、“隔离”、“封装”，然后试图将所有东西都变成一团糟，试图实现它。用户要求您更改 99 Bottles 代码，以在当前显示“6 瓶”的每个地方输出“1 六瓶装”。愤世嫉俗和烦躁的我希望作者采用那个简单的版本，添加when 6 角落案例并完成它。但我确实意识到作者是想表达一个观点，需要一些理由再写 6 章。 6 章可怕的、被误导的、被误解的 OOP 屠杀，是一段有点天真和简单，但在其他方面却是善良和无辜的代码！与第 4 章一起归结为过度分析给这只猫剥皮的最佳方法。同样 - 它与 OOP 无关，只是增加了相当多的复杂性以支持一些任意的参数化要求。在这个过程中，作者以某种方式涉及到 Liskov 替换原则，尽管看不到接口或继承层次结构，但只有少数函数没有任何有意义的自我。在第 5 章中，作者发明了一个 BottleNumber 类，它只是包装数字并将条件逻辑放入其方法中。仍然看不到有意义的 OOP。 🤷 在第 6 章中，作者试图通过使用多态来引入开放性。当然。太糟糕了，它使用类 Number0、类 Number1、类 Number6 和类 BottleNumber 进行解释，并继承将它们粘合在一起。和一个工厂从一个数到一个给定的类。

我明白了——作者还会如何谈论多态性。但这完全是荒谬和令人困惑的。人们读了这些东西，认为这就是做事的方式，然后在软件商店中肆虐多年！这正是让我去反对 OOP 的那种狗屎。在第 7 章中，作者通过 self.inherited 钩子（我必须查找的 Ruby 特性）在工厂方法中注册自己的类。一个实际的例子，我猜。可能是。如果我不是那么反对这本书，不管怎样，OOP 作为一个整体。第 8 章和第 9 章是前几章不适合的内容的全部内容。在这一点上，我没有动力去浏览它们并用那里的一些东西描述我的问题，抱歉。我很确定 Elegant Objects 的作者（会/会）不喜欢 99 Bottles of OOP。尽管我不喜欢那本书，但它对 OOP 有某种形式的想法，并且似乎完全抱怨 99 Bottles 呈现的那种非真正的 OOP 实际过程代码。到目前为止，GOOS 是我读过的最好的 OOP 书，而 99 Bottles 是最差的。甚至 Elegant Objects 似乎更合理，这是一个相当低的标准，我必须告诉你。 Elegant Objects 只是一个相当武断的意见列表，作者无法提出任何论据来支持它们。但至少它似乎是关于 OOP 的一些想法。整个 99 Bottles 本质上被它必须使用的毫无意义的示例代码毁了。虽然我抱怨在 Growing Object Oriented Software 中忽略了数据持久性甚至完全忽略了数据模型，但至少它正在处理一些类似真实的代码，清楚地了解 OOP 是什么，而不是无意义的两功能软件漫画.无论如何，我希望我已经为您节省了 40 美元，甚至更多的是忘记这些东西所需的时间和精力。还是已经太晚了？