OOP教程指南

贝里克和乔姆斯基的精彩文章“ 为什么只有我们：语言与进化”认为：人类语言首先作为一种对所感知的事物进行内部理解的工具而兴起，然后逐渐外部

我最近遇到一个人，他说，摆脱面向对象编程（OOP）的方式是回到简单地告诉计算机要做什么，就像OOP从未发生过。我认为这不是一个好主意，我也不认为这是可能的。面向对象的程序设计（尽管后来有过之而无不及）是软件工程领域的一大进步。它使开发比以前更大的程序成为可能，也许比原来大10倍。有人

大多数人进行SOLID软件设计讨论时都会很快变糟。我们最终为单一职责的“实际含义”而争辩或纠结，由于“开放/关闭”，我们某种程度上又需要抽象基类，并且由于“依赖倒置”，我们还向实体添加了接口。除了使您的代码“遵循SOLID”之外，还有更多重要的问题需要关注。此外，当您对“原则”非常“

不同的编程范例需要不同水平的学习投入。随着投资水平的提高，您会迅速失去人才。这就是为什么函数式编程尽管在许多方面都有所改进，但将永远是少数人的消遣。

有些人说设计模式已经死了。真愚蠢！ “设计模式”书籍是我们行业中出版的最重要的书籍之一。对于所有专业程序员来说，其中的概念应是基本知识。 设计模式就像现实生活中的谚语：这是开放了其他人的经验。 假设需要调用10种不同类型的设备，然后再打开它们，我会创建一个De

在软件设计中，“越小越好”几乎普遍是坏建议，例如针对数据库分区，消息大小，μsvcs，有界上下文，类名，方法一致性等。一些关键业务逻辑会越过这些细粒度边界，并导致实施不当。小粒度事物看起来很简单，因为错误不是隐藏在事物内部，而是隐藏在它们的连接中。 事物边界会变大，很少变小或

干净Clean代码并不总是面向对象的。有时它将以程序样式编写。哪种风格更好：过程式还是面向对象？我们应该在一定条件下进行选择，以使其易于开发和可读，根据“Clean守则”的原则。下面是过程代码的示例，它将帮助我考虑代码的纯度及其对面向对象代码的重构。

Java是一种面向对象的编程语言（它符合纯面向对象的大多数属性），它包括四个OOP支柱（面向对象的编程）概念，即： 抽象化 封装形式 继承 多态性 今天，我将深入探讨称为封装的重要支柱。作为参考，封装可以定义为“ 将数据和功能绑定到一

这是 SmalltalkBestPracticePatterns最佳实践之一：根据某个函数方法是做什么的（目的）命名这个

在面向对象的程序中使用getter和setter的主要目的是确保数据封装。像其他面向对象的语言一样，python中的私有变量实际上并不是隐藏字段。在以下情况下，通常使用python中的Getter和Setters： 我们使用getters和setters在获取和设置值周围添加

对象更多是关于行为还是数据？从外部看，数据是隐藏的，行为是公开的。我们看到投入转化为产出。但看不到任何倍隔离的数据；我们也不知道这些数据的存储位置或存储方式。数据库表更多是关于行为或数据信息？它们是简单的数据结构。从外部看，数据是暴露的，没有任何行为，无论可见或隐含的行为。对

仅仅编写有效的代码是不够的。问题发生时，必须易于维护，增强和调试该代码。面向对象编程如此受欢迎的原因之一是因为它满足了这些要求。但是，当开发人员选择捷径或更多地关注完成工作而不是正确完成工作时，往往会出现反模式。这些常见的反模式之一是上帝式对象。面向对象编程中的主要概念之一是

多年来，可重用性/可复用性是软件架构设计中的一个圣杯。关于可重用软件模块的讨论在1970年代初得到了发展。例如，1974年史蒂文斯，迈尔斯和君士坦丁（Stevens，Myers和Constantine）撰写的开创性的计算机科学论文

OOP取得了巨大的成功。但是成功仅仅是偶然吗？并且它还能在2020年提供其他编程范例无法提供的独特功能吗？在1981年8月的Byte杂志中，David Robson公开了他的文章，该文章成为许多人进入“ 

事件建模的创始人Alberto Brandolini说：数据是在有界上下文之间流动的，而行为是特定于某个有界上下文方式的。如果围绕数据划分微服务边界将导致分布式耦合。这不是我最喜欢的方式。（banq注：按动词如行为或事件寻找上下文之间边界，以此划分微服务边界，不是根据对象的数据属性，一个对象

什么是设计模式？设计模式大约在30年前出现。然而，许多人认为他们今天和以往一样重要。首先，什么是“设计”？它是关于软件设计的，而不是关于UI设计的。代码中的所有内容都是设计。从诸如变量名之类的细节到更多体系结构问题。 设计是一种形状Shape，系统需要