我正在设计一个分布式文件系统,其中一个核心类是文件系统类,看起来像:
class FileSystem {
public:
exists(Path*);
insert_file(File*);
insert_block(Block*);
remove(Path*);
list();
update_file(File*);
update_block(Block*);
get_file(Path*);
get_block(Block*);
move(Path*, Path*);
copy(Path*, Path*);
...
... // More and more methods
};
我成功地重构了该项目,但是,每当需要添加行为(装饰器或子类型)时,我都无法重构此类课程,我最终使我的设计变得更加复杂。另一个问题是该类的依赖项数量(路径,块,文件等未包含在摘要中)。
主要原因是该FS类负有太多职责,但是我仍然找不到将此文件系统类分为不同类的方法。我想知道这种情况是否有任何模式,如果没有,您将如何处理这个巨大的班级?
请查看C 核心指南C.4:
只有在需要直接访问类的表示
时才能使函数成为成员
在上面的示例中,尚不清楚内部状态文件系统具有什么,但我猜最少。任何可以通过公共接口表达的功能,应具有免费功能。另一种说法是,任何不涉及保持类别不变的功能都不应成为接口的一部分。
我猜文件系统仅由其当前文件夹表示。
class FileSystem {
private:
Path* directory_;
public:
FileSystem(Path *directory) : directory_ {directory};
Path* directory() { return directory_; };
};
保持不变的成员函数的示例是chdir
。如果那是感兴趣的。它也可能是一个免费的功能,可以返回一个新的文件系统,从而使该类基本上是不可能的,这是非常理想的,请参见指南CON.1。
class FileSystem {
...
chdir(Path* subpath) { /* checks */ ... }
};
以上所有其他功能都可以通过公共接口表示,因此它们应该是非成员函数:
exists(FileSystem*, Path*);
insert_file(FileSystem*, File*);
insert_block(FileSystem*, Block*);
remove(FileSystem*, Path*);
list(FileSystem*);
update_file(FileSystem*, File*);
update_block(FileSystem*, Block*);
get_file(FileSystem*, Path*);
get_block(FileSystem*, Block*);
move(FileSystem*, Path*, Path*);
copy(FileSystem*, Path*, Path*);