Questions tagged «single-responsibility»

显然，“单一责任原则”并不意味着“只做一件事情”。那就是方法的目的。 public Interface CustomerCRUD { public void Create(Customer customer); public Customer Read(int CustomerID); public void Update(Customer customer); public void Delete(int CustomerID); } 鲍勃·马丁说：“班级应该只有一个改变的理由。” 但是，如果您是SOLID的新手，那么很难下定决心。 我写了另一个问题的答案，在那儿我建议责任就像职位，然后用饭店的比喻来阐明我的观点。但这仍未阐明某人可以用来定义其班级职责的一组原则。 你是怎么做到的？您如何确定每个班级应承担的责任，以及如何在SRP中定义责任？

198 architecture  class-design  solid  single-responsibility 

我试图尽可能地遵守单一职责原则（SRP），并且习惯了某种严重依赖委托的特定模式（对于方法上的SRP）。我想知道这种方法是否合理，或者是否存在严重问题。 例如，要检查对构造函数的输入，我可以引入以下方法（Stream输入是随机的，可以是任何东西） private void CheckInput(Stream stream) { if(stream == null) { throw new ArgumentNullException(); } if(!stream.CanWrite) { throw new ArgumentException(); } } 这种方法（可以说）做的不止一件事 检查输入 引发不同的异常 因此，为了遵守SRP，我将逻辑更改为 private void CheckInput(Stream stream, params (Predicate<Stream> predicate, Action action)[] inputCheckers) { foreach(var inputChecker in inputCheckers) { if(inputChecker.predicate(stream)) { inputChecker.action(); } } } 据说哪件事只会做一件事（是吗？）：检查输入。对于输入的实际检查和异常的抛出，我介绍了类似的方法 bool …

66 c#  single-responsibility 

单一责任原则在维基百科上定义为 单一责任原则是一种计算机编程原则，它指出每个模块，类或功能都应对软件提供的功能的一部分负责，并且责任应完全由类封装 如果一个班级仅应承担一项职责，那么它怎么可能有不止一种方法？每种方法都不会承担不同的责任，这将意味着该类将承担多个责任。 我看到的每个展示单一责任原则的示例都使用一个只有一个方法的示例类。查看示例或使用多种方法解释类可能会有所帮助，但仍然可以认为这是一种责任。

64 solid  single-responsibility 

