传递类与传递实例；简单的API设计
简介
我知道我要描述的 API/库非常简单，我做什么来让它工作并不重要，但我希望最终能够设计出更复杂的系统，并且希望获得一些关于如何设计简单有效的 API 的良好实践。
信息
我正在重新设计我不久前做的一个 Android 项目，以使一些代码更可重用（不断尝试新的“API”设计以进行实践）。
这个相当简单的应用程序的一部分在屏幕上的文本周围进行随机播放，并且由于存在基于此“库”的三个不同程序，并且具有各自的随机播放效果，因此我选择将公共代码拉出到实际的库中，并将该库的实现解耦。从系统的其余部分洗牌。我改变了一些事情来完成这项工作：处理改组的代码放在一个类中，每个应用程序都提供一个配置对象，其中填充了运行特定应用程序所需的值。在当前的设计下，配置对象提供了所需的 shuffle 实现的 Class。然后，库稍后在需要时创建该类的实例。
我喜欢这个，因为它可以让我的库控制对象的所有内容，并消除实例对外部代码的暴露，但它也阻止我使用构造函数参数（洗牌速度、方向等）自定义实现。 （对此的一种解决方案是传递某种数组，实现可以在库创建它时从中提取数据，但我讨厌那些要求您以某种模糊且难以传递参数的库。检查编译时配置垃圾，例如“speed：90;herp：derp”。）
我的问题
最好通过配置传递类，以便库可以控制它的整个生命周期 -循环，或者是这个不切实际，我应该做一个该死的实例并将其传递进去。另外，如果传递一个类是不切实际的，那么什么时候传递一个类是一个好主意？ （除了诸如在某种地图中的类下注册类实例以便稍后在某种插件系统中查找之类的事情之外）
Introduction
I know the API/library I am about to describe is very simple, and it doesn't really matter what I do to get it working, but I hope to be eventually designing much more complex systems and would like to get some good practice in about how to design a simple and effective API.
Information
I am reworking a project in Android I did a while ago to make some of the code more reusable (Constantly experimenting with new 'API' designs for practice).
Part of this fairly simple app shuffles around text on the screen, and since there are three different programs based on this 'library' with their own shuffling effects, I chose to pull the common code out into an actual library and decouple the implementation of the shuffling from the rest of the system. I changed a few things to make this work: The code that handles the shuffling is put in a class, Each application provides a configuration object filled with the values needed to run the specific application. Under the current design, the configuration object provides the Class of the desired shuffle implementation. The library then creates an instance of the Class at a later time when it is needed.
I liked this because it lets my library control everything of the object and removed exposure of the instance to outside code, but it also prevents me from customizing the implementation with constructor parameters (speed of shuffle, direction, etc). (One solution to this is passing in an array of some sort that the implementation can pull it's data from when it is created by the library, but I hate libraries that require you to pass in parameters in some sort of cloudy and hard-to-check-at-compile-time config crap like "speed:90;herp:derp".)
My Question
Would it be best to pass the Class with the configuration so the library can control it's whole life-cycle, or is this impractical and I should just make a damn instance and pass it in. Also, if passing in a Class is impractical, when is passing in a Class a good idea? (Besides things like registering class instances under their Class in some sort of map for look-up later in some sort of plugin system)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果使用 DI（依赖注入），对象的生命周期将在库外部处理。我更喜欢这种方法，除非生命周期非常简单并且不需要组件可配置。
If you use DI (Dependency Injection), the life cycle of objects is handled external to the library. I prefer this approach unless the life cycle is very simple and there would be no need for the component to be configurable.