在Objective-C的包裹C库的提示 [英] Tips on wrapping a C library in Objective-C
问题描述
我用C写的一个库，我想在一个Objective-C的应用程序使用，无论是在Mac或iPhone。
I have a library written in C that I would like to use in an Objective-C app, either on the Mac or the iPhone.
不幸的是，因为这个库是开源的空间被写入由个人，文档是很稀疏，不完整的。虽然我可以计算出如何使用的东西在图书馆，我真的没有整个code基地的概况。
Unfortunately, since this library is being written by individuals in the open source space, the documentation is quite sparse and incomplete. While I can figure out how to use the stuff in the library, I don't really have an overview of the entire code base.
我想这样做的是包裹起来的图书馆成Objective-C的一些容易使用和转让类。
What I would like to do is wrap the library up into some easily usable and transferrable classes in Objective-C.
- 有没有人对如何处理这个任何提示？
- 在获得图书馆是如何构成一个视觉层次的最佳方式有何建议？
- 我怎么会去决定如何最好地结构包装的可重用性和易用性？
任何及所有帮助将大大AP preciated，谢谢！
Any and all help will be greatly appreciated, thanks!
推荐答案
我已经做了这几次自己。这可以很有趣 - 这是你的机会来解决（或至少隐藏）不良code
I've done this a few times myself. This can be fun -- it's your chance to fix (or at least hide) bad code!
您可以使用 Doxygen的得到code的视觉层次（虽然我只是完成用它为C ++库，它也适用于C），或任何其他免费工具在那里。
You can use Doxygen to get a visual hierarchy of the code (although I've only used it for C++ libraries, it also works with C), or any of the other free tools out there.
不要组织你的包装类，如基础库如果库没有设计或记录良好。这是你的机会来考虑对于用户以及他们如何将要使用code点。首先编写测试用例，以弄清这一点，和/或跟一些人谁已经在使用该库。
Don't structure your wrapper class like the underlying library if the library isn't designed or documented well. This is your chance to consider the point of view of the user and how they are going to be using the code. Write your test cases first to figure that out, and/or talk to some people who use the library already.
Two nice design patterns that match up with what you're doing are Adapter and Facade.
这篇关于在Objective-C的包裹C库的提示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
