Tag: 坚实原则

工厂设计模式: 当在实现通用协议或共享通用基类的类之间进行选择时，将使用工厂方法模式。这种模式允许实现子类提供专业化，而无需依赖它们的组件知道这些类的任何详细信息以及它们之间的关系什么是工厂设计模式？工厂方法模式选择一种实现类来满足调用组件的请求，而无需组件知道有关实现类或它们之间的相互关系的任何信息。有什么好处？这种模式巩固了决定选择哪个实现类的逻辑，并防止其在整个应用程序中扩散。这也意味着调用组件仅依赖于顶层协议或基类，而不需要有关实现类或选择它们的过程的任何知识。什么时候应该使用这种模式？当您有几个实现通用协议或从同一基类派生的类时，请使用此模式。什么时候应该避免这种模式？在没有通用协议或共享基类的情况下，请勿使用此模式，因为此模式通过使调用组件仅依赖单一类型来起作用让我们看一下示例：协议JobContactProtocol { func sendRequestResumeEmail（） } struct Contact { 变量名称：字符串 var job：工作初始化（名称：字符串，工作：职位）{ self.name =名称 self.job =工作 } 枚举Job { 案例IOS 案例Android } } IOSJob类：JobContactProtocol { var联系人：联系人 func sendRequestResumeEmail（）{ 打印（“亲爱的\（contact.name）您是ios候选人”） } 初始化（联系人：联系人）{ self.contact =联系人 } } AndroidJob类：JobContactProtocol { var联系人：联系人 func sendRequestResumeEmail（）{ 打印（“亲爱的\（contact.name）您是Android的候选人”） } 初始化（联系人：联系人）{ […]

SRP：单一责任原则: 单一责任原则（SRP）规定，每个软件模块或类都应该有一个且只有一个更改理由。除佛陀本人外，任何人都不承担透露神秘秘密的责任。。。将因相同原因而发生变化的事物聚集在一起。分开那些由于不同原因而改变的事物。鲍勃·马丁难以理解，因此难以维护。重用困难。由于职责在同一个类别中紧密联系在一起，因此很难在不损害其他职责的情况下更改其中一项职责（刚性），并且最终可能破坏软件的其他部分（脆弱性）。高耦合，即该类具有过多的依赖性，因此，由于其他类的更改（同样是脆弱性），因此更容易发生更改。让我们考虑一些可能需要分开的职责： HTTP API调用 -如果需要修改标头或基本URL，则只能将其修改为HTTPClient 。无需为此其他文件做任何更改。创建视图状态-创建视图状态应该由工厂或转换器负责。验证 — 所有验证逻辑都应封装到单独的Validation类中，以便将来只有一个人负责修改验证逻辑或添加新行为。坚持不懈通知错误处理记录中格式化解析中制图导航商业逻辑创建视图 https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html https://www.scaledrone.com/blog/solid-principles-for-becoming-a-better-ios-swift-developer/ 单一责任原则@清洁代码联盟聚会，来自Eyal Golan 感谢您阅读文章。您可以在以下位置找到我： Linkedin： Aaina Jain 推特： __aainajain

适用于iOS开发人员的SOLID原则: 接受原则，而不是架构这些原则一起使用时，旨在使程序员更有可能创建易于维护和随时间扩展的系统。 SOLID Principles是用于以适当方式开发软件以避免错误设计的编码标准。它是由Robert C Martin推广的，并在面向对象的设计范围内使用。如果正确应用，它将使您的代码更具可扩展性，可维护性，逻辑性和可读性。 SOLID原理中的原理是什么？ SOLID原则不是规则，不是法律，也不是完美的真理。这是对良好的软件设计的建议，该软件设计既不严格也不脆弱。对原理和模式的了解使您有理由决定何时何地应用它们。如果您不了解它们，那么您的决定就会更加武断。 SOLID是五项设计原则的首字母缩写，旨在使软件设计更加易懂，灵活和可维护。 SOLID原理是Martin在2000年提出的。在阅读有关原理时，您将遇到两个术语“刚性”和“脆弱性”。让我们讨论一下它们是什么：刚性：当更改导致相关模块中其他无关的更改时，软件变得难以更改。简单的更改变得昂贵。硬代码是具有依赖性的代码，这些依赖性会在很多方向上产生作用，以至于您无法进行孤立的更改而不更改其周围的所有其他内容。 —罗伯特·马丁例如，您尝试更改数据层中的一些底层细节，突然之间，在为您的View进行格式化的类中遇到了编译错误。如果您经常发现自己几乎触及了项目的所有文件，那么只要您在单个类中进行更改，就会出现僵化代码的症状。易碎性：易碎代码比敏捷代码更糟糕，因为它不会产生编译时错误。修复程序引入了会导致回归问题的新错误。易碎的代码以您无法预测的奇怪方式中断。 —罗伯特·马丁这里解释原理的内容太多了。我将为这些原则提供专门的职位。 S —单一责任原则 O —打开/关闭原理 L-Liskov替代原理 I —接口隔离原理 D —依赖反转原理感谢您阅读文章。您可以在以下位置找到我： Linkedin： Aaina Jain 推特： __aainajain

ISP：接口隔离原理: 根据方法组将Fat协议转换为小型协议接口隔离原则（ ISP）指出：不应强迫客户依赖他们不使用的方法。在设计应用程序时，我们应该关注包含多个子模块的模块抽象。在创建另一个仅包含原始系统子模块的模块时，我们被迫实施完整协议并编写一些虚拟方法。这样的协议被称为胖协议。 ISP帮助我们避免：胖接口不要强迫类实现他们无法实现的方法不要用很多方法污染协议接口隔离原则主张将“胖接口”隔离为较小的且高度紧密的协议，称为“角色协议”。每个“角色协议”都声明一种或多种用于特定行为的方法。因此，客户端只能实施与其方法相关的那些“角色协议”。违反接口隔离原则：当客户端依赖于不使用的方法时，这意味着抽象是错误的。如果ImageMessageView和VideoMessageView实现此协议，则由于图像视图不了解视频播放器，反之亦然，因此将产生开销，因此需要实现虚拟方法来满足编译时错误。使协议方法为可选的另一种解决方案是在协议扩展中创建虚拟方法，然后覆盖特定类中的必需方法。遵循接口隔离原则：通过遵循ISP，我们可以将上述协议分为2部分：现在， VideoMessageView可以只符合DeepLinkVideoMessage 。将来如果需要删除视频消息，我们可以简单地删除此协议并查看而无需触及其他代码。与ImageMessageView相同