有一些第三方框架很不错,但是对于提供的 api 方法。自己感觉并不是很喜欢,于是想自己编写代码,对其进行再一次封装,以适应自己的开发习惯。
有些开发人员觉得,这样做是有点太过了,浪费时间,毕竟是别人的开发东西。但是如果不这样的话,一些重复性的操作,第三方框架的 api 没有提供复用方法,自己就得多写点代码。
各位觉得呢。
1
hugo54 2021-01-01 18:20:34 +08:00
最好的办法是给对方提 issue 或者 pr 吧
|
4
codeforyou 2021-01-01 18:39:30 +08:00
fork 后自己维护一个版本,将你这个版本的特点列在 README 里面,自然会有人跟你一样,并且 star
|
5
vamayoumo 2021-01-01 18:48:59 +08:00 2
偏工具性质的库我觉得在自己的项目中都应该包裹一层,一个是便于自己调用,另一个是考虑接入库的接口可能出现的变动,还有方便以后替换实现方案;但是如果本身就是指导你如何实现某种架构的库,很难做到自己再封装一次。
|
6
3t 2021-01-01 19:02:56 +08:00
看框架的轻重,轻的像 gin 和 flask 想怎么改怎么改,重的框架 django 这种就是拿来就用,轻度包一下也行,改的话一起维护的人会很痛苦,毕竟上一周的代码不知道是不是自己写的(狗头
|
7
tumaowolf 2021-01-01 19:25:54 +08:00
部分易读的工具会,大部分不会
|
8
tctc4869 OP @vamayoumo 适配器模式?重构的话,主要还是针对框架内的某个类型的"get"与"set"的方法进行再一次包裹,但是如果内部有子对象的,就不太好弄了
|
9
tctc4869 OP @tctc4869 说错了,应该是装饰器模式或适配器模式?包裹的的话,主要还是针对框架内的某个类型的"get"与"set"的方法进行再一次包裹,但是如果类的内部有子对象属性的,包裹就有点就不太好弄了
|
10
Building 2021-01-01 20:17:11 +08:00 via iPhone
看情况,有时会再写一个中间层,所有调用都通过这个中间层,这样第三方库换了也不会牵涉到项目核心代码。
|
11
tctc4869 OP |
12
nicevar 2021-01-02 10:50:03 +08:00
看公司还是个人项目,个人项目可能会抽象一层,有一天要切换的时候很快,公司项目的话按规范来,否则每个人都写自己的一套,项目非常乱,特别是早期人手框架的年代,一个项目经手多了就没法看
|
13
agdhole 2021-01-02 11:53:48 +08:00 via iPhone
会,而且内部会根据业务来造一个框架上的框架
|
14
oneend 2021-01-02 12:25:46 +08:00
根据第三方框架 自己把一些自己需要的功能的调用的方式封装下, 这不是很正常的吗?
|
15
jones2000 2021-01-02 12:48:14 +08:00
扣有用的代码, 其他都不要。
|
16
imycc 2021-01-02 17:53:16 +08:00 via iPhone
根据需要自己会固定套一层,用于做通用的错误处理,认证,日志等等。
感觉最理想的还是框架把业务无关的事情给做了,保留足够的接口方便拓展和定制,然后性能不要差。 |
17
pkupyx 2021-01-03 15:26:20 +08:00
看什么程度的三方框架,大框架的话,软件工程的目的先搞清楚,该改习惯的不是人家而是你。。。
如果是常见的网络封装默认报错 UI 是另外一回事。 |