面向协议编程并非银弹

ebio3659 7年前
   <p>银弹(Silver Bullet)一词出自IBM大型机之父Frederick P. Brooks Jr.在1986年发表的一篇关于软件工程的经典论文《没有银弹:软件工程的本质性与附属性工作》(No Silver Bullet — Essence and Accidents of Software Engineering)。其中的“银弹”是指一项可使软件工程的生产力在十年内提高十倍的技术或方法。该论文强调由于软件的复杂性本质,而使这样“真正的银弹”并不存在。</p>    <p>银弹在软件工程中的含义是指妄图创造某种便捷的开发技术,从而使某个项目的实施提高效率。又或者指摆脱该项目的本质或核心,而达到超乎想象的成功。但这么做的结果却是徒劳的。</p>    <p>在本文中Chris介绍了Swift中的面向协议编程的滥用情况,认为很多时候有更简单的解决办法,面向协议编程并非银弹。</p>    <p>以下为正文:</p>    <p>在Swift语言中,面向协议编程很流行。在“面向协议”那儿有很多Swift代码,一些开源库甚至将其声明为功能。我觉得协议在Swift中被过度滥用了,其实问题常常可以用更简单的方式来解决。简而言之,就是不要生搬硬套协议的条条框框,而不知变通。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/ee7984fbec3f0130fd1fcb9e7b5a0fc1.jpg"></p>    <p>在WWDC2015上苹果推出了一个Session叫“Swift中的面向协议编程”,它成了这届大会上最有影响力的Session之一。它表明了除某些情况外,用户可以使用面向协议的解决方案(即协议和一些符合协议的类型)来替换类层次结构(即超类和一些子类)。面向协议的解决方案更简单、更灵活。例如,一个类只能有一个超类,但一个类型可以符合许多协议。</p>    <p>让我们来看看他们在WWDC演讲中解决的这个问题:一系列绘图命令需要渲染成图像,并将指令记录到控制台。通过将绘图命令放在协议中,描述绘图的任何代码可以根据协议的方法来表述。协议扩展允许你根据协议的基本功能定义新的绘图功能,并且每个符合的类型都可以自动获得新的功能。</p>    <p>在上述例子中,协议解决了多种类型之间共享代码的问题。在Swift的标准库中,协议主要用于Collection类型,用来解决完全相同的问题。因为dropFirst用Collection类型定义,所有的Collection类型都能自动得到它。与此同时,标准库中定义了太多的Collection相关的协议和类型,当我们想找东西时会面临困难。这是协议的一个缺点,然而,在标准库的情况下还是利大于弊。</p>    <p>现在,让我们通过一个例子来开始。这里有一个WebService类。它使用URLSession从网络加载实体。(实际上并不加载东西,领会意思即可):</p>    <pre>  class Webservice {     func loadUser() -> User? {       let json = self.load(URL(string: "/users/current")!)       return User(json: json)     }     func loadEpisode() -> Episode? {       let json = self.load(URL(string: "/episodes/latest")!)       return Episode(json: json)     }     private func load(_ url: URL) -> [AnyHashable:Any] {       URLSession.shared.dataTask(with: url)       // etc.       return [:] // should come from the server     }   }   </pre>    <p>上面的代码很短,运行正常。直到我们要测试loadUser和loadEpisode之前,没有什么问题。现在我们要么用stub方法来模拟load,要么通过依赖注入来传入一个模拟的URLSession。我们还可以定义一个符合URLSession的协议,然后传递一个测试实例。不过在这个案例中,我们采用更简单的解决方案,将Webservice更改的部分取出并转换为结构体:</p>    <pre>  struct Resource<A> {     let url: URL     let parse: ([AnyHashable:Any]) -> A}   class Webservice {     let user = Resource<User>(url: URL(string: "/users/current")!, parse: User.init)     let episode = Resource<Episode>(url: URL(string: "/episodes/latest")!, parse: Episode.init)     private func load<A>(resource: Resource<A>) -> A {       URLSession.shared.dataTask(with: resource.url)       // load asynchronously, parse the JSON, etc. For the sake of the example, we directly return an empty result.       let json: [AnyHashable:Any] = [:] // should come from the server       return resource.parse(json)     }   }   </pre>    <p>现在,我们可以不必通过模拟任何东西来测试user和episode了:它们是简单的结构值。我们仍然需要测试load,但只有这一个方法需要写测试(而不是为每个资源)。现在让我们来添加一些协议。</p>    <p>取代parse函数,我们可以为能够从JSON初始化的类型创建一个协议。</p>    <pre>  protocol FromJSON {     init(json: [AnyHashable:Any])   }   struct Resource<A: FromJSON> {     let url: URL}   class Webservice {     let user = Resource<User>(url: URL(string: "/users/current")!)     let episode = Resource<Episode>(url: URL(string: "/episodes/latest")!)     private func load<A>(resource: Resource<A>) -> A {       URLSession.shared.dataTask(with: resource.url)       // load asynchronously, parse the JSON, etc. For the sake of the example, we directly return an empty result.       let json: [AnyHashable:Any] = [:] // should come from the server       return A(json: json)     }   }   </pre>    <p>上面的代码可能看起来更简单,但灵活性也大大降低。例如,你如何定义一个具有User值的数组资源?(上述面向协议的例子中,是不可能实现的,我们必须等待Swift 4或5,直至可用。)协议使代码得以简化,但我认为它不为自身买单,因为它大大减少了我们可以创建一个Resource的方式。</p>    <p>代替将user和episode作为Resource值,我们还可以使Resource成为协议并具有UserResource和EpisodeResource结构。这似乎是一个很流行的做法,因为拥有类型比只是一个值来说,“就是感觉要对一些”:</p>    <pre>  protocol Resource {     associatedtype Result     var url: URL { get }     func parse(json: [AnyHashable:Any]) -> Result}   struct UserResource: Resource {     let url = URL(string: "/users/current")!     func parse(json: [AnyHashable : Any]) -> User {       return User(json: json)     }   }   struct EpisodeResource: Resource {     let url = URL(string: "/episodes/latest")!     func parse(json: [AnyHashable : Any]) -> Episode {       return Episode(json: json)     }   }   class Webservice {     private func load<R: Resource>(resource: R) -> R.Result {       URLSession.shared.dataTask(with: resource.url)       // load asynchronously, parse the JSON, etc. For the sake of the example, we directly return an empty result.       let json: [AnyHashable:Any] = [:]       return resource.parse(json: json)     }   }   </pre>    <p>但如果我们仔细看看,我们真正得到了什么?代码变得更冗长、复杂、不直观。并且由于关联类型,结果最后我们可能定义一个AnyResource。EpisodeResource结构和episodeResource值有什么区别呢?它们都是全局定义的。对于结构体,名称以大写字母开头;而对于值,则使用小写字母。除此之外,结构真的没有任何优势。你可以将它们加入命名空间(自动补全)。所以在这种情况下,有一个值肯定会更简短。</p>    <p>我在网上看到的很多代码例子。例如,我看到这样的协议:</p>    <pre>  protocol URLStringConvertible {     var urlString: String { get }   }   // Somewhere laterfunc sendRequest(urlString: URLStringConvertible, method: ...) {     let string = urlString.urlString   }   </pre>    <p>是什么打动了你?为什么不简单地删除协议并直接传递urlString呢?这样就简单多了。或者,一个单一方法的协议:</p>    <pre>  protocol RequestAdapter {     func adapt(_ urlRequest: URLRequest) throws -> URLRequest}   </pre>    <p>有些争议的是:为什么不简单地删除协议,并在某处传递函数?这样岂不是更简单。(除非你的协议是一个类的协议,你想要一个弱引用)。</p>    <p>我可以继续展示例子,但我希望希望你已经明确我的观点:多数情况下都有更简单的选择。更抽象地说,协议只是实现多态代码的一种方式。还有许多其他方法:子类、泛型、值、函数等。使用值(例如,一个String,而不是一个URLStringConvertible)是最简单的方法。函数(例如adapt而不是RequestAdapter)比值复杂一点,但仍然很简单。泛型(无任何限制)比协议简单。为了完成代码,协议通常比类层次结构更简单。</p>    <p>一个有用的启发是,也许是考虑您的协议是依照数据还是行为来建模。对于数据,结构可能更容易。对于复杂的行为(例如,具有多个方法的委托),协议通常更容易。(标准库的collection协议有点特别:它们并不真正描述数据,而是描述数据操作。)</p>    <p>也就是说,协议可能非常有用。但不要为了面向协议编程而编程。首先要审视你的问题,并尝试以最简单的方式来解决它。让问题推动解决方案,而不是相反。面向协议编程本身无所谓好与坏。就像任何其他技术(函数式编程,OO,依赖注入,子类化)一样,它可以用来解决一个问题,我们应该尝试选择合适的工具。有时这是一个协议,但往往,有一个更简单的方法。</p>    <p>其他</p>    <ul>     <li>Beyond Crusty:Real-World Protocols: <a href="/misc/goto?guid=4959729200444646754" rel="nofollow,noindex">http://www.thedotpost.com/2016/01/rob-napier-beyond-crusty-real-world-protocols</a></li>     <li>Haskell Game Object Design - Or How Functions Can Get You Apples: <a href="/misc/goto?guid=4959729200541334368" rel="nofollow,noindex">http://www.gamedev.net/page/resources/_/technical/game-programming/haskell-game-object-design-or-how-functions-can-get-you-apples-r3204</a></li>    </ul>    <p> </p>    <p>来自:http://mobile.51cto.com/app-show-524738.htm</p>    <p> </p>