生产中有这样一类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.*

struct 怎么继承？

【 在 Windsor 的大作中提到: 】
: Rust是多模式语言，OO部分采用Struct + Trait来实现。
: 你的需求就是Struct的特点，有pub和缺失私有的控制。
--
FROM 58.33.81.*

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

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

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

好像现在的趋势是函数式编程，解藕，所以oop那一套不怎么流行了

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

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