Tag: 设计模式

建筑设计模式：VIPER

抱歉，延迟了，但是在阅读了文章之后，我意识到NasaAPOD应用程序的当前安装方式对于实施VIPER并不是很有趣。 应用程序内部需要进行更多的交互，因此我回到了MVC，MVVM和MVP来全面实现相同的功能。 我所做的是添加了“收藏夹”功能，该功能只是将您的收藏夹移到表视图的顶部（实际上并没有保存任何内容）。 因此，至少MVP和VIPER现在更加有趣了。 我不确定的一件事是如何为单元设置演示者/交互者。 似乎应该有一个presenter / interactor组件，因为它还可以处理图像缓存。 但是我不能完全考虑如何确保我没有制造大量或可能泄漏的材料。 auth0.com教程肯定有很大帮助，所以我的VIPER应用程序很大程度上基于它。 我发现有些奇怪，但根据以前的工作是很正常的，是当用户点击某些内容时，它会通过演示者而立即返回视图。 例如，用户点击信息图标，视图告诉演示者用户点击，演示者返回查看告诉其发生点击并显示详细信息。 auth0网站还建议您不要手动创建所有文件（我做了🙃），他们建议使用工具为您生成文件。 因为我决定手动创建所有文件，所以我确实很难考虑应用程序所需的每个文件的所有交互和协议。 如此之多，以至于我把它抽了出来。 我所做的一件事有些不同，那就是该应用程序如何设置演示者和交互者。 auth0站点将这些变量公开，但是我想尽可能地保持所有私有。 所以我添加了attachView(viewInteractor:) ， attachInteractor(interactor:)和attachPresenter(presenter:)函数。 您可以在下面看到完整的应用程序。 ashleyng /建筑设计模式 通过在GitHub上创建一个帐户来为ArchitectureDesignPatterns开发做出贡献。 github.com 到目前为止，这是最有趣的学习模式，并且肯定有很多设置需要使它起作用。 话虽如此，我现在不认为VIPER是我的选择。 我仍然不太了解Router部分，但是如果没有Router ，也许还有VIPER的味道？ 比较MVVM和Viper架构：何时使用一种或另一种 TL; DR：设计良好的体系结构对于长期保持项目可维护性很重要。 在这篇文章中… auth0.com 视图，交互器，演示者，实体和路由器 视图 —界面层（UIKit文件）。 视图负责显示演示者要求他们执行的操作，并将用户输入回传给演示者 Interactor —负责从模型层（使用网络或本地数据库）获取数据，并且其实现完全独立于用户界面。 演示者 —查看逻辑以格式化要显示的数据。 这是MVVM中ViewModel完成的工作的一部分。 演示者从交互器接收数据，创建视图模型并将其携带到视图。 还对用户输入做出反应，请求更多数据或将其发送回交互器 实体 -模型层职责的一部分。 没有业务逻辑的纯数据对象。 由交互者管理。 路由器 -应用程序的导航逻辑。 示例：如果必须在iPad应用程序中重用相同的iPhone视图，则唯一可能改变的是视图的显示方式。 这使您的其他图层保持不变。 示例应用 视图 […]

iOS：设计模式

设计模式是针对软件设计中常见问题的可重用解决方案。 它们是旨在帮助您编写易于理解和重用的代码的模板。 最常见的可可设计模式： 创作性 ：单身人士。 结构 ：装饰器，适配器，外墙。 行为的 ：观察者，和，纪念品 让我们开始吧…… 🏄🏻 正面 Facade设计模式提供了到复杂子系统的单个接口。 无需向用户提供一组类及其API，而是仅公开一个简单的统一API。 当使用大量类时，尤其是当它们使用复杂或难以理解时，此模式是理想的选择。当外观下的类可能会更改时，这也很有用，因为外观类可以保留相同的API事情在幕后发生变化。例如，如果您想替换后端服务的日子到了，您将不必更改使用API​​的代码，而只需更改Facade中的代码即可。 装饰器 装饰器模式可以动态地 向对象添加行为和职责，而无需修改其代码。 它是子类化的替代方法，在子类化中，您可以通过将类与另一个对象包装在一起来修改类的行为。 在Objective-C中，此模式有两种非常常见的实现： 类别和授权 。 在Swift中，此模式还有两种非常常见的实现： 扩展和委托 。 委托：用于将实现特定的行为排除在通用类之外。 iOS中的许多UI元素都使用委托来控制其行为，例如UIScrollView。 UIScrollView类不知道应该滚动什么，因为那是应用程序特定的任务。 因此，要通知应用程序滚动事件，它将使用UIScrollViewDelegate。 应用程序可以实现委托，然后拦截由UIScrollView发送给它的滚动事件。 纪念品 在Memento模式中， 可以将您的内容保存在某处 。 稍后，可以在不违反封装的情况下恢复此外部状态。 也就是说，私有数据保持私有。 Memento模式的实现示例是存档，序列化和 状态恢复 。 适配器 适配器设计模式将类的接口转换为客户期望的另一个接口 。 Adapter使类可以协同工作，否则由于接口不兼容而无法实现。 它将客户端与目标对象的类分离。 苹果使用协议来完成这项工作。 您可能熟悉UITableViewDelegate ， UIScrollViewDelegate ， NSCoding和NSCopying等NSCopying 。 例如，使用NSCopying协议，任何类都可以提供标准的copy方法。 观察者 观察者设计模式定义了对象之间的一对多依赖关系，因此当一个对象改变状态时，其所有依赖关系都会被通知并自动更新。 观察者模式本质上是一个发布和订阅模型，其中主题及其观察者是松散耦合的。 […]

