Makers Academy Bookclub:我们对Sandi Metz的POODR的看法(第2-5章)

我们非常高兴地认识了Makers Academy Bookclub的第三周。 我们期待着学习如何提高对面向对象编程的理解,并且我们都喜欢Sandi Metz的周到和清晰的风格来解释与Ruby有关的程序体系结构的困难概念:http://www.poodr.com/。 这本书的承诺是巨大的。 我们将学习如何确定单个类中的内容,避免纠缠应分开的对象,在对象之间定义灵活的接口,使用鸭子输入来减少编程开销,成功地应用继承,通过组合来构建对象,设计具有成本效益的测试并制作简单易懂的代码。 如果那是我们想要的结果的正确统称,我们将迅速成为福音布道者。

有太多的东西要学习和讨论,我们首先转向第2章和缩写TRUE。 这代表透明(描述各种类的依赖性并查看更改发生的位置),合理(识别时间和团队支出方面的编程成本以及在我们的限制范围内运行),可用(我们需要学习如何创建别人可以理解的代码,并且可以有效地经受住变更的影响)和示例性代码(我们希望我们的代码如此简单明了,以作为他人效仿的榜样)。

我们了解到的第一个重要提示是,我们可以创建称为structs的类的精简版本。 结构是在类中创建迷你类的一种轻量级方法:

这与模块不同,因为我们可以有它的实例,但是它使我们可以很清楚地了解依赖关系。 在wheelify方法内部隔离了所有有关传入数组结构的知识,该方法将Arrays数组转换为Structs数组。 因此,我们可以使用Structs来包装结构。

桑迪·梅斯(Sandi Metz)还帮助确定了何时做出设计决策。 我们可以推迟决策,并旨在抽象化每个类所要呈现的数据。 确定一个班级是否做得太多的一个很好的秘诀是与班级交谈并想象答案是什么。 我们需要识别依赖性并学习如何管理它们。

然后,我们继续进行鸭子打字。 正如Sandi Metz在其应用程序中关于Gear和Wheel类的说法:“齿轮需要访问可以响应直径的对象……Gear并不在乎,也不应该知道该对象的类。 为了计算gear_inches,Gear不必知道Wheel类的存在。 不需要知道Wheel会先使用轮辋然后再进行轮胎初始化; 它只需要一个知道直径的物体。”(Metz,POODR,41)。 这一点很重要,因为它提醒我们可以给课程提供一些信息,并决定我们要告诉他们多少信息。 我们注意到并记住,我们几乎需要减少类中的依赖,就像我们可以减少“外来”细菌一样。 我们的依赖关系必须“简洁,明确和孤立。” Sandi继续向我们展示了如何使用哈希作为类的参数,从而减少了对管理依赖关系方向的担心。 关于课堂的主要建议是:“依赖于变化少于您的事物。”(第53页)。

然后在第四章中,我们发现了一个重要的发现,即面向对象程序是:“由类组成,但由消息定义。” 类控制源代码存储库中的内容。 信息反映了生动活泼的应用程序。”(第59页)。 我们了解了公共接口和私有接口之间的区别:私有接口不稳定,而对公共方法的稳定性期望更高。 最后,我们学习了序列图,这是一种学习类相互发送的消息的便捷方法:

这些是了解类如何相互发送消息的有用方法,并提醒我们我们没有发送消息是因为我们有对象,但是有了对象却是因为我们发送了消息。 Sandi解释说,课堂旅行是Moe客户和Bike课堂之间的互动。 根据我对Oystercard和Takeaway等每周挑战的体验,我注意到有可能有一种“神类”充当所有其他类之间的接口,并且我也认识到这种接口可以采取依赖的形式设计类结构的方式是从高级模块到低级模块的反转。 因此,例如,在Oystercard中,我们有一个Oystercard类,该类与JourneyLog通信,然后与JourneyLog通信:

牡蛎卡===> JourneyLog ===> Journey

在JourneyLog中,我们需要创建一个抽象层,以将较高级别的类(Oystercard)与较低级别的类(Journey)分离。 这意味着对Journey类或Oystercard类所做的任何更改都不会相互影响,因为我们可以通过JourneyLog修改它们之间的交互。

我们在学习过程中以清晰的思路阐明了出色的代码结构和体系结构的可能性。 重读Sandi关于面向对象设计的深层问题的想法简直令人沮丧,我们期待在下一次会议上进一步探讨这些问题和其他问题。