始终注意技术建议的含义

这个周末，我浏览了Medium，发现了一篇有关“从模型到控制器传递数据的3种方式”的文章。 评论表明人们喜欢它，因为它谈到了重要的基础知识：如何传递信息？ 这可能是有史以来最重要的面向对象编程问题。 您如何耦合组件？

提到的3种方式是：

1. 回调，
2. 代表团，
3. 和通知。

实际上，这是耦合任何组件的3种不同方式。 了解这些技巧（以及其他技巧）对编写代码非常重要。

然后我想到这篇文章可能会误导新的Swift开发人员，因为这些示例几乎没有显示如何创建一个好的模型。 采取示例代码进行委派：

 类DataModel { 
 弱var委托：DataModelDelegate？ 
  func requestData（）{ 
  //接收到数据并将其解析为String 
 让数据=“来自任何地方的数据” 
 委托？.didRecieveDataUpdate（数据：数据） 
  } 
  } 

这是一个基于委托的回调的网络请求。 当然，它说明了代表团。 但这是网络控制器代码。 这不是模型代码。 您在这里看到任何代表实体的东西吗？ 实际上，您将发现的唯一具有模型风格的东西是数据。 模型对象是本质上是某种东西的对象。 上面看到的是仅封装序列的服务对象。 除了委托属性，它是无状态的。 它本身几乎不是应用程序状态的一部分。

在简单的情况下，从模型代码中提取网络请求代码可能没有回报。 但这不会扩展。 而且，如果您将此示例视为起义的iOS或Mac开发人员的第一件事，那么您将产生误导。

假设您的代码已经具有模型对象，并且您想应用上面概述的委托技术。 因此，您采用了这个简单的代码段，您可以将其粘贴到其中而没有任何冲突，然后就可以完成了。 成功的申请似乎足以证明。 但是现在您的代码变得更糟了。 因为您的模型对象现在也是网络请求网关。 它做了两个非常重要但又非常不同的事情。 也许危害仅会在几个月后显现出来，并且，如果您一开始就全力以赴地使自己陷入这种情况，那么您可能不知道问题的根源，并且将无法自己修复。

当您阅读以代码为中心的“ X最好的Y方式”时，请弄清楚作者正在（不知不觉中）向您出售什么样的世界观或术语。 只有相距甚远，您才能获得建议，而不会盲目地改变自己的想法。 如果您找不到作者为什么如此做的令人信服的理由，也许她只是做事草率而已，并不在乎。 您必须对所学内容的质量负责。

作者无法从Genesis入手，也无法解释整个人类历史如何在这种超级编码技巧中达到顶峰。 在写作时，您必须将某些事情视为理所当然。 问题是：如果您（读者）没有自己的见解，那么您首先看到的东西对您的影响最大。 如果遗漏的东西是您工艺的重要概念，那么很难知道发生了什么。 您不能收集一些代码片段，除非收集一些作者关于如何正确执行操作的观点。 如果您的收藏夹中的各个部分发生冲突，而您没有注意到它或不明白为什么，那么将很难编写具有凝聚力的代码并应用任何这些技巧。 因为最终，没有任何事情是孤立的。 您（人类）始终是过程的一部分，您的困惑将在代码中体现出来。

供参考，这是我最后谈到的帖子的链接：http://ift.tt/2cO5p7V

通过Christian Tietze的工作日志 http://ift.tt/2hsXvqy