Swift中的设计模式：第一部分-创新设计模式

设计模式是针对软件工程问题的不同解决方案。 没有它们就可以构建软件 但要困难得多。 我将发布有关设计模式的三部分系列。 在这篇文章中，我将讨论创意设计模式。 创建设计模式是处理对象创建机制的设计模式，试图以适合情况的方式创建对象。 对象创建的基本形式可能会导致设计问题或增加设计的复杂性。 创新设计模式通过某种方式控制此对象的创建来解决此问题。 资料来源：Wikipedia.org 在这里，我们将讨论五个创新设计模式以及如何快速使用它们。 这种类型的设计模式用于通过克隆称为原型的现有对象来实例化新对象。 您会看到Apple类实现的Fruit协议的抽象克隆函数，该函数实际上返回当前对象本身。 让我们在操场上运行上面的代码。 //创建原型 let prototype = Apple（count：4）//创建现有对象的副本 让redApple：Apple = prototype.clone（）为！ 苹果 redApple.count // 4 //添加自己的属性 redApple.set（价格：“ $ 2”） redApple.price // $ 2 //创建现有对象的副本 让greenApple：Apple = prototype.clone（）为！ 苹果 greenApple.count // 4 //添加自己的属性 greenApple.set（价格：“ $ 4”） greenApple.price // $ 4 • 克隆对象时，该对象的所有属性都将复制到 另一个对象。 •当您需要创建对象而又不知道该类的层次结构时，应使用此设计模式 这是最常用的设计模式。 基本上，它只是抽象对象的创建。 […]

使用Swift使访客模式过时

访客模式是来自臭名昭著的“四人帮”的设计模式，我曾多次使用它来解决一些棘手的问题。 它主要解决了问题，但是我不能说我曾经喜欢访客设计模式。 它产生了许多自己的问题，您可以通过创建更复杂的访问者模式来解决。 这是我与模式有关的问题之一。 它很快变得复杂，我讨厌编写复杂的代码。 让我们看看一些情况，这些问题是我在C ++中使用访问者模式解决的，以及在使用Swift编写相同代码时如何完全避免使用访问者。 谓词编辑器 谓词是返回布尔值的运算符或函数。 以下是将两个表达式与比较运算符组合在一起的谓词： a + 3> 4-2b 在内存中，我们可以将其表示为对象树。 这里的每种颜色代表对象或类的不同类别。 在Mac OS X上，有许多应用程序示例支持通过GUI编辑器创建谓词。 一个示例是iTunes中的智能播放列表。 想象我们想用C ++创建这样的编辑器。 因此，我们需要一个GUI来允许我们组成谓词。 一旦获得谓词，我们可能希望过滤MP3歌曲列表，以查找可以归类为90年代音乐的歌曲。 让我们考虑一些简单的事情。 我们如何表达25首播放最多的歌曲的谓词？ 以下是iTunes的一种方法。 因此，让我们将其范围缩小到谓词： 播放次数> 0 在C ++代码中，我们可以表示为： 表达式* plays = AttributeExpression（“ plays”）; 表达式*零= ConstantExpression（0）; 谓词* pred = LargerThanPredicate（plays，zero）; playsongs = allsongs.filter（pred）; 因此，要使用谓词，我们要处理Expression和Predicate对象。 但是，要使用GUI构建谓词，我们需要不同的对象来表示各个行的GUI。 我们可以有一个PredEditorRow类来代表每一行的GUI。 但是，有许多不同种类的行。 谓词可以任意嵌套，因此我们需要复合行。 让我们重新访问我们的第一个音乐智能列表。 90年代的音乐谓词看起来像这样： 1990 <年<1999 […]

