什么是单一exe+机器码
本文是有关SOLID as的五部分系列的第一部分
岩石设计原理系列。 SOLID设计原则着重于
开发易于维护,可重用和
可扩展的。 在这篇文章中,我们将看到S的例子英格尔- [R esponsibility P rinciple用C与它的好处和通用准则一起++。
/!\:最初发布于www.vishalchovatiya.com 。
顺便说一句,如果您还没有阅读我以前有关设计原则的文章,那么下面是快速链接:
意图
一堂课只有一个改变的理由
换句话说,SRP指出类应该与
指出它具有单一责任,责任定义
作为“改变的理由”。
动机:违反单一责任原则
class Journal {
string m_title;
vector < string > m_entries;
public :
explicit Journal ( const string &title) : m_title {title} {}
void add_entries ( const string &entry) {
static uint32_t count = 1 ;
m_entries.push_back(to_string(count++) + ": " + entry);
}
auto get_entries () const { return m_entries; }
void save ( const string &filename) {
ofstream ofs (filename) ;
for ( auto &s : m_entries) ofs << s << endl ;
}
};
int main () {
Journal journal{ "Dear XYZ" };
journal.add_entries( "I ate a bug" );
journal.add_entries( "I cried today" );
journal.save( "diary.txt" );
return EXIT_SUCCESS;
}
- 只要您有一个域对象,即Journal,上面的C ++示例就可以了。 但是在实际应用中通常不是这种情况。
- 当我们开始添加Book,File等域对象时,您必须分别为每个人实现save方法,这并不是实际问题。
- 真正的问题出在您必须更改或维护保存时
功能。 例如,某天您将不再保存
文件上的数据和采用的数据库。 在这种情况下,您必须走
通过每个域对象实现 &需要更改代码都是不好的。 - 在这里,我们通过向Journal类提供两个更改iii与Journal相关的事物的理由,从而违反了“单一责任原则”。 保存日记
- 此外,代码也将变得重复,肿且难以维护。
解决方案:C ++中的单一职责原理示例
- 作为解决方案,我们要做的是分离关注点 。
class Journal { string m_title; vector < string > m_entries; public : explicit Journal ( const string &title) : m_title {title} {} void add_entries ( const string &entry) { static uint32_t count = 1 ; m_entries.push_back(to_string(count++) + ": " + entry); } auto get_entries () const { return m_entries; } //void save(const string &filename) //{ // ofstream ofs(filename); // for (auto &s : m_entries) ofs << s << endl; //} }; struct SavingManager { static void save ( const Journal &j, const string &filename) { ofstream ofs (filename) ; for ( auto &s : j.get_entries()) ofs << s << endl ; } }; SavingManager::save(journal, "diary.txt" );
- 日记只应处理与日记相关的条目和事物。
- 并且应该有一个单独的中心位置或实体来进行保存工作。 在我们的例子中,它是SavingManager。
- 随着SavingManager的增长,所有与保存相关的代码都将放在一个位置。 您也可以将其模板化以接受更多域对象 。
单一责任原则的好处
=>表现力
- 当类仅做一件事时,其接口通常具有一个
少数方法更具表现力。 因此,它也有一个
少量的数据成员。 - 这样可以提高开发速度,并使您作为软件开发人员的生活更加轻松。
=>可维护性
- 我们都知道需求会随着时间而变化,因此
设计/架构。 班级职责越多,就越
通常您需要更改它。 如果您的班级实施多个
责任,他们不再相互独立。 - 单独的更改减少了软件其他不相关区域的破坏。
- 由于编程错误与复杂度成反比,
更容易理解,使代码不易出现错误和
易于维护。
=>可重用性
- 如果一个班级有多个职责,而其中只有一项需要
在软件的另一个区域中,那么其他不必要的
责任阻碍了可重用性。 - 承担单一职责意味着该类应可重用,而无需进行或只需进行很少的修改。
用C ++制作SRP友好软件的标尺
- SRP是一把双刃剑。 过于具体,最终
有数百个相互联系的荒谬类
轻松地成为一个。 - 当您感到自己是自己时,不应使用SOLID原则
工程过度。 如果您归纳为“单一责任原则”,
一般的想法是这样的:
SRP旨在限制变更的影响。 因此,将由于相同原因而发生变化的事物汇集在一起。 将因不同原因而改变的那些东西分开。
- 除此之外,如果您的类构造函数具有5-6个以上的参数,则意味着您要么不遵循SRP,要么不了解构建器设计模式。
结论
SRP是重构被广泛引用的理由。 这是
通常在没有完全了解SRP及其要点的情况下进行
上下文,导致范围为负数的代码库碎片
后果。 而不是成为最小尺寸的单向街
类,SRP实际上提出了一个平衡点
聚集和分裂。
有任何建议,疑问或想打个招呼吗? 减轻压力,您只需单击即可。 🖱️
翻译自: https://hackernoon.com/single-responsibility-principle-in-c-solid-as-a-rock-4d323ygo
什么是单一exe+机器码