别人开发的框架，各位使用后，会为了开发习惯而再写代码进行封装么？

[tctc4869]

有一些第三方框架很不错，但是对于提供的 api 方法。自己感觉并不是很喜欢，于是想自己编写代码，对其进行再一次封装，以适应自己的开发习惯。

有些开发人员觉得，这样做是有点太过了，浪费时间，毕竟是别人的开发东西。但是如果不这样的话，一些重复性的操作，第三方框架的 api 没有提供复用方法，自己就得多写点代码。

各位觉得呢。

[hugo54]

最好的办法是给对方提 issue 或者 pr 吧

[tctc4869]

@hugo54 这个得看框架提供者

[tctc4869]

@tctc4869 不对，是框架开发的作者

[codeforyou]

fork 后自己维护一个版本，将你这个版本的特点列在 README 里面，自然会有人跟你一样，并且 star

[vamayoumo]

偏工具性质的库我觉得在自己的项目中都应该包裹一层，一个是便于自己调用，另一个是考虑接入库的接口可能出现的变动，还有方便以后替换实现方案；但是如果本身就是指导你如何实现某种架构的库，很难做到自己再封装一次。

[3t]

看框架的轻重，轻的像 gin 和 flask 想怎么改怎么改，重的框架 django 这种就是拿来就用，轻度包一下也行，改的话一起维护的人会很痛苦，毕竟上一周的代码不知道是不是自己写的（狗头

[tumaowolf]

部分易读的工具会，大部分不会

[tctc4869]

@vamayoumo 适配器模式？重构的话，主要还是针对框架内的某个类型的"get"与"set"的方法进行再一次包裹，但是如果内部有子对象的，就不太好弄了

[tctc4869]

@tctc4869 说错了，应该是装饰器模式或适配器模式？包裹的的话，主要还是针对框架内的某个类型的"get"与"set"的方法进行再一次包裹，但是如果类的内部有子对象属性的，包裹就有点就不太好弄了

[Building]

看情况，有时会再写一个中间层，所有调用都通过这个中间层，这样第三方库换了也不会牵涉到项目核心代码。

[tctc4869]

@Building
@vamayoumo
@tumaowolf

写这种中间层，实现以便于扩展，可替换性，增强开发效率，一遍会用到什么设计？我想到的是设计模式里的装饰器模式，加上语言自带的接口，抽象类，泛型。除了装饰器模式，还有其他的么

[nicevar]

看公司还是个人项目，个人项目可能会抽象一层，有一天要切换的时候很快，公司项目的话按规范来，否则每个人都写自己的一套，项目非常乱，特别是早期人手框架的年代，一个项目经手多了就没法看

[agdhole]

会，而且内部会根据业务来造一个框架上的框架

[oneend]

根据第三方框架 自己把一些自己需要的功能的调用的方式封装下, 这不是很正常的吗？

[jones2000]

扣有用的代码， 其他都不要。

[imycc]

根据需要自己会固定套一层，用于做通用的错误处理，认证，日志等等。
感觉最理想的还是框架把业务无关的事情给做了，保留足够的接口方便拓展和定制，然后性能不要差。

[pkupyx]

看什么程度的三方框架，大框架的话，软件工程的目的先搞清楚，该改习惯的不是人家而是你。。。
如果是常见的网络封装默认报错 UI 是另外一回事。