Swift中的设计模式集合

我发现很多人通过搜索引擎访问了我在Swift中有关设计模式的文章。 因此，我在本文中收集了它们，以使读者可以轻松找到它们。 谢谢。 创作模式 Swift World：设计模式-简单工厂 如果我们想学习一种编程语言，我们需要忍受它。 这意味着尽可能多地使用Swift。 今天… medium.com Swift World：设计模式-工厂方法 您还记得我们在上一篇文章中讨论的简单工厂模式吗？ medium.com Swift World：设计模式-Singleton 辛格尔顿在可可中非常受欢迎。 我们可以找到不同的用例。 以下是两个示例。 medium.com Swift World：设计模式-生成器 通常，在制造汽车时，我们首先制造每个零件，然后组装它们。 作为客户，我们不需要… medium.com Swift World：设计模式-抽象工厂 今天我们将讨论抽象工厂模式。 它处理更复杂的用例。 众所周知，轿车… medium.com 结构模式 Swift World：设计模式-适配器 我们已经完成了创建模式，并将在本文中介绍结构模式。 从字面上看，结构性… medium.com Swift World：设计模式-桥梁 您还记得我们的汽车系统结构吗？ 我们有一个协议和不同的实现方式，例如下面的代码。 medium.com Swift World：设计模式-装饰器 装饰器是一种结构化模式，可在运行时向类或实例添加新功能。 与继承相比，它具有… medium.com Swift World：设计模式-外立面 从字面上看，facade表示 medium.com Swift World：设计模式-代理 今天，我们将讨论代理模式。 在这种模式下，代理是一个对象，可以帮助我们访问另一个对象。 […]

iOS中的MVP设计模式

我确定您已经熟悉MVC，但是您也感到有些痛苦，例如： 难以在View和ViewController上进行测试 Viewcontroller处理一切时变得越来越大 今天，我要谈谈另一种架构模式MVP 。 什么是MVP 模型视图呈现者（MVP）是模型视图控制器（MVC）架构模式的派生产品，主要用于构建用户界面。 —维基百科 这里的被动视图部分包括视图和视图控制器。 该模型是放置数据的地方，并定义了处理该数据的逻辑和计算。 view（view + viewcontroller）是一个被动界面，可以简单地显示数据，并接收将其处理的用户动作呈现给演示者。 演示者是模型和视图之间的中介者。 所有演示逻辑都应放在此处。 代码说明 //模型 优点 降低代码复杂度 易于执行单元测试 视图控制器不再庞大

Kendi的李尔设计模式-第1部分创建模式

每个想成为高级开发人员的初级开发人员，都必须从“设计模式”中学习，该模式是Erich Gamma，Richard Helm，Ralph Johnson i John Vlissides的经典著作。 我不得不承认，我从“设计模式”开始并不容易-毕竟，这是一本充实的抽象指南，也是您必须发展的如此抽象的思维方式。 幸运的是，在这个痛苦的过程中，我有一个同伴，我忠诚的黑人拉布拉多·肯迪（Labrador Kendi），每当我开始入睡时都会叫醒我。 我相信“实践能成为大师”，并且您应该始终以自己的语言来表达抽象以真正理解它。 而且，因为值得与他人分享-我们将与Kendi一起分享有关模式的知识。 那么谁愿意，让我们读… 首先-模式到底是什么？ 它总是从问题开始，必须解决它。 有人找到优化的解决方案，可以在这种情况下使用。 因此，如果您知道该模式，则无需自己发明。 因此，正确识别问题的类型至关重要。 因此，我们将从案例分析开始讨论每种模式。 案号 1-我们要构建不同类型的复杂对象。 这些目的是一个制造过程的结果。 如何在不复制代码的情况下构建这些对象？ 解决方案是使用“构建器”模式，其中复杂的对象创建算法独立于该对象的组件和组件的连接方式，并且构造过程允许创建不同类型的对象。 用例：如果我是狗屋生产的总监（干什么！），我会雇用一名首席建造者来创建狗屋项目。 反过来，这名建筑商会继承其他将完成此项目的建筑商，结果建造了不同类型的狗屋（一间小房子用于贝塞特犬，一间大房子用于拉布拉多犬）。 案号 2-我们希望能够在运行时添加和删除产品。 我们要避免创建与产品类层次结构相对应的工厂类层次结构。 解决方案是使用原型模式。 用例：我们发现狗屋的生产没有回报。 相反，我们购买现成的狗屋。 在订购时，客户会给我们提供首选项，例如“为该颜色绘画”或“在前面添加此标题”。 我们通过将原型克隆与客户的偏好相结合来动态创建新产品。 总结一下： 创建模式有助于保持系统独立于对象创建，组成和表示的方式。 它们封装了系统使用哪些特定类的信息，并隐藏了创建和组成对象的过程。 对复杂对象创建过程的最佳控制是生成器模式。 它会逐步生成产品，并且只有在过程完成后，导演才能从Builder中获取产品。 其他模式只需一步即可创建对象。 工厂方法是一种流行的对象构造函数，当一个类想要将一个任务委托给其他一些辅助类时，该方法特别有用。 工厂方法的缺点是创建了并行的类层次结构（产品类=构造函数类）。 因此，有时最好使用与工厂方法相反的原型模式，该模式通过克隆对象而不是创建新对象来减少类的数量。 此外，原型模式是唯一一种在运行时提供添加和删除产品功能的模式。 本文还没有提到其他设计模式：抽象工厂和单例。

iOS设计模式-第1部分（MVC，MVP，MVVM）

设计模式始终有助于构建可管理，可测试，可重用和优化的软件。 通常，它有助于对软件进行模块化，以使每个组件都是独立的，并承担单个责任。 此外，它们极大地提高了代码的可读性，这在传达软件代码中起着重要作用。 而且，软件开发过程可以大大加快采用已经证明的设计范例的速度。 移动开发人员无法摆脱遵循设计模式所带来的好处。 最初，移动应用程序太小，无法遵循设计或架构模式，因此它们过去一直严格遵循最基本的应用程序。 如今，由于移动应用程序越来越大，几乎可以反映它们的桌面或Web对应部分（从功能上来说），因此它们必须在实际进入开发模式之前考虑设计模式。 最近，我一直亲自或通过网络参加iOS和Swift开发者大会。 每隔一个这样的会议，至少有两到三个关于新兴或公认的设计模式的演讲，尤其是考虑到移动应用程序。 像iOS这样的移动平台已经建议开发人员在其应用程序中遵循MVC（模型-视图-控制器）。 苹果的MVC是原始MVC的修改版，可以很好地与移动应用程序配合使用，但是开发人员社区对此并不满意。 因此，开发人员社区一直在尝试其他软件开发平台中已经实践过的不同设计模式。 我们将看到这样的设计模式被社区广泛接受，并且过渡也相当成功。 像所有其他设计模式一样，这些模式也不适合所有情况。 每个案例都有其优点和缺点，因此，明智地选择案例中的一个是我们的全部责任。 如果没有适合您的工作，开发人员可以根据您的需要帮助您生成新的工作。 我们将介绍iOS开发人员社区中一些最受欢迎的工具，MVC，MVP，MVVM和VIPER。 这篇文章将分为两部分。 MVC（模型-视图-控制器） 让我们从最简单，最常用的一个开始。 苹果始终通过其示例代码始终建议遵循MVC。 如前所述，对Apple形式的MVC进行了一些修改，以更好地适应移动应用程序。 它的一般形式表示如下： 它基本上由一个视图，一个控制器和一个模型组成。 可以将视图想象为某个特定时间点向用户显示的用户界面。 模型是要在视图的组件中显示的数据。 控制器是它们之间的桥梁。 这三个，总是保持一种关系。 控制器拥有一个视图，并将一个模型与之关联。 该视图负责向用户显示其用户界面。 最终，视图将源自用户界面的动作传递给Controller。 动作是用户启动的，例如，用户可以点击屏幕上存在的按钮以启动动作，或者有时是自动生成的，例如，屏幕可能需要及时刷新其内容。 控制器的责任主要是从View接收这些动作并对其采取行动。 控制器在处理时可以更新模型。 有时此更新过程需要一段时间。 模型在完成更新过程时会通知Controller，控制器随后会通知View，以使用更新的数据更新其用户界面。 视图和模型永远不会直接对话。 他们通过控制器进行通信。 与原始MVC相比，这是Apple MVC拥有的唯一区别，如下所示。 苹果公司可能已经考虑过不将View与Model紧密绑定，因为移动应用程序中的View可以被高度复用。 如果保持紧密的联系，我们将需要每次针对不同的模型重新实现视图。 与模型无关的视图是Apple MVC背后的实际想法。 很简单，对不对？ 但是，MVC的这种简单性带来了一些问题和困难。 直到移动应用程序变得更短，更简单，才面临这些问题。 但是现在，当iOS设备的功能比台式机强大时，用户希望移动应用程序具有足够的功能来充分利用设备资源。 更多的期望导致更大的应用程序，该应用程序通常集成了多个组件，进而导致更大的代码库。 如果每个组件的职责有限，则可以很好地管理具有多个组件的较大代码库。 首先，MVC引起的问题是，它没有遵循单一责任范式，从而导致了MVC。 什么？ MVC导致MVC？ 是的，MVC（模型视图控制器）导致MVC（Massive View […]

