Tag: 设计模式

Swift中的设计模式:第二部分-行为设计模式

在该系列的第一篇文章中,我讨论了创意设计模式。 现在,我将描述另一组称为行为设计模式的模式。 行为设计模式处理对象之间的交互方式。 它描述了对象之间如何进行通信,以及如何在不同对象之间破坏任务的步骤,从而提供了更大的灵活性并使得代码更具可测试性。 让我们跳到以下10个行为设计模式: 1.责任链 责任链是一种行为设计模式,可让我们在一系列处理程序之间传递请求,其中每个处理程序都决定处理请求或将请求沿着处理链传递。 有一个名为“ 级别”的枚举将“体育”管理细分为三个级别:州,国家和国际。 首先,让我们创建一个名为Sports的类,它将仅保留当前的体育管理水平。 然后,我们有了称为GameManagement的协议,该协议可以沿处理程序链传递责任。 StateSportsTeam , NationalSportsTeam和InternationalSportsTeam类实现了此协议。 如果运动级别不属于他们的管理层,他们会将责任转移给更高的管理层(或管理人员链)。 在操场上运行代码: 让 stateSportsTeam = StateSportsTeam() 让 nationalSportsTeam = NationalSportsTeam() 让 internationalSportsTeam = InternationalSportsTeam() stateSportsTeam.nextLevelManagement =国家运动队 nationalSportsTeam.nextLevelManagement = internationalSportsTeam let sports1 =体育(级别:Level.international) stateSportsTeam.manage(sports:sports1) let sports2 =体育(级别:国家级) stateSportsTeam.manage(sports:sports2) let sports3 =体育(等级:Level.state)stateSportsTeam.manage(体育:sports3) 输出: 由国际体育管理公司管理 由国家体育总局管理 由国家体育总局管理 2. 命令模式 在命令模式中,将执行命令的类(称为Invoker )与产生命令的类( ConcreteCommand )和知道如何执行该命令的类( Receiver […]

Swift解决方案:复合

复合模式涉及集合和单个对象的树层次结构。 在上面的插图中,我们有一个文件夹和mp3的目录。 文件夹仅包含文件数组。 每个文件夹的集合可以包含mp3和其他文件夹的混合。 该插图很好地对应于我们定义的每个部分: 层次结构->目录 收集对象->文件夹 单个对象-> mp3文件 它允许客户以相同的方式对待每个层次结构元素。 层次结构中的所有文件共享一个公共接口,而不管它是文件夹还是mp3。 例如,mp3和文件夹都是可以重命名,移动和复制的文件。 因此,可以合理地期望符合要求实现类文件行为的协议。 重要的一点是,客户可以统一对待小组和单个部分。 在使用每个文件之前,无需经常对其进行类型检查。 这是使元素派生自相同协议或基类的直接结果。 UML 组件 :为集合和单个对象提供公共接口的抽象。 树中的所有元素都必须派生自组件协议或基类。 基元 :以前称为“单个对象”。基元只是树中不包含子级成分的成分。 Composite :以前称为“集合对象”。Composite是包含组件数组的对象。 虽然Composite对象和Primitive对象共享相同的接口,但是Composites包含其他方法来管理其子级。 请注意:有几种方法可以引用我们的具体组件: 我个人更喜欢“复合”和“原始”这两个术语。接下来,让我们进入代码吧! 实作 在我们的示例中,我们将向公司部门分配奖金,最终将其发放给员工。 在这种情况下,部门和员工分别充当我们的组合和基元。 零件 protocol Payee { var name: String { get } var bonusAmount: Double { get } func receive(bonus: Double) } 首先,我们为复合对象和原始对象创建一个Payee协议。 这将是我们统一对待他们的手段。 雇员 class Employee: […]

iOS开发中的传统MVC和MVC

简短明了,让我们直接看一下传统MVC和iOS中MVC的图表。 在传统的MVC中,视图对象可以通过采用“主观观察者”设计模式来注册模型对象的状态更改事件,一旦视图对象感兴趣的模型对象的状态更改,视图对象就会得到通知。 在iOS中,我们应该努力避免视图对象与模型之间的直接交互。 视图对象应始终通过控制器对象来了解模型对象中的更改。 好吧,就是这样。 以上是我想在本文中谈论的主要内容,但是如果您想获得更多详细信息,可以继续阅读。 Model-View-Controller是一种非常高级的体系结构设计模式,它认为存在三种类型的对象:模型对象,视图对象和控制器对象。 它定义了这些类型的对象在应用程序中扮演的角色及其通信线路。 模型是模式的核心组成部分。 它代表特殊的知识和专长,并根据问题域表达应用程序的行为。 它们保存应用程序的数据,并定义处理该数据的逻辑。 设计良好的MVC应用程序将其所有重要数据封装在模型对象中。 一旦将数据加载到应用程序中,任何属于应用程序持久状态的数据(无论该持久状态存储在文件还是数据库中)都应驻留在模型对象中。 因为它们代表与特定问题领域相关的知识和专长,所以它们倾向于可重用。 理想情况下,模型对象与用于呈现和编辑它的用户界面没有显式连接。 例如,如果您有一个代表一个人的模型对象(例如您正在写通讯录),则可能要存储生日。 存储在您的Person模型对象中是一件好事。 但是,存储日期格式字符串或其他有关如何显示该日期的信息可能更好。 视图对象知道如何显示,并且可能允许用户编辑应用程序模型中的数据。 该视图不应负责存储其显示的数据。 (当然,这并不意味着视图从不实际存储其显示的数据。出于性能原因,视图可以缓存数据或执行类似的操作)。 视图对象可以负责仅显示模型对象的一部分,整个模型对象甚至许多不同的模型对象。 视图有很多不同的种类。 视图对象倾向于可重用和可配置,并且它们在应用程序之间提供一致性。 在iOS中,UIKit框架定义了大量视图对象,并在Interface Builder库中提供了许多视图对象。 通过重用UIKit的视图对象(例如UIButton对象),可以确保应用程序中的按钮的行为与其他任何iOS应用程序中的按钮一样,从而确保了各个应用程序在外观和行为上的高度一致性。 控制器对象充当应用程序的视图对象与其模型对象之间的中介。 控制器通常负责确保视图可以访问他们需要显示的模型对象,并充当视图了解模型更改的渠道。 控制器对象还可以为应用程序执行设置和协调任务,并管理其他对象的生命周期。 在iOS MVC设计中,当用户输入值或通过视图对象指示选择时,该值或选择将传达给控制器对象。 控制器对象可能以某种特定于应用程序的方式解释用户输入,然后要么告诉模型对象如何处理此输入(例如,“添加新值”或“删除当前记录”),要么可能具有模型对象在其属性之一中反映了更改的值。 基于相同的用户输入,某些控制器对象可能还会告诉视图对象更改其外观或行为的某个方面,例如告诉按钮禁用自身。 相反,当模型对象发生更改时(例如,访问新的数据源),模型对象通常会将更改传达给控制器对象,然后控制器对象请求一个或多个视图对象进行相应的更新。 除了将应用程序分为三类之外,模型-视图-控制器设计还定义了它们之间的交互。 模型存储数据,该数据根据来自控制器的命令检索并显示在视图中。 视图基于模型的更改为用户生成新的输出。 它还可以向其关联的视图发送命令以更改视图的模型表示形式 以下准则适用于应用程序设计中的模型-视图-控制器注意事项: 设计良好的MVC应用程序的目标应该是使用(理论上至少)可重用的尽可能多的对象。 特别是,视图对象和模型对象应具有高度可重用性。 特定于应用程序的行为通常尽可能地集中在控制器对象中。 尽管可以使视图直接观察模型以检测状态变化,但是最好不要这样做。 视图对象应始终通过中介控制器对象来了解模型对象中的更改。 努力限制应用程序类中的代码依赖性。 一个类对另一个类的依赖性越大,可重用性就越差。 具体建议因所涉及的两个类别的MVC角色而异: —视图类不应依赖于模型类(尽管某些自定义视图可能不可避免)。 —除其他模型类外,模型类不应依赖任何其他内容。

如何拆卸大量Singleton iOS应用

一生中至少有一个iOS开发人员至少从一个年轻的人或其他人那里继承了一个遗留项目,而当iOS开发成为独立开发人员的黄金竞赛时,其他人曾编写过代码。 那时,我们中只有少数人关心测试,可测试性,体系结构或模式。 只有大量的视图控制器,关心限制崩溃的数量,关心无限数量的功能和单例。 有很多单身人士。 Singleton非常容易用Swift中的1行代码和Objective C中的5行代码来实现,易于从应用程序中的任何地方调用,并且最好是弄乱代码以防止单元和UI测试。 本文的目的是为您提供一种有效且快速的工具,以解开任何单身汉,无论数量多少。 我将使用一个代码片段来给出我上面所描述的示例,并模拟3个单例服务和一个示例视图控制器。

Swift中的原型设计模式

通过复制现有对象的所有属性并创建独立的克隆,原型模式用于实例化新对象。 当新对象的构造效率低下时,此做法特别有用。 想象一下,下面有一个SmartPhone类: 现在我们需要创建此类的5个实例,如下所示: 我们可以很容易地意识到许多实例具有相同的属性,因此我们经常复制代码行,然后以不同的方式编辑任何属性。 没关系,但不是经过优化且容易出错。 让我们尝试将Prototype模式应用到下面的SmartPhone类中: 我们声明一个带有默认可选参数的克隆 func与属性相同。 该函数通过复制现有实例的所有属性返回一个新实例,然后根据需要修改某些属性。 现在创建5个实例作为波纹管: 我们不再需要通过调用设计的初始化程序来初始化新实例,只需“克隆”当前实例然后对其进行修改! 就这样! 原型模式非常易于理解,也易于通过其他编程语言实现。 当新对象的构造效率低下时,此功能特别有用。 如果您有任何疑问,请留下您的赞赏,感谢您的阅读!

VIPERtasarımpaterni nedir?

吉里斯 Apple iOS的MVC模式,可以帮助您解决MVC的问题。 1996年MVC足球比赛将在MUL 1996举行。 Microsoft网络模型Web窗体Web窗体MVC模式2009年窗体的窗体。 iOS的MVC模式的MVC模式的ihtiyaçlarıkarşılamamayabaşladı。 位置视图控制器的位置已过时。 业务逻辑模型业务模型模型业务层数据库—数据模型sade hale getirildi。 她的母亲是孩子,是孩子,是孩子,是孩子,是孩子,她的孩子,孩子,孩子,孩子,孩子,孩子,孩子,孩子,孩子。 an MVC haricinde MVP,MVVM和VIPERtasarımpaternleri var。 在iOS上的应用程序在VIPER上运行的时候,会出现inceleyelim。 VIPER mimarisi nelerdenoluşur? VIPER mimarisiadını视图,交互者,演示者,实体路由器(线框)’ılkharflerindenalıyor。 Bukavramlarınneolduğunakısacabakalım。 视图: VIPER mimarisinde视图被动演示者演示者被动演示。 HangiiçeriğingösterileceğiView’ebağlıdır。 Kullanıcıactionlarıpresenter’ayönlendirir。 交互器:业务逻辑işlemlerininyapıldığıkısımdırveuygulamanınomurgasınıoluşturur。 Bu katmandayapılanişlemlertamamen UI danbağımsızolmalıdır。 主持人:主持人esas olarak查看il ilgili logic’iiçerenkoduiçerir。 用户交互作用的用户数据查看用户交互作用。 查看ile Interactorarasındabirköprügörevigörür。 Bu katmanda视图ile ilgili veyauygulamanın商业kurallarıylailgili kodbulunmamalıdır。 实体:交互模型tarafındankullanılan模型nesneleriniiçerir。 Entity’lerin sadece Interactortarafındankullanılmasıçokönemlidir。 Interactor asla演示者层’实体模型lerinigöndermez。 路由器: Hangiekranlarınne zamangösterileceğinibelirlendiğiuygulamageçişakışınbulunduğukatmandır。 […]

实用的iOS应用架构

最近,我一直在阅读许多有关应用程序体系结构的文章。 有很多这样的文章,有很多不同的见解和解决方案。 开发人员分享他们的经验,优缺点可能会帮助我们决定在未来的项目中走哪条路,这是很好的。 我同意,有许多很好的架构,经过精心设计,并具有很好的关注点分离,可以解决其他方法的弊端。 但是,我也认为没有适合所有项目的应用程序架构。 我们如何衡量架构对项目是否有利? 好吧,我认为此评估中有几个相关参数。 评估架构 首先,应将应用程序的组件合理组织和分离。 他们不应该对其他组件的内部细节了解太多。 其次,正如鲍伯叔叔所说的那样,体系结构应该对项目的业务领域“尖叫”。 它是运输应用程序吗? 也许一个金融机构? 这是您从项目中获得的信息,只需以新手的身份快速浏览一下代码即可。 拥有不言而喻的架构对于维护和增长产品至关重要,尤其是在增加人员时。 然后,我们当然具有可伸缩性。 添加更多功能有多容易/难? 拥有一个优雅的解决方案可能会在将来为我们节省大量时间和金钱。 另一个参数是架构如何适合业务领域的要求。 它是繁重的数据驱动的应用程序吗? 它有很多需要用户输入的表格吗? 我们将要构建的应用程序的复杂性是什么? 是“ 5个屏幕”应用程序还是“ 50个屏幕”应用程序? 需要考虑的另一件事是开发团队的效率。 团队能否迅速了解新架构和可能不同的概念? 他们将能够独立处理功能而不会阻塞自己吗? 想象一下,只有一个故事板的架构,团队中的每个人都必须在用户界面上工作。 合并地狱等待发生。 测试是体系结构决策中的另一个重要元素。 我们要测试哪些关键组件? 在测试方面,我属于认为必须只测试值得测试的零件的小组。 我不喜欢做很多无用的测试,只是增加了代码覆盖率。 代码覆盖率只是一个欺骗性的统计信息。 您可能有90%的测试覆盖率,但是错过了关键部分。 在另一个极端,我看到了设计完美的项目,这些组件具有很好的隔离性,覆盖率为零。 在决定应用程序体系结构时,这使我想到了另一个关键部分-上下文。 项目的截止日期和预算是多少? 我们必须在质量(交货时间)上进行哪些权衡? 工程师需要更多时间以最优雅的方式设计和实施项目,而销售则需要更快的时间。 每个人都有自己的利益,我们必须意识到双方的平衡。 低质量的产品不会持续很长时间,但是市场上可能不再需要后期产品。 这就是为什么我认为在进行体系结构决策时,我们需要务实,中立和对全局的理解,而对我而言,这是做出此类决策的动力。 我们不需要偏向任何一种方法,也不应抛弃其他方法。 这只会限制我们的工具集,并在做出决策时缩小我们的可能性。 好老的MVC 我很困惑为什么这么多人只是放弃了Model-View-Controller模式。 他们代表Massive View Controllers。 它不适用于大型项目。 好吧,我已经看到(并从事过)非常大的项目,这些项目很好,干净且可维护,并且遵循Model-View-Controller。 我们有很多概念和模式可以帮助我们减小视图控制器的大小,例如委派,组合,依赖注入,协议,纯函数,服务/实用程序类,导航中心。 有了这些技术,测试也不是那么困难。 […]

使用VIPER模式进行iOS开发的干净架构

当开始一个iOS项目时,开发人员除了要达到应用程序的目的之外,还将首先关注的障碍之一是,他们需要的Cocoapods将是如何组织代码,以及可能遵循的设计模式。 尽管大多数开发人员会坚持使用久经考验的真正的MVC(模型-视图-控制器)或MVVM(模型-视图-视图模型),但是有一种聪明的模式称为VIPER,许多人都不知道。 VIPER可能会改变您习惯用于iOS平台的开发方式,并且像大多数事物一样,它具有积极和消极的作用。 通常的嫌疑 首次开始iOS开发时,开发人员将听到很多有关MVC或Model-View-Controller的信息。 这种Apple认可的架构模式随处可见,包括Apple的UIKit,大多数教程示例应用程序以及当今App Store上的大多数应用程序。 顾名思义,MVC分为三个职责: 模型:应用程序的数据和操纵该数据的逻辑。 视图:用户操作的用户界面。 控制器:控制模型和视图之间的逻辑。 如果您正在开发第一个应用程序或在一个小型团队中工作,那么MVC可以很好地工作,但是随着应用程序的发展,开发人员开始开玩笑地将MVC称为“大型视图控制器”。随着时间的流逝,越来越多逻辑被推到控制器中,控制器变得becomes肿且不可测试。 这就是VIPER模式试图解决的问题。 什么是VIPER? VIPER模式是一种遵循单一职责原则的干净架构。 VIPER努力将应用程序的逻辑划分为不同的责任层。 与MVC相比,VIPER更进一步,它分为五个职责: 视图:显示来自演示者的信息,并将用户交互发送回演示者。 交互者:检索实体,并包含特定用例的业务逻辑。 它们与视图无关,可以由一个或多个演示者使用。 演示者:处理为显示准备的内容并拦截用户交互。 实体:简单的数据模型对象。 路由器:处理应显示哪些屏幕以及何时显示的导航逻辑。 实施VIPER时,每个功能或模块都将遵循上述结构。 由于该应用程序的逻辑将分为多个较小的组件,因此视图现在变得更明亮,逻辑也变得更具可测试性。 VIPER的流程 VIPER的基本流程非常简单。 路由器将用户带到新的视图,该视图通知演示者它需要数据,演示者向交互器询问数据,交互器检索实体(从网络请求或本地数据库),交互器将实体发送到演示者,演示者从实体创建视图模型,演示者将视图模型发送到视图,然后视图向用户显示必要的数据。 实施VIPER 为了演示以VIPER模式创建模块,让我们假设我们正在创建一个显示汽车表的应用程序。 每个单元格都会显示汽车的品牌和型号。 用户将能够点击一个单元格并查看汽车的详细信息,或者他们可以单击“创建新汽车”按钮将新汽车添加到列表中。 实施新模块时,我发现自下而上的工作会更容易,因此我们将从定义实体开始。 实体 由于该应用程序正在处理汽车,因此让我们创建一个简单的struct对象,该对象将包含一些基本信息: car对象。 car对象是我们的API服务将返回给我们的东西。 它包含基本信息,例如汽车的ID,品牌,型号和内饰。 但是,当我们要显示有关汽车的信息时,由于表格单元格仅需要显示汽车的制造商和型号,因此不需要包括所有信息。 因此,我们可以创建一个快速视图模型来仅代表汽车的制造商和模型。 快速视图模型将在Presenter中创建,并传递回View。 互动者 现在我们的实体已经建立,让我们为其创建业务逻辑或“用例”。 我们的表格视图将需要使用API​​服务中的汽车填充。 因此,我们将创建一个Interactor,用于处理从API检索汽车并将其发送到Presenter。 为此,我们声明了一个名为getCars的协议方法,该方法将使用我们的API服务获取汽车并将其返回。 由于我们的应用程序非常简单,因此我们不需要其他用例(尽管大多数实际应用程序都有多个用例)。 主持人 有了Interactor,我们现在有了一种方法来检索最终将要显示的汽车。 如前所述,演示者负责对用户的输入做出反应并为显示准备内容。 我们的应用程序描述中提到需要显示汽车(制造商和型号),显示汽车详细信息的能力以及创建新汽车并将其添加到表格中的能力。 接下来,我们将创建一个Presenter,使我们能够做到这一点。 为了展示汽车,我们添加了showCars方法,该方法使用我们先前创建的Interactor检索汽车,然后从这些对象创建简单的视图模型,这些对象将用于视图中特定类型的单元格。 接下来的两个方法showCarDetail和showCreateCarScreen将使用Router(将在下面创建)来将用户导航到正确的屏幕。 我们的视图将使用以下三种方法来启用功能。 […]

依赖注入

依赖注入是一个概念,用于删除耦合,明确定义和区分类和对象的职责,增加透明度并促进单元测试。 听起来很花哨,而且会被行话淹没。 但这确实是简单的设计原则。 依赖注入意味着给对象一个实例变量 依赖注入仅是将依赖注入到对象中,而不是负责创建对象的依赖关系。 让我给您一个示例,使其更清楚,看到该示例后,您意识到我有时使用依赖项注入,但我对此一无所知。 但请放心,这会使我们两个人成为现实。 我将在Swift中举例说明,但是概念可以在任何地方应用。 我们可以通过两种方式设置属性requestManager: 没有依赖注入: 第一种方法是让ViewController实例化RequestManager实例,即,视图控制器负责创建RequestManager实例。 这意味着视图控制器不仅知道RequestManager类的行为。 它还知道它的实例化。 使用依赖注入: 在此选项中,我们将依赖项(RequestManager)实例注入到ViewContoller实例中。 通过注入请求管理器,视图控制器不知道如何实例化请求管理器。 让我们看看其他示例: DataManger类具有一个属性,类型为Serializer?的序列化器。 序列化器是一个协议。 DataManager类负责实例化符合Serializer协议的类型的实例RequestSerializer类。 DataManager类是否应该知道如何实例化Serializer类型的对象? 现在,DataManager类不再负责实例化RequestSerializer类。 它不再分配其序列化器属性的值。 只要符合Serializer协议,我们就可以用另一个轮胎替换RequestSerializer。 DataManager不再了解或关心这些详细信息。 依赖注入的优点: 透明度: 通过注入对象的依赖关系,类或结构的职责和要求变得更加清晰和透明。 通过将请求管理器注入到视图控制器中,我们了解到视图控制器取决于请求管理器,并且视图控制器负责请求的处理和管理。 测试: 依赖注入使单元测试更加容易。 使用模拟对象替换对象的依赖关系非常容易。我们可以创建另一个符合Serializer协议的MockSerializer,并在实例化DataManger类时将其分配给serializer属性。 责任与耦合分离: 数据管理器类无需实例化RequestSerializer实例。 它不需要知道如何执行此操作。 还可以使用协议和依赖项注入来减少项目中的耦合。

Usei Clean Architecture num projeto de duas telas e me arrependi …

ATENÇÃO-Nãoirei abordar或XYZ防守者,nãoéo intuito desta publica por球场,mas sim falar sobre umaexperiênciaque tive dan。 重要信息后,vamos ao que interessa。 Muita classe e pouca entrega? 喜剧明星将在美国清洁运动中发挥重要作用,罗南·道格拉斯·门德斯(Ronan e Douglas Mendes),设计风格的设计者 清洁的原则上的原则性影响者 清洁工,软件工程师,软件工程师,软件工程师,软件工程师,软件结构和设计指南,以及优秀的专家arquitetura etambém设计图案napráticae logo de caravocêvêessa imagem, levanta-se evêque possuiinúmerascamadas quevocênãoestáacostumado,nãoé? Esse semper foi um ponto que discuti muito com Ronan e Douglas,Pois me dava aimpressãoque que que que fazer […]