1.用shell实现自动化脚本做的服务编排，一般都是面向过程，一步一步的。而k8s的编排却是面向对象的，因为它为这个顺序流抽象出了很多角色，将原本一步一步的顺序操作转变成了多个角色间的轮转和交互。

2.从接触ddd才走出javaer举面向对象旗，干面向过程勾当的局面。所谓为什么“充血模型”不流行，我认为不外呼两个。一，规范的领域模型对于底层基础架构来说并不友好（缺少setget），所以会导致规范的领域模型与现有基础架构不贴合，切很难开发出完全贴合的基础架构，进而引深出，合理的业务封装却阻碍关于复用通用抽象的矛盾。二，合理的业务封装，需要在战略上对业务先做合理的归类分割和抽象。而这个前置条件很少也不好达成。进而缺少前置设计封装出来的“充血模型”会有种四不像的味道，反而加剧了业务的复杂性，还不如“贫血模型”来得实用。事实上快节奏下，前置战略设计往往都是不足的，所以想构建优秀的“充血模型”架构，除了要对业务领域和领域设计有足够的认知，在重构手法和重构意愿上还要有一定讲究和追求，这样才能让项目以“充血模型”持续且良性的迭代。

3.“充血模型”相对于“贫血模型”有什么好处？从我的经验来看，可读性其实可能“贫血模型”还好一点，这也可能有思维惯性的原因在里面。但从灵活和扩展性来说“充血模型”会优秀很多，因为好的“充血模型”往往意味着边界清晰（耦合低），功能内敛（高内聚）。这一块老师怎么看？

总的来说，使用面向对象风格编写的面向过程代码有如下特点：

1. 使用了类，但是
2. 要么完全没有封装（比如数据和操作分离的贫血模式）
3. 要么破坏了封装（比如滥用 getter 或 setter）
4. 要么完全没有抽象（大而全的 Constants 或 Utils 类）
5. 要么封装或抽象不完全（比如类实例化后，或者子类继承后，需要自己管理其内部某些属性或状态）

平时应该多留心代码是否存在上述特征。

文中没有举封装或抽象不完全的例子，这里举一个。

比如一个实现某种业务需求（如与某种类型设备通讯的应用协议）的 tcp 或 udp 服务器；

实例化后还需要自己管理其协议相关的就绪状态（ready属性）；使你不得不对其再封装一层，并抽象其连接、断开等方法使其自动进行就绪状态的管理；

每个继承都这么封装一遍，就会有大量重复的代码，而且其实类的实例化者或继承者并不需要也不应该关心就绪状态的管理，所以没有达到就绪状态管理的封装。

这就是一种不完全的封装。

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

先说问题2：看似面向对象实际面向过程的例子真是数不胜数了， 工作语言C/C++，90%是C++,大体上老师在文中已经提到了，其他的我暂时也没想起来，但是滥用面向对象继承特性的代码我真是看到了太多
问题1：C中可以用struct 来实现class，只是访问控制权限都是public。类中的成员函数可以通过指向操作结构体的函数指针来实现，实现封装，需要绑定数据、函数、函数指针。可以创建函数指针表，构造函数设置函数指针指向正确的操作函数，函数指针表作为对象访问函数的接口。操作结构体的这些函数（成员函数）不像C++中能直接访问数据成员，需要显示的传递操作对象给成员函数。
继承：在派生类中维护一个基类对象的指针。这样派生类可以访问基类对象的数据。
多态：在基类中维护一个派生类对象的指针。这样基类可以访问派生类对象的数据。
C++中的多态，有一个对象销毁的问题。基类的析构函数必须是虚函数
在C中，这可以通过使基类的删除函数指针指向派生类的删除函数，因为派生类的删除函数清楚派生类的数据和基类的数据

接上条评论，代码实现如下，欢迎讨论
typedef struct _Base Base;
typedef void (*fptrDisplay)(Base*);
typedef void (*fptrDelete)(Base*);
void DisplayBase(Base* );
void DeleteBase(Base*);
typedef struct _Base
{
    void* pDeriveObj;
    int a;
    int b;
    fptrDisplay Display;
    fptrDelete Delete;
}Base;
Base* new_base(int a, int b)
{
    Base* pObj = NULL;
    pObj = (Base*)malloc(sizeof(Base));
    if (pObj == NULL)
    {
        return NULL;
    }
    // 当创建基类对象时指向自己
    pObj->pDeriveObj = pObj;
    pObj->a = a;
    pObj->b = b;
    pObj->Display = DisplayBase;
    pObj->Delete = DeleteBase;
    return pObj;
}
void DisplayBase(Base* base)
{
    printf("member: a:%d\t b:%d\n", base->a, base->b);
}
void DeleteBase(Base* base)
{
    printf("base destructor!\n");
    free(base);
}
typedef struct _Derive
{
    Base* pBaseObj;
    int c;
    int d;
}Derive;
void DeriveDisplay(Base* base);
void DeriveDelete(Base* base);
Base* new_Derive(int a, int b, int c, int d)
{
    Derive* pObj = NULL;
    Base* pBaseObj = new_base(a, b);
    pObj = malloc(sizeof(Derive));
    if (!pObj)
    {
        pBaseObj->Delete(pBaseObj);
        return NULL;
    }
    pBaseObj->pDeriveObj = pObj;
    pObj->pBaseObj = pBaseObj;
    pObj->c = c;
    pObj->d = d;
    pBaseObj->Display = DeriveDisplay;
    pBaseObj->Delete = DeriveDelete;
    return pBaseObj;
}
void DeriveDisplay(Base* base)
{
    Derive* pDeriveObj = (Derive*)(base->pDeriveObj);
    printf("member:base:a:%d\t base:b:%d\nderive:c:%d\t derive:d:%d\n", base->a, base->b, pDeriveObj->c, pDeriveObj->d);
}
void DeriveDelete(Base* base)
{
    printf("derive destructor!\n");
    free(base->pDeriveObj);
    free(base);
}
int main()
{
    Base* pBase = new_base(1, 2);
    Base* pDerive = new_Derive(3, 4, 5, 6);
    pBase->Display(pBase);
    pDerive->Display(pDerive);
    pBase->Delete(pBase);
    pDerive->Delete(pDerive);
}

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

今日的课堂讨论不会回答,尝试总结一下重点回顾的3个问题:

1.getter, setter问题的本质类的可变性问题.<Effective Java>中明确提到,除非有必要,否则类应该设计为不可变(Immutable)的.

2. Constants 和 Util类的问题本质是静态成员和静态方法问题.
静态成员和静态方法违背面向对象设计(OOP)原则,但从整体项目角度讲,静态成员和静态方法的好处大于其坏处,所以它们确实有存在的意义.

3.我对贫血模型的看法: 我是一名Android开发,日常使用的是MVC的变种MVP && MVVM模型.
MVP和MVVM相比MVC要更靠近OOP思想，但面向过程思想的设计仍包含于其中。
无论面向对象或面向过程，写出层次清晰，易扩展，易维护的代码才是目的。

看完这篇，真的太有感触了，提出的这些问题，都是目前大部分程序员所存在的编码问题。

实际上面向对象、充血模型，面向过程，都是各有各的使用场景，这点上面的同学都说的很明白了，老师也说的非常明白。

很想加老师的微信交流沟通，总有那种一见如故的感觉。

我一直觉得我推崇的编码方式好像在他们眼里是异类，又说不清楚自己推崇的是什么。

说一个非面向对象语言实现面向对象的方式 lua 可以使用 setmetatable 方式实现 封装 继承