Swift中的VIPER设计模式，用于iOS应用程序开发。

设计模式是上帝给软件开发人员的礼物。 这些技术可最大程度地减少代码重复，防止高度耦合并标准化编写代码的通用方式，从而为开发软件时的重复出现情况提供了通用解决方案。 在这个故事中，我们将熟悉用于iOS开发的称为VIPER （视图，交互器，演示者，实体和路由器）的设计模式。 先决条件：在开始学习VIPER之前，请确保您了解建筑设计模式和委托模式。 什么是毒蛇？ 毒蛇是一种实现“关注分离”范式的设计模式。 与MVP或MVC一样，它通常采用模块化方法。 一种功能，一种模块。 对于每个模块，VIPER具有五个（有时是四个）不同的类，具有不同的角色。 任何课程都不能超出其唯一目的。 这些课程如下。 查看：具有所有代码的类，用于向用户显示应用程序界面并获取他们的响应。 在收到响应后，View会提醒演示者。 演示者：模块的核心。 它从视图中获取用户响应并相应地工作。 仅用于与所有其他组件进行通信的类。 调用路由器进行线框图，交互器以获取数据（网络调用或本地数据调用），查看以更新UI。 交互器：具有应用程序的业务逻辑。 主要进行API调用以从源中获取数据。 负责进行数据调用，但不一定来自其自身。 路由器：进行电线成帧。 从演示者那里收听要演示的屏幕并执行该屏幕。 实体：包含交互器使用的普通模型类。 下面显示了VIPER的简单示意图 毒蛇的例子 我创建了一个简单的项目来解释毒蛇。 可以在GitHub上找到。 这是一个非常基本的应用程序，它显示了从外部API获取的新闻标题。 （：p没用）。 Viper是委托驱动的体系结构。 因此，不同层之间的大多数通信都是通过委派执行的。 一层通过协议调用另一层。 调用层从协议中调用函数。 侦听层符合该协议并实现该功能。 下面，我将解释如何在我的一个示例项目中实现VIPER。 我建议您在github中打开项目并阅读说明。 通讯协定 我为所有协议创建了一个单独的文件。 遵循命名约定来命名协议。 例如，“ viewToPresenterProtocol”。 因此，这是一个“协议”，将由“演示者”实施以收听“视图”必须说的内容。 PresenterToViewProtocol：演示者调用，View侦听。 演示者从该协议接收引用以访问View。 视图符合协议。 ViewToPresenterProtocol：查看呼叫，主持人收听。 InteractorToPresenterProtocol：Interactor调用，Presenter监听。 PresentorToInterectorProtocol：演示者调用，Interactor侦听。 PresenterToRouterProtocol：演示者呼叫，路由器监听。 应用流程 View具有对“ ViewToPresenterProtocol”的引用以访问“ Presenter”并符合“ PresenterToViewProtocol”。 […]

模型-视图-视图模型的建筑模式– Anil Sutariya –中

Model-View-ViewModel体系结构模式 iOS / Swift应用程序使用的Model-View-ViewModel（MVVM）体系结构模式。 MVVM是MVC的扩展，我们在其中正式将视图和控制器耦合在一起，但是将所有表示逻辑从控制器中移出到称为视图模型的新对象中。 在iOS / Swift上下文中，视图的角色由view + view控制器组合完成（参见图）。 在iOS上使用 Figure Model-View View-Model模式 这三个组成部分的作用总结如下： 模型：负责存储数据，与视图模型保持双向通信。 视图/视图控制器：表示模式的视图部分，并处理用户交互事件。 与视图模型保持双向通信。 视图模型：处理表示逻辑，与模型和视图/视图控制器保持双向通信。 处理与可能提供特定功能（如复杂的业务逻辑和网络请求）的其他控制器的通信。