07 | 理论四：哪些代码设计看似是面向对象，实际是面向过程的？

1.用shell实现自动化脚本做的服务编排，一般都是面向过程，一步一步的。而k8s的编排却是面向对象的，因为它为这个顺序流抽象出了很多角色，将原本一步一步的顺序操作转变成了多个角色间的轮转和交互。 2.从接触ddd才走出javaer举面向对象旗，干面向过程勾当的局面。所谓为什么“充血模型”不流行，我认为不外呼两个。一，规范的领域模型对于底层基础架构来说并不友好（缺少setget），所以会导致规范的领域模型与现有基础架构不贴合，切很难开发出完全贴合的基础架构，进而引深出，合理的业务封装却阻碍关于复用通用抽象的矛盾。二，合理的业务封装，需要在战略上对业务先做合理的归类分割和抽象。而这个前置条件很少也不好达成。进而缺少前置设计封装出来的“充血模型”会有种四不像的味道，反而加剧了业务的复杂性，还不如“贫血模型”来得实用。事实上快节奏下，前置战略设计往往都是不足的，所以想构建优秀的“充血模型”架构，除了要对业务领域和领域设计有足够的认知，在重构手法和重构意愿上还要有一定讲究和追求，这样才能让项目以“充血模型”持续且良性的迭代。 3.“充血模型”相对于“贫血模型”有什么好处？从我的经验来看，可读性其实可能“贫血模型”还好一点，这也可能有思维惯性的原因在里面。但从灵活和扩展性来说“充血模型”会优秀很多，因为好的“充血模型”往往意味着边界清晰（耦合低），功能内敛（高内聚）。这一块老师怎么看？

个人觉得，MVC这种框架模式本质上与面向对象并不冲突。当我们在讨论面向对象的时候，我们究竟应该怎样去定义一个对象，究竟什么才能被我们看成是对象，是不是只有像某种物体，比如说一只鸟或者一只狗我们才能去把他定义为对象？我认为，MVC里面的三个部分Model 、Controller 、View 我们都能把他们单独的看成一个对象，比如说Model，本来它是数据单元，但是如果我们把他看做一个对象的话，里面存储的数据不就是我们对象里的属性么，而对于数据的二次加工处理等等操作不就是对象里的方法么？同理，对于View而言，里面小的view组件或者是其他的view不就是我们对象里面的属性，而对于不同的view组件或其他view的组合或者其他的处理操作不就是对象里面的方法么？所以说，不必死抠定义，数据就一定要和业务逻辑组成一个类云云。。。我们最后写出来的代码的目的就是，1.要解决问题；2.代码有可扩展性，可读性；3，代码解耦；

看完这篇，真的太有感触了，提出的这些问题，都是目前大部分程序员所存在的编码问题。 实际上面向对象、充血模型，面向过程，都是各有各的使用场景，这点上面的同学都说的很明白了，老师也说的非常明白。 很想加老师的微信交流沟通，总有那种一见如故的感觉。 我一直觉得我推崇的编码方式好像在他们眼里是异类，又说不清楚自己推崇的是什么。 说一个非面向对象语言实现面向对象的方式 lua 可以使用 setmetatable 方式实现 封装 继承

1.现在因为使用封装好的框架，没有提供set方法，类的序列化会成为一个问题 2.从理论上来说，数据和逻辑应该放在一起，但是数据的赋值往往可能依赖其他的service提供的数据，如果这样的话数据属性和纯粹依赖的service就会导致一个类的成员属性特别的多。 3.对于一个具体现实对象而言，不同场景下可能关心的字段稍微有些不一样，对于此又该怎么处理呢？多个小对象，他们之间有无相关关系，有的话如何阐述，还是全部赋值完毕，都完整返回。当然可能具体场景具体分析，那是否有一个稍微通用的指导纲领 期待老师关于面向对象的实战流程

习惯了从前端的参数直接使用 BeanUtils.copyProperties 映射到具体实体类，如果不直接提供set方法，有啥好的方法去组装数据呢

1.get set 这个很好理解，但是我有很多疑问，比如有的属性理论上来讲不该添加set方法，那我怎么对他进行属性拷贝？比如两个vo进行拷贝属性值，还有作为接口参数，spring又怎么给他赋值？ 2.看完贫血模式那个知识点后，我懵了，我甚至不知道怎么才能写出面向对象的代码了，如果数据和业务不分离的话，那比如我多个业务接口需要同一份数据，难道要定义多份吗？我有点懵了😥😥😥

老师这一讲，解我多年困惑。 仍有一事困惑：前端传数据到后端，我要是不定义一个开放了所有属性的POJO，那么数据如何反序列化成类呢？

Constants用接口是不是比用类更好？

是不是对不同的业务场景，应该采用不同的编程范式 业务驱动比较强的场景，是不是用采用面向过程编程更容易让人理解，

老师讲课举例的时候，能不能稍微带点python的例子？（另外，老师在加餐里有Java的基础知识，非常贴心了）