为库编写包装器

发布于 10-25 09:25 字数 222 浏览 2 评论 0原文

我正在尝试为我正在使用的第三方图形库编写一个包装器。我想让它足够通用,如果我决定将其移植到另一个平台或操作系统,我可以轻松切换库。

问题是我真的找不到足够好的设计。除了我正在使用的库之外,我还遵循其他两个库的设计,以确保足够通用的设计。但似乎总有一些事情是一个库可以做而其他库却做不到的。

关于如何使我的代码更加可移植(轻松切换库),您有什么建议吗?也许您可以建议一种过去对您有用的图形包装器设计。

I'm trying to write a wrapper for the third-party graphics library I'm using. I'd like to make it general enough you I could switch libraries easily if I decide to port it over to another platform or OS.

The problem is I can't really find a good enough design. Besides the library I'm using, I'm also following the design of two other libraries to ensure a general enough design. But there always seems to be something one lib can do the others can't.

Do you have any tips as to how I should make my code more portable (easy switching of libraries)? Maybe you can suggest a design for a graphics wrapper that's worked for you in the past.

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

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

发布评论

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

评论(1

机场等船2024-11-01 09:25:55

关于如何使我的代码更加可移植(轻松切换库),您有什么建议吗?

这很少有重要价值。

如果您认为必须确保可移植性,您有三种选择。

  • 最不常见的功能集。获取您认为可能想要使用的所有库。写下所有的类、方法和属性,并找到最小的公共子集。您必须思考如何匹配所有不同的名称,以确保语义尽可能接近。

    这将为您提供一个必须在任何地方运行的最小图形实现。

    但是,它将缺乏功能,并且您的应用程序(或包装器)将必须进行大量编程才能以统一的方式填充缺失的功能。

  • 所有功能的联合。获取您认为可能想要使用的所有库。写下所有的类、方法和属性,然后将每个新事物简单地添加到不断增长的功能列表中。您必须进行一些思考来匹配所有不同的名称,以确保语义尽可能接近,以避免添加重复项。

    这会带来问题,因为一个库中的一项功能必须在所有其他库中实现。这是大量的编程工作。

你不是第一个有这个想法并意识到这真的很难做到的人。

那么回落是什么呢?

选择 3.

选择您最喜欢的图书馆。找点事做。

根据客户需求,确定最需要的备用库。创建必要的包装器,以便您的应用程序可以使用该库。

重复这最后一步,直到没有客户或者客户需求太低,以至于解雇他们比支持他们更便宜。

Do you have any tips as to how I should make my code more portable (easy switching of libraries)?

This is rarely of significant value.

If you think you must ensure portability you have three choices.

  • Least Common Feature Set. Take all the libraries you think you might want to use. Write down all the classes, methods and attributes and find the smallest common subset. You have to do some thinking to match up all the various names to be sure you've got the semantics as close as possible.

    This will give you a minimal graphics implementation that must run everywhere.

    However, it will be feature-poor and your application (or wrapper) will have to do a lot of programming to fill in the missing features in a uniform way.

  • Union of All Features. Take all the libraries you think you might want to use. Write down all the classes, methods and attributes and simply add each new thing to the ever-growing list of features. You have to do some thinking to match up all the various names to be sure you've got the semantics as close as possible to avoid adding duplicates.

    This will present problems because a feature that's in one library must be implemented in all the other libraries. It's a lot of programming.

You're not the first person to have this thought and realize that it's really, really hard to do.

So what's the fall back?

Choice 3.

Pick your favorite library. Get something to work.

Based on customer demand, identify the most-demanded alternate library. Create the necessary wrapper so that your application can work with this library.

Iterate this last step until you're out of customers or the customer demand is so low that it's cheaper to fire them as a customer than it is to support them.

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