今天我和某人吵架。 我正在解释使用富域模型相对于贫血域模型的好处。我用一个简单的类演示了我的观点： public class Employee { public Employee(string firstName, string lastName) { FirstName = firstName; LastName = lastname; } public string FirstName { get private set; } public string LastName { get; private set;} public int CountPaidDaysOffGranted { get; private set;} public void AddPaidDaysOffGranted(int numberOfdays) { // Do stuff } …

63 c#  object-oriented  single-responsibility 

问题摘要： 长话短说，我继承了代码库和不允许更换的开发团队，使用God Objects是一个大问题。展望未来，我想让我们重构事情，但是我从那些想与God Objects一起做所有事情的团队中得到了回击，“因为它更容易”，这意味着我将无法重构。我以多年的开发经验为后盾，我是受雇来了解这些事情的新老板，等等，第三方离岸公司的销售代表也是如此，现在这是在执行层和我的会议上现在是明天，我想投入大量技术弹药以倡导最佳实践，因为从长远来看，我认为这对于公司而言会便宜得多（而且我个人认为这是第三方所担心的）。 我的问题是从技术角度讲的，我知道它的长期稳定性，但是我在超短期和6个月期限方面遇到了麻烦，尽管我“知道”我无法通过引用和引用的资源来证明这一点。一个人（罗伯特·C·马丁，又名鲍勃叔叔），因为我被告知要从一个人那里获得数据，而只有一个人（罗伯特·C·马丁）的论点不够好。 题： 我可以直接引用一些本领域知名专家的资源（标题，出版年份，页码，报价），这些资源明确表示对“上帝”对象/类/系统的这种使用不好（或很好，因为我们正在寻找）技术上最有效的解决方案）？ 我已经做过的研究： 我在这里有很多书，并且已经搜索了它们的索引以查找单词“ god object”和“ god class”的使用。我发现奇怪的是它几乎从未使用过，例如我所拥有的GoF书的副本就从未使用过（至少根据我面前的索引），但是我在下面的两本书中找到了它，但是我想要更多我可以用。 我在Wikipedia页面上检查了“上帝对象”，并且该页面当前是一个存有很少参考链接的存根，因此尽管我个人同意它说，但在个人经历被认为无效的环境中，我没有太多用处。被引用的书也被认为太老了，无法被我在讨论这些技术要点的人们接受，因为他们提出的论据是：“曾经被认为是不好的，但没人能证明它，而现在的现代软件则说：”上帝“对象很好用”。我个人认为这句话是不正确的，但无论事实如何，我都想证明事实。 在罗伯特·C·马丁（Robert C Martin）的“ C＃中的敏捷原理，模式和实践”（ISBN：0-13-185725-8，精装本）的第266页中，它指出：“每个人都知道，神的阶级是个坏主意。我们不想将系统的所有智能集中到单个对象或单个功能中。OOD的目标之一是将行为划分和分布到许多类和许多功能中。” -然后继续说有时还是最好还是使用上帝课程（以引用微控制器为例）。 在罗伯特·C·马丁（Robert C Martin）的“清洁代码：敏捷软件技巧手册”第136页（仅此页面）中，谈到了“上帝的阶级”，并称其为违反“阶级应该很小”规则的主要例证。从第138页开始，他使用了“单一责任原则”。 我遇到的问题是，我所有的参考文献和引用都来自同一个人（Robert C. Martin），并且来自同一个人/来源。有人告诉我，因为他只是一个观点，所以我不使用“上帝类”的愿望是无效的，并且未被接受为软件行业的标准最佳实践。这是真的？从技术的角度来看，我是在努力遵循鲍勃叔叔的教导做错事情吗？ 上帝对象和面向对象的编程与设计： 我对这一点的思考越多，我就越会在学习OOP时学到更多，而且从来没有明确指出过。它对良好设计的暗含是我的想法（请随意纠正我，因为我想学习），问题是我“知道”这一点，但不是每个人都知道，因此在这种情况下，它不被视为有效的论证，因为当实际上大多数人在统计上都不了解它时，我实际上将其称为普遍真理，因为从统计学上讲大多数人都不是程序员。 结论： 我不知所措，想获得最好的附加结果来引用，因为他们提出了技术要求，并且我想知道真相并能够像真正的工程师/科学家一样被引用证明事实，即使由于我对使用神物的经验，我对神物有偏见。任何帮助或引用将不胜感激。

56 object-oriented  class  object  single-responsibility 

我正在一个团队中，团队负责人是SOLID开发原则的坚决拥护者。但是，他缺乏将复杂软件发布出去的大量经验。 在某种情况下，他将SRP应用于本来已经很复杂的代码库中，而现在该代码库变得非常分散，难以理解和调试。 现在，我们不仅遇到代码碎片问题，而且遇到封装问题，因为某个类中可能是私有或受保护的方法被判断为代表“更改原因”，并已提取到公共或内部类和接口中，与应用程序的封装目标不符。 我们有一些类构造函数，它们接收20个以上的接口参数，因此我们的Io​​C注册和解析本身已成为一个庞然大物。 我想知道我们是否可以使用任何“远离SRP的重构”方法来帮助解决其中一些问题。我已经读到如果创建多个空的粗粒度类来“包装”多个紧密相关的类以提供对它们功能总和的单点访问（即模仿一个较小的类），则它不会违反SOLID过度采用SRP的类实施）。 除此之外，我想不出一种解决方案，该解决方案将使我们能够务实地继续我们的开发工作，同时又使每个人都满意。 有什么建议么 ？

56 c#  wpf  inversion-of-control  single-responsibility 

在过去的几年中，我们一直在缓慢地转换为逐渐更好的书面代码，每次只需几个小步骤。我们终于开始切换到至少与SOLID类似的东西，但是我们还没有到那儿。自从进行切换以来，开发人员最大的抱怨之一就是他们无法忍受同行审查和遍历数十个文件，而以前的每个任务只需要开发人员触摸5-10个文件即可。 在开始进行转换之前，我们的体系结构非常类似于以下内容（已授予，但又增加了一个或两个数量级的文件）： Solution - Business -- AccountLogic -- DocumentLogic -- UsersLogic - Entities (Database entities) - Models (Domain Models) - Repositories -- AccountRepo -- DocumentRepo -- UserRepo - ViewModels -- AccountViewModel -- DocumentViewModel -- UserViewModel - UI 从文件的角度来看，所有内容都非常线性且紧凑。显然有很多代码重复，紧密耦合和令人头疼的问题，但是，每个人都可以遍历并弄清楚。完全的新手，从来没有像以前那样打开过Visual Studio的人，就可以在几周内解决这个问题。缺乏整体文件的复杂性，对于新手开发人员和新员工来说，在不增加太多时间的情况下就开始进行贡献相对容易。但这几乎就是代码风格的任何好处都无法体现的地方。 我全心全意地支持我们为改善代码库所做的一切尝试，但是在这样的大规模范式转换中，从团队的其他成员那里得到一些回击是很普遍的。当前几个最大的症结是： 单元测试 班数 同行评审的复杂性 单元测试对于团队来说是一笔难以置信的辛苦卖点，因为他们所有人都认为这是浪费时间，并且他们能够比单个代码更快地整体测试代码。使用单元测试作为SOLID的认可在大多数情况下是徒劳的，并且在这一点上已经成为一个笑话。 上课人数可能是要克服的最大障碍。过去需要5-10个文件的任务现在可以占用70-100！尽管每个文件都有不同的用途，但文件的数量却是巨大的。团队的反应主要是吟和头部抓挠。以前，一项任务可能需要一个或两个存储库，一个或两个模型，一个逻辑层和一个控制器方法。 现在，要构建一个简单的文件保存应用程序，您需要一个类来检查文件是否已存在，一个类来编写元数据，一个类来进行抽象，DateTime.Now以便您可以投入时间进行单元测试，为每个包含逻辑的文件插入接口，包含每个类的单元测试，以及一个或多个文件以将所有内容添加到您的DI容器中。 对于中小型应用程序，SOLID非常容易出售。每个人都看到了可维护性的好处和便利。但是，他们只是没有看到SOLID在超大型应用程序中具有很好的价值主张。因此，我正在尝试寻找改善组织和管理的方法，以使我们度过不断增长的痛苦。 我以为基于最近完成的任务，可以更详细地说明文件量的示例。我被赋予一项任务，以在我们的一种较新的微服务中实现某些功能，以接收文件同步请求。收到请求后，服务将执行一系列查找和检查，最后将文档以及2个单独的数据库表保存到网络驱动器。 要将文档保存到网络驱动器，我需要一些特定的类： - …

49 c#  coding-style  dependency-injection  solid  single-responsibility 

我一直想知道在OOP中使用基于名词的动词是否合法。 我遇到了这篇精彩的文章，尽管我仍然不同意它的观点。 为了进一步解释该问题，文章指出，例如，不应有一个FileWriter类，但是由于编写是一种动作，因此它应该是该类的方法File。您将认识到它通常与语言相关，因为Ruby程序员可能会反对使用FileWriter类（Ruby使用方法File.open来访问文件），而Java程序员则不会。 我个人的观点（是的，非常谦虚）是，这样做会违反“单一责任”原则。当我用PHP编程时（因为PHP显然是OOP的最佳语言，对吗？），我经常会使用这种框架： <?php // This is just an example that I just made on the fly, may contain errors class User extends Record { protected $name; public function __construct($name) { $this->name = $name; } } class UserDataHandler extends DataHandler /* knows the pdo object */ { public function …

42 object-oriented  solid  single-responsibility 

我最近遇到了一个看似微不足道的建筑问题。我的代码中有一个简单的存储库，其名称如下所示（代码在C＃中）： var user = /* create user somehow */; _userRepository.Add(user); /* do some other stuff*/ _userRepository.SaveChanges(); SaveChanges 是一个简单的包装程序，用于将更改提交到数据库： void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); } 然后，过了一段时间，我需要实现新的逻辑，该逻辑每次在系统中创建用户时都会发送电子邮件通知。由于有许多来电_userRepository.Add()和SaveChanges系统的时候，我决定更新SaveChanges如下： void SaveChanges() { _dataContext.SaveChanges(); _logger.Log("User DB updated: " + someImportantInfo); foreach (var newUser in dataContext.GetAddedUsers()) { _eventService.RaiseEvent(new UserCreatedEvent(newUser )) } …

40 architecture  single-responsibility  event 

我有一种更新数据库中员工数据的方法。该Employee班是不变的，所以“更新”的对象实际上手段来实例化一个新的对象。 我希望该Update方法返回Employee具有更新数据的新实例，但是由于现在我可以说该方法的责任是更新员工数据，并从数据库中获取新Employee对象，这是否违反了单一职责原则？ 数据库记录本身已更新。然后，实例化一个新对象来表示该记录。

37 single-responsibility 

根据Microsoft文档，有关Wikipedia SOLID原则的文章或大多数IT架构师，我们必须确保每个班级仅负一个责任。我想知道为什么，因为如果每个人似乎都同意这条规则，那么似乎没人会同意这条规则的原因。 一些人引用了更好的维护，有人说它提供了简单的测试，或者使类更加健壮或安全。什么是正确的，实际上是什么意思？为什么它可以使维护更好，测试更容易或代码更健壮？

37 design-patterns  architecture  solid  single-responsibility 

单一责任原则基于高度凝聚力原则。两者之间的区别在于，具有高度凝聚力的班级具有一系列密切相关的职责，而遵守SRP的班级仅具有一个职责。 但是，我们如何确定某个特定类别是否具有一组职责并因此具有高度凝聚力，或者它是否仅具有一项职责并因此遵守SRP？换句话说，是不是有些主观，因为有些人可能认为一类非常细化（因此相信该类遵循SRP），而另一些人可能认为它不够细密？

34 design-patterns  single-responsibility  cohesion 

想要改善这篇文章吗？提供此问题的详细答案，包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。 此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 为了便于讨论，下面是一个示例函数，该函数逐行打印给定文件的内容。 版本1： void printFile(const string & filePath) { fstream file(filePath, ios::in); string line; while (std::getline(file, line)) { cout << line << endl; } } 我知道建议函数在一个抽象级别上做一件事。对我来说，尽管上面的代码几乎做一件事，而且是原子的。 一些书（例如Robert C. Martin的Clean Code）似乎建议将上述代码分解为单独的函数。 版本2： void printFile(const string & filePath) { fstream file(filePath, ios::in); printLines(file); } …

21 c++  coding-style  single-responsibility 

将该原理定义为具有更改理由的模块。我的问题是，在代码实际开始更改之前，这些更改原因肯定是未知的吗？几乎每一段代码有许多原因，它可能会可能改变，但肯定尝试预见所有的这些设计和代码考虑到这一点最终会很差代码。仅在开始请求更改代码时才真正开始应用SRP，这不是一个更好的主意吗？更具体地说，当一段代码由于多个原因而多次更改时，因此证明它具有多个更改原因。尝试猜测更改的原因听起来很反敏捷。 一个示例是一段打印文档的代码。提出了将其更改为打印为PDF的请求，然后再次请求将其更改为对文档应用某些不同的格式。在这一点上，您有证据证明有多个原因需要更改（并且违反了SRP），并且应该进行适当的重构。

20 design-patterns  single-responsibility 

a）SRP和SoC有什么区别？也许这SRP在类级应用，而SoC的可在应用系统，子系统，组件，类或功能水平。 b）如果对a）的回答为“是”，那么在类级别应用的SoC是否是SRP的同义词？ 谢谢

19 design-patterns  single-responsibility