生产中有这样一类C++项目，就是IT部门开发基础framework，业务部分只写业务逻辑。通常是IT写好一个基类，业务部门则重载这个基类，就可以做实际业务了，不同的业务重载为不同的子类就行。
这个好处是将众多的IT细节让专业的IT人员在framework里就已经写好了，业务部门的代码则重心在业务逻辑就可以了。
抽象来讲，就是在framework里定义:

Class Parent {
public:
    virtual void work()=0;
protected:
    // 成员变量、方法
}

这个设计模式还是很好用的，参与的各方也容易理解这个模式。
rust的trait能定义接口，但接口里没有成员变量。

如果语言选了rust，假设业务人员能会点简单的rust，那这样的设计模式可以在rust上方便地搞吗？如何弄 或 有什么替代的模式？
--
修改:RunningOn FROM 58.33.81.*
FROM 58.33.81.*

目前我能想到的比较简单的办法是在trait里将struct的引用作为参数。涉及到lifetime就会比较复杂。

并不是一定要坚持这样的设计模式，有其它的好用的设计模式也是OK的。

【 在 Windsor 的大作中提到: 】
: 按我的理解，对Rust也是深入中。
: Rust的设计理念包括一个组合重于继承的思想，这个也是GoF里面的模式。
: 对于OO来看，Struct里面包括数据，Trait里面代表行为，行为是可以有继承关系的。
: ...................
--
FROM 183.192.19.*

这个听起来和“trait的函数里第一个参数是struct的引用”感觉上差不多，
也是一种workaround
【 在 beep 的大作中提到: 】
: 我的粗浅看法，rust就是故意不让你用继承，尤其是含有数据属性（struct）的继承。
: 一个凑合的办法是把struct里的数据属性在trait里重写一遍get/set方法，这样trait从接口意义上看基本就能等价于你原来的c++ class了。缺点是每次impl这个trait都要写一大堆重复的get/set。
: 其实这就是所谓的“组合优于继承”嘛。写起来繁琐，用起来尤其是改起来方便。越来越多的oop语言现在也都倾向于主张这么搞了。
: ...................
--
FROM 183.192.19.*

struct放参数可以搞。几天讨论下来只有这个方法靠谱了。

不过那个 banana-monkey-jungle 倒不是oop的问题，是framework的问题，大多数项目的设计中都没有考虑在不引入整个framework的情况下引入一个小部件。


【 在 eGust 的大作中提到: 】
: 我一直说，oo 就是工程师设计出来的东西。把一堆数据类型放在一起，组合成 struct，然后很自然的就想到，完全可以把一堆函数按照同样的方式放到一起。从复用数据类型的结构，再到复用同样接口的函数。
: 但其实，oo 复用代码的场景过于理想化，以至于在现实中，都是硬往上凑而且还带来了非常多的问题。
: 比如前端的控件，看起来似乎是一个很理想的 oo 的场景。实际中呢，react 最开始的确也是这么设计的，但跟它自身核心的 fp 格格不入，最后换成 hooks 了。vue 在做3的过程当中，也想过用 typescript + decorator + oo 的形式来实现，但其实2里的 mixin 的坑就已经很深了，所以
: ...................
--
FROM 58.33.81.*