我想修改一个开源 wpf 库,但随着捐赠者库的改进而更新它:如何?

发布于 2024-10-30 23:58:29 字数 565 浏览 1 评论 0原文

我打算延长&更改开源库 (LIB_A),它本身由其他库组成,这些库已针对其发布进行了修改。
我的修改可能是对所有库进行的。

当添加新功能/消除错误时,使后续将 LIB_A 导入到我的库中尽可能轻松且不会产生集成问题的最佳方法是什么?

我正在考虑让我的库子类化我想要更改的类,并覆盖我想要更改的方法,但无法弄清楚这是否可行。这里的原因是我可能只修改每个类中的两个方法,这样当 LIB_A 错误被修复时,如果它们不在我修改的方法中 - 就不会发生冲突,并且我可以免费利用更新。如果他们采用相同的方法,那就没有办法解决这个问题,我接受。

如果我只是复制整个 LIB_A,那么我将不得不费力地通过差异浏览每个文件以查看已更改的内容,然后合并更新。必须有一个既定的方法来做到这一点?

源存储库(本地或其他)及其关联的签入和比较行为是否是可接受的方法?

谢谢


编辑:这个问题问的是完全相同的事情..

I'm intending to extend & alter an opensource library (LIB_A), which is itself composed of other libraries which have been modified for it's release.
My modifications are probably to be made to all of the libraries.

What is the best way to make subsequent importing of LIB_A into my library as painless as possible when new features are added/bugs are squished, without creating integration issues?

I was thinking of having my library sublass the classes I want to change, and override methods I want to change, but can't figure out if this is possible. The reasoning here is that I might only modify two methods in each class, so that when LIB_A bugs are fixed, if they're not in my modified methods - there is no collision, and I take advantage of the updates for free. If they are in the same method, there's no way around that, which I accept.

If I just copy the whole LIB_A, then I'll have to laboriously go through every file with a diff to see what has been changed, and then incorporate the updates. There must be an established way of doing this?

Is a source repository (local or otherwise) with it's associated check-in and diff behaviour the accepted method?

Thanks


EDIT: This SO question is asking exactly the same thing..

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

傻比既视感 2024-11-06 23:58:29

嗯,你说过了。如果您可以通过子类化来做到这一点,那么无论如何这是最简单的方法。

问题是你并不总是可以通过子类来做到这一点——例如,当你需要更改密封或私有方法、更改其他非虚拟方法或属性等时。在这种情况下,除了以下任一操作之外,你无能为力: (1) 复制代码并创建您自己的版本,(2) 修改代码,使这些方法/属性是虚拟的和公共的——但确保它不会破坏其他地方的任何内容。

即使您可以对其进行子类化,并且库的新版本不会触及您覆盖的少数方法,您仍然必须再次完全测试您的更改,因为您的新代码可能依赖于某些实现新版本更改的详细信息。当然,库的供应商会针对新版本修改这几个方法,但您的版本不会改变。因此,最好的方法是将供应商的新版本的重写方法与旧版本进行比较,以检测您是否也需要更改自己版本中的某些内容。

Well, you said it. If you can do it by subclassing, then by all means this is the simplest method.

The problem is that you not always can do it just via subclassing -- e.g. when you need to change a sealed or private method, change other non-virtual methods or properties etc. In this case, there is nothing you can do except to either (1) copy the code and create your own version, (2) modify the code such that those methods/properties are virtual and public -- but make sure it doesn't break anything elsewhere.

Even if you can subclass it, and the new version of the library does not touch the few methods that you overrode, you still have to test your changes fully agian, because your new code may depend on certain implementation details that the new version changed. Of course, the vendor of the library will have modified those few methods for the new version, but your version won't change. So the best way is to do a diff of the vendor's new version of your overridden methods with the old version to detect whether you need to change something in your own version as well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文