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
代码重构 #19
Conversation
超赞!!!!! |
明天可以看下, 如果没有问题可以合并到一块去了; 虽然已经使用的应用要修改下接口, 但是好处应该多于坏处. 因为我们用SDK 实现支付宝分享, 所以在外面自己基于 SDK 写了一个 service Provider.
|
代码很有工程感,很好。但我不喜欢这种风格,所以很抱歉不会合并。理由如下:
@inatu MonkeyKing 的代码使用 MIT 协议,所以您可以借用其代码发布自己的第三方库。 |
嗯, 好的, 谢谢, 我觉得可以自己发布一个第三方库. 其实我也注意到了 AnyActivity 的存在貌似没有太大的必要, 因为微信等已经有自己的分享, 但是因为不想破坏原来的功能所以勉强加上去了, 如果自己的话, 会把这一部分去掉. 之所以打算重构最主要的原因是为了方便添加其它的第三方分享; 特别是那些依赖于第三方自己的 SDK 实现的分享. 接口的简洁我觉得搭建程序可能像计算机的系统构建一样, 下面为了适应更大的需要,可能往往需要提供较为粗糙的接口, 越往上会因为业务越具体变得更加简洁.因为我们在自己的工程中会再用结构体在这个库的上面架一层更针对自己应用的业务接口, 所以API对外 会保持绝对的简洁. 这种设计可以避免 register 这种没有必要的逻辑, 也没有太多的单例在整个程序中运行. 由于我们业务层的一个封装, 其实只有一个 ThirdPartyManager 的结构体负责和业务的交互, 引入第三方库, 其它的地方只会使用 ThirdPartyManager 的对外的几个简洁的接口. 感觉每种方案都有优缺点, 可能根据自己的需要适合不同的搭建方式. 等忙过最近, 打算写篇文章介绍下这种思路, 到时候欢迎探讨.
|
很棒,等着看文章。MonkeyKing 的主要目的就是避免使用者(程序员)和各种第三方 SDK 打交道(因为那种体验实在很不好),不知道你所说的“依赖于第三方自己的 SDK 实现的分享”有哪些?是否可能有办法避免? |
我们现在主要要做的是支付宝的分享, OpenShare 也没有做, 打算等忙过这段自己探索下; 现在先暂时还是使用支付宝的 SDK. 所以先在库的外面构建了一个自己的 AlipayServiceProvider 来对 SDK 做封装实现 protocol 中的几个接口, 等到以后探索出方案, 就可以直接修改下这个文件. 移到库的里面
|
因为要添加支付宝分享, 所以仔细审视了一下代码, 觉得以前的代码结构设计不适合做出大的扩展. 所以进行了大面积的重构, 大概内容
还有工作没完成:
因为完成这部分重构有点匆忙,可能会有些小问题, 但是觉得这种方式可能更适合以后这个框架的扩展和管理. 所以请看下, 如果你们不打算采用的话, 我想是不是可以借用下你们的成果,自己发一个第三方的分享包.