标签: single-responsibility-principle

我有YoutubeVideoService执行 CRUD（创建、读取、更新和删除）操作的类。在我看来，创建、读取、更新和删除是类更改的四个原因。这个类是否违反了单一职责原则？

如果违反，那么，我们应该有四个类，如CreateYoutubeVideoService，ReadYoutubeVideoService，UpdateYoutubeVideoService和DeleteYoutubeVideoService。有很多课程是不是有点矫枉过正？

如果对象具有单一责任,则可以接受以下内容:

public class Person
{
   public string Name;
   public DateTime DateOfBirth;

   private IStorageService _storageService;

   public Person(IStorageService storageService)
   {
      _storageService = storageService
   }

   public void Save()
   {
        _storageService.Persist(this);
   }
}

即使用提供的协作者(这也有助于阻止领域模型贫血).

或者应该是:

public class Person
{
   public string Name;
   public DateTime DateOfBirth;

   public Person()
   {
   }


}
public class StorageService
{
    public void Persist(Person p)
    {
    }
}

我最近一直在考虑Liskov替换原则以及它与我当前任务的关系.我有一个包含菜单的主表单; 在这个主要表单中,我将一个特定的表单作为MDI子对接.此特定表单可能包含也可能不包含菜单.如果是,我想将它与主菜单合并.所以情况是这样的:

public class MainForm
{
    public void Dock(SpecificBaseForm childForm)
    {
        this.Dock(childForm);
        if (childForm is IHaveMenu)
        {
            this.Menu.Merge(childForm as IHaveMenu).Menu;
        }
    }
 }

public interface IHaveMenu
{
   Menu Menu {get;}
}

public abstract class SpecificBaseForm{}

public class SpecificFormFoo : SpecificBaseForm {}

public class SpecificFormBar: SpecificBaseForm,IHaveMenu
{
    public Menu Menu{get {return this.Menu;}}
}

现在这两个孩子并不是"完全"可互换的:一个有菜单; 另一个没有.这是在C#中误用is/as contruct吗？如果这不正确,那么干净的解决方案是什么？

我不确定我班内的这种方法是否违反了单一责任原则,

public function save(Note $note)
{
    if (!_id($note->getid())) {

        $note->setid(idGenerate('note'));

        $q = $this->db->insert($this->table)
                      ->field('id', $note->getid(), 'id');

    } else {
        $q = $this->db->update($this->table)
                      ->where('AND', 'id', '=', $note->getid(), 'id');
    }

    $q->field('title', $note->getTitle())
      ->field('content', $note->getContent());

    $this->db->execute($q);

    return $note;
}

基本上它在方法中执行两个作业 - 插入或更新.

我应该将其分为两种方法,而不是遵守单一责任原则吗？

但SRP仅适用于课程,不是吗？它适用于类中的方法吗？

SRP -

一个类应该只有一个责任(即软件规范中只有一个潜在的变化应该能够影响类的规范)

编辑:

另一种列出笔记(包括许多不同类型的列表),搜索笔记等的方法......

public function getBy(array $params = array())
{
    $q = $this->db->select($this->table . ' n')
                  ->field('title')
                  ->field('content')
                  ->field('creator', 'creator', 'id')
                  ->field('created_on')
                  ->field('updated_on');

    if (isset($params['id'])) {
        if (!is_array($params['id'])) {
            $params['id'] = array($params['id']); …

我正在努力理解单一责任原则如何与OOP合作.

如果我们要遵循这个原则来开球,那么我们是不是留下了许多课程,其中许多课程可能只有一个方法？

如果我们不完全遵循这个原则,那么这个原则的重点是什么？

在下面的视频中,作者采用现有的类并为其分配单一责任原则.他选择了一个打印类,它具有访问数据,格式化和打印报告的功能.他将每个方法分解为自己的类,因此他创建了一个DataAccess类来处理数据访问,他创建了一个ReportFormatter类来处理Report的格式,并创建了一个ReportPrinter类来处理Report的打印.然后,原始的Report类保留一个方法Print(),该方法调用ReportPrinter的类方法Print.DataAccess和ReportFormatter似乎有责任,但ReportPrinter依赖于DataAcess和ReportFormatter,所以这不会破坏SRP或者我是否误解了它？

在经典的Facade模式中,单个对象通常为更复杂的东西提供简化的界面.

正如四人帮所说的那样(尽管接近"官方"......):

Facade(185)为子系统中的一组接口提供统一接口.Facade定义了一个更高级别的接口,使子系统更易于使用.

和

...一个外观只是抽象出子系统对象的接口,使它们更容易使用; 它没有定义任何新功能,子系统类也不知道它.

或者,正如Unmesh将其放在/sf/answers/366973351/中:

Facade保护用户免受系统的复杂细节的影响,并为他们提供易于使用的简化视图.它还将使用系统的代码与子系统的细节分离,使以后更容易修改系统.

单一责任原则告诉我们

一个类或模块应该只有一个改变的理由.

Per Bob叔叔(http://en.m.wikipedia.org/wiki/Single_responsibility_principle)

鉴于Facade在设计上可以保护用户免受众多"改变的原因"的影响,这两个想法如何协同工作？Facade是否有与其实现所依赖的子系统数量一样多的理由进行更改？

我试图遵循接口隔离和单一职责原则，但是我对如何将它们整合在一起感到困惑。

在这里，我有一个示例，其中有一些接口，我已将其拆分为更小、更直接的接口：

public interface IDataRead
{
    TModel Get<TModel>(int id);
}

public interface IDataWrite
{
    void Save<TModel>(TModel model);
}

public interface IDataDelete
{        
    void Delete<TModel>(int id);
    void Delete<TModel>(TModel model);
}

我稍微简化了它（有一些where条款妨碍了可读性）。

目前我正在使用SQLite ，但是，这种模式的美妙之处在于，如果我选择不同的数据存储方法（例如Azure），它有望让我有机会更好地适应变化。

现在，我对每个接口都有一个实现，下面是每个接口的简化示例：

public class DataDeleterSQLite : IDataDelete
{
    SQLiteConnection _Connection;

    public DataDeleterSQLite(SQLiteConnection connection) { ... }

    public void Delete<TModel>(TModel model) { ... }
}

... 

public class DataReaderSQLite : IDataRead
{
    SQLiteConnection _Connection;

    public DataReaderSQLite(SQLiteConnection connection) { ... }

    public …

我想在我的项目域层（Clean MVVM ）中实现单一职责原则。

我有大约 200 个不同的用例，管理起来非常繁忙。现在我正在考虑创建一个UseCaseManager可以为我提供所需的UseCase基于Input&Output对象的对象。

我尝试了一种方法，但看起来不太好。我提到了一些示例代码，请帮助我如何将所有用例聚合到一个 UseCaseManager。

用例1：

public class ActualUseCase1 extends AsyncUseCase<Object3,Object4> {

    public ActualUseCase1(SchedulerProvider schedulerProvider) {
        super(schedulerProvider);
    }

    @Override
    public Flowable<Object4> buildUseCaseFlowable(Object3 input) {
        return Flowable.just(new Object4());
    }
}

用例2：

public class ActualUseCase2 extends AsyncUseCase<Object1, Object2> {

    public ActualUseCase2(SchedulerProvider schedulerProvider) {
        super(schedulerProvider);
    }

    @Override
    public Flowable<Object2> buildUseCaseFlowable(Object1 input) {
        return Flowable.just(new Object2());
    }
}

用例管理器：

public interface UseCaseManager<In, Out> {
    <T> T getUseCase(In …

我对单一职责原则很困惑。该原则指出，类更改的原因应该只有一个。

我面临的问题是，对方法的任何更改或做事中的任何逻辑更改都会更改类。例如，考虑以下类：

class Person{
    public void eat(){ };
    public void walk(){ };
    public void breathe(){ };
    public void run(){ };
    public void driveCar(Car car){ };
}

鲍勃叔叔将其描述为应该只有一个人/演员负责更改。我有以下两个问题：

1. 对于上面的类，谁是可以负责变化的演员/人？
2. 饮食、呼吸或行走的逻辑的任何变化不会改变 Person 类吗？那么这是否意味着每一种方法都是改变的理由，因为做事的逻辑可能会改变？