Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

代码重构 #19

Closed
wants to merge 4 commits into from
Closed

代码重构 #19

wants to merge 4 commits into from

Conversation

inatu
Copy link

@inatu inatu commented Nov 30, 2015

因为要添加支付宝分享, 所以仔细审视了一下代码, 觉得以前的代码结构设计不适合做出大的扩展. 所以进行了大面积的重构, 大概内容

  1. 将分享内容的搭建抽离了出来.
  2. 稍微选用了些 struct 类型
  3. 使用协议完成不同类型的分享, 分类管理.
  4. 对 UIActivity 做了些扩展.

还有工作没完成:

  1. 有些小的细节处理需要完善.
  2. 打算将 web view 和网络抽成协议, 毕竟每个应用都有自己的组件, 让他们(可选)用自己的组件完成
  3. 完整的注释

因为完成这部分重构有点匆忙,可能会有些小问题, 但是觉得这种方式可能更适合以后这个框架的扩展和管理. 所以请看下, 如果你们不打算采用的话, 我想是不是可以借用下你们的成果,自己发一个第三方的分享包.

@Limon-O-O
Copy link
Collaborator

超赞!!!!!

@inatu
Copy link
Author

inatu commented Nov 30, 2015

明天可以看下, 如果没有问题可以合并到一块去了; 虽然已经使用的应用要修改下接口, 但是好处应该多于坏处. 因为我们用SDK 实现支付宝分享, 所以在外面自己基于 SDK 写了一个 service Provider.

On Dec 1, 2015, at 12:09 AM, Limon notifications@github.com wrote:

超赞!!!!!


Reply to this email directly or view it on GitHub #19 (comment).

@nixzhu
Copy link
Owner

nixzhu commented Dec 1, 2015

代码很有工程感,很好。但我不喜欢这种风格,所以很抱歉不会合并。理由如下:

  1. 破坏性修改。用 enum 做 account 已可以很好的分离各个社交网络。虽然 MonkeyKing.swift 里的代码很多,但很容易理解其结构,并不存在代码行数多就没有模块化的感觉。
  2. MonkeyKing 使用的分析过程来自 openshare,而 openshare 就是将各个社交网络分别处理,类如此 PR。而 MonkeyKing 在设计时故意选取了更加 Swift 的方式(或者说对 enum 的偏好),以提供更简洁的 API。
  3. 设计 AnyActivity 是为了让用户(程序员)自行决定他要使用的系统分享,demo 里提供例子以参考。这样可以让 MonkeyKing 保持纯净,不需要引入图片或字符串翻译。

@inatu MonkeyKing 的代码使用 MIT 协议,所以您可以借用其代码发布自己的第三方库。

@nixzhu nixzhu closed this Dec 1, 2015
@inatu
Copy link
Author

inatu commented Dec 1, 2015

嗯, 好的, 谢谢, 我觉得可以自己发布一个第三方库.

其实我也注意到了 AnyActivity 的存在貌似没有太大的必要, 因为微信等已经有自己的分享, 但是因为不想破坏原来的功能所以勉强加上去了, 如果自己的话, 会把这一部分去掉. 之所以打算重构最主要的原因是为了方便添加其它的第三方分享; 特别是那些依赖于第三方自己的 SDK 实现的分享.

接口的简洁我觉得搭建程序可能像计算机的系统构建一样, 下面为了适应更大的需要,可能往往需要提供较为粗糙的接口, 越往上会因为业务越具体变得更加简洁.因为我们在自己的工程中会再用结构体在这个库的上面架一层更针对自己应用的业务接口, 所以API对外 会保持绝对的简洁. 这种设计可以避免 register 这种没有必要的逻辑, 也没有太多的单例在整个程序中运行. 由于我们业务层的一个封装, 其实只有一个 ThirdPartyManager 的结构体负责和业务的交互, 引入第三方库, 其它的地方只会使用 ThirdPartyManager 的对外的几个简洁的接口.

感觉每种方案都有优缺点, 可能根据自己的需要适合不同的搭建方式. 等忙过最近, 打算写篇文章介绍下这种思路, 到时候欢迎探讨.

On Dec 1, 2015, at 10:51 AM, nixzhu notifications@github.com wrote:

Closed #19 #19.


Reply to this email directly or view it on GitHub #19 (comment).

@nixzhu
Copy link
Owner

nixzhu commented Dec 1, 2015

很棒,等着看文章。MonkeyKing 的主要目的就是避免使用者(程序员)和各种第三方 SDK 打交道(因为那种体验实在很不好),不知道你所说的“依赖于第三方自己的 SDK 实现的分享”有哪些?是否可能有办法避免?

@inatu
Copy link
Author

inatu commented Dec 1, 2015

我们现在主要要做的是支付宝的分享, OpenShare 也没有做, 打算等忙过这段自己探索下; 现在先暂时还是使用支付宝的 SDK. 所以先在库的外面构建了一个自己的 AlipayServiceProvider 来对 SDK 做封装实现 protocol 中的几个接口, 等到以后探索出方案, 就可以直接修改下这个文件. 移到库的里面

On Dec 1, 2015, at 11:43 AM, nixzhu notifications@github.com wrote:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants