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