使用Stack分配对象的自动对象解构的想法让我想到了使用系统作为初始化和清理第三方库的一种方式。
示例:
#include <libA.h>
#include <libB.h>
namespace library {
class Wrapper {
Wrapper() {
libA_init();
libB_init();
}
~Wrapper() {
libB_exit();
libA_exit();
}
}
}
int main() {
library::Wrapper library;
}
人们已经在SO上争论过,是否应该将自动堆栈释放的简单使用称为RAII,因为没有R的RAII就是OO的工作方式。 (分配是初始化吗?听起来像是在向我调用构造函数。)
这种用法是众所周知的反模式还是组织代码的好主意?
答案 0 :(得分:2)
您问:
这是组织代码的众所周知的反模式还是好主意?
一个好主意。由于这是资源管理的问题,因此这是组织第三部门的一种真正整洁的方式。派对c风格的库init / cleanup和我以前见过的一个。
尽管您的示例有几点要点。
首先,每个班级都有一个以上,显然违反了“一班一负责”的原则。
第二,除非有充分的理由,否则应该将init放置在main之外(例如,紧跟在类定义之后)。
答案 1 :(得分:0)
这是组织代码的众所周知的反模式还是好主意?
完全取决于您需要这样做的范围。
通常RAII不是反模式,而是与c ++结合使用的首选模式。
您可能需要照顾└───src
├───main
│ ├───java
│ │ └───com
│ │ └───abc
│ │ └───app
│ │ ├───config
│ │ ├───data
│ │ │ ├───model
│ │ │ └───repository
│ │ ├───exception
│ │ ├───service
│ │ └───serviceImpl
│ └───resources
│ ├───META-INF
│ └───static
│ ├───css
│ ├───images
│ └───js
└───test
└───java
└───com
└───abc
└───app
├───data
│ └───repository
├───service
└───serviceImpl
的自动生成的复制构造函数和赋值运算符,并且可以library::Wrapper
明确使用它们。