14 | 面向对象之封装：怎样的封装才算是高内聚？

我平时用java语言开发，java语言的特点就是一切皆对象。我自己的理解是，java中对象的概念跟面向对象中对象的概念是不一样的。前者是语言的特性，后者跟作者说的一样，是一种编程范式。在具体的编码实践中，哪些属于对象，哪些不属于对象，应该是程序员掌控的。比如DDD中的领域实体，就是对象,需要仔细设计其行为接口。 至于平时说的一些POJO的对象，可以看成是数据载体，是可以加getter,setter的（没有这些默认的getter,setter,很多第三方的数据转化都很不方便，比如json，sql等）。在使用的时候，不归结为对象就可以了。

首先，Demeter 不是一个人，而是一个项目，项目主页 http://www.ccs.neu.edu/research/demeter/。最早提到迪米特法则的论文出版于 1989 年，Assuring good style for object-oriented programs。还有一本书，1996 年出版，Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns。没有看过。 Demeter 是希腊神话中的大地和丰收女神，也叫做德墨忒尔。 迪米特法则简单的说，分为两个部分：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。其实如果用另一个名字“最小知识原则”可能更容易理解一些，这个也算是程序员的“黑话”吧。 虽然接触面向对象编程已经很久了，也知道封装、继承和多态，不过写程序的时候，似乎还是习惯“一个对象一张表”的方式，也没有太多的考虑过封装的问题。整个类里面都是 getter、setter 的事情也做过，有点像是用“面向对象的语言写面向过程的代码”。 软件设计的大部分原则都耳熟能详，但是如何在写代码的时候“落地”，就不是特别清楚了，缺练。

经常听说一句话，程序设计应该关注数据结构，设计好了数据结构，工作就完成了一半。 今天的封装更偏向能力（方法），内部数据甚至可以去掉。不知道这两个原则是否冲突呢?

“迪米特法则”，印象最深的就是“不要和陌生人说话”。今天学习了本节课程，有了些启示，也可以理解为只和陌生人表达确定性意图。 每暴露一个公共API就增加一份职责，所以在每次暴露API时就要问自己，这个职责是自己必要的，还是有可能会增加不必要的负担。

好奇老师怎么看待Lombok，所有字段生成getter/setter不是一个好的实践，Java Bean的概念是不是也不该被提倡？

老师好，后续的文章能不能说下取方法名/变量 的技巧，

面向对象的基本原则第一个就是封装 日常开发中最常用到的封装莫过于函数了，一个函数实现一个最小的功能单元， 然后将各个函数与属性组织起来，就成了类 一个类又可视为最小的模块。 如何更好暴露接口是编码实践中的技能，时刻要思考着这个接口是否需要暴露以及最小化暴露的接口 最近我也在思考项目需要重构模块，我发现重构是一种软件进化，在杂乱的代码中理清逻辑，重新组织结构

意图和实现分离，应该更加关注对象提供哪些行为，起一个好的命名，而不是一股脑的 getter\setter。 谨慎暴露接口，日常中对 public 的滥用的确是随处可见的。 迪米特法则：一个类对自己依赖的类知道的越少越好。类似一个黑盒，我只通过一根绳和你产生联系，至于内部的实现以及面积体积多大等等，这些信息不要暴露出来。

我对于老师举的shutdown的例子有一个问题 如果按照我的想法 我会把两个shutdown方法都暴露出去 caller自己去组合 所以除非方法的实现需要变更 否则callee是不需要去更改的 但是老师说的是把两个方法封装一下 再暴露出一个封装好的方法 那么就好像老师说的 如果这两个方法需要改变顺序 caller就要改 这怎么理解？

"I made up the term "object-oriented," and I can tell you I did not have C++ in mind." --Alan Kay "Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS." --Alan Kay