我正在阅读 Code Complete(第 2 版),并在第 87 页的页边空白处看到了 Bertrand Meyer 的一句话。
不要先问系统做什么;问它有什么用!
迈耶先生试图在这里表达的究竟是什么。我有一些粗略的想法,但我想确保我真的理解。
我正在阅读 Code Complete(第 2 版),并在第 87 页的页边空白处看到了 Bertrand Meyer 的一句话。
不要先问系统做什么;问它有什么用!
迈耶先生试图在这里表达的究竟是什么。我有一些粗略的想法,但我想确保我真的理解。
......所以这是目的论的第二个谬误 - 将目标导向的行为归因于非目标导向的事物,甚至可能不认为事物是有生命的和精神居住的,但只有思考,X发生是为了Y. “为了”是一种精神主义语言,尽管它似乎没有像“恐惧”或“认为它可以飞”这样的明目张胆的精神属性命名。— Eliezer Yudkowsky,人工智能理论家,关注具有稳定目标系统的自我改进人工智能
Bertrand Meyer 的讲道表明,关于系统的合理推理基于了解系统改变了哪些具体实体。更改的目的是一项紧急财产。
我相信这里的重点不在于系统做了什么,而在于它所操作的数据以及这些操作是什么。
这提供了两个主要的思维转变:
有了这两个“基线”,您将更好地准备组织一个系统来实现您的目标,以便对数据的操作得到很好的理解和意义。
实际上,他正在为能够在您编写的代码上编写“合同”奠定基础。
从 Google 搜索中,它找到了 Art Gittleman's Computing With C# and the .Net Framework:
Bertrand Meyer 给出了一个工资单程序的例子,它从考勤卡中生成工资单。管理层稍后可能希望扩展此程序以生成统计数据或税务信息。例如,工资单功能本身可能需要更改以生成每周支票而不是双周支票。需要更改用于实施原始工资单程序的程序以进行任何这些修改。Meyer 指出,这些工资单程序中的任何一个都将操纵相同类型的数据、员工记录、公司法规等。
着眼于此类系统更稳定的方面,Mayer 提出了一个原则:“先问系统做什么:问它做什么!”;和一个定义:“面向对象的设计是导致软件架构基于每个系统或子系统操作的对象的方法(而不是它要确保的“功能”)。
今天,我们认为 UML 的类图和其他 OOAD 方法是理所当然的,但这是一路“发现”的东西。
另请参阅面向对象设计。
我的观点是,引用是一种在你的软件中找到好的抽象的方法。这句话旁边的文字涉及寻找真实世界的对象来设计你的类。
一个简单的例子是这样的:
你正在为一家银行制作软件。因为您的软件使用银行帐户,所以它应该有一个帐户类。然后,您开始考虑帐户具有哪些属性以及您可以与帐户进行哪些交互。
当然,如果您尝试建模的对象不像这种情况那么清晰,那么这句话会更有意义。
弗雷德布鲁克斯是这样说的:
“给我看你的流程图,隐藏你的表格,我会继续迷惑。给我看你的表格,我通常不需要你的流程图;它们会很明显。”
领域驱动设计...了解软件旨在解决的问题。系统操作什么“域”实体(数据抽象)?它对那些域实体有什么作用?