什么是单一exe+机器码_C ++中的单一责任原则:坚如磐石

什么是单一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+机器码

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值