传递一个类vs传递一个实例;简单的API设计

时间:2011-12-07 08:17:32

标签: java generics class-design

简介

我知道我要描述的API /库非常简单,并且我的工作并不重要,但我希望最终设计更复杂的系统,并希望得到一些关于如何设计简单有效的API的良好实践。

信息

我正在修改我刚刚做过的Android项目,以使一些代码更具可重用性(不断尝试新的'API'设计用于练习)。

这个相当简单的应用程序的一部分在屏幕上的文本周围移动,并且由于有三个不同的程序基于这个'库'并具有自己的改组效果,我选择将公共代码拉出到一个实际的库中并将其解耦从系统的其余部分实施改组。我改变了一些事情来完成这项工作:处理混洗的代码放在一个类中,每个应用程序都提供一个配置对象,其中填充了运行特定应用程序所需的值。在当前设计下,配置对象提供了所需的shuffle实现的Class。然后,库会在以后需要时创建Class的实例。

我喜欢这个,因为它允许我的库控制对象的所有内容并将实例的曝光移除到外部代码,但它也阻止我使用构造函数参数(shuffle,direction等的速度)自定义实现。 (对此的一个解决方案是传递某种类型的数组,实现可以从库创建数据时提取它的数据,但我讨厌要求您在某种阴天和难以传递的参数中传递参数的库check-at-compile-time配置废话,如“speed:90; herp:derp”。)

我的问题

最好是通过配置传递Class,以便库可以控制它的整个生命周期,或者这是不切实际的,我应该制作一个该死的实例并将其传入。另外,如果传入一个类是不切实际,什么时候传递一个好主意? (除了在某种类型的地图中在其类下注册类实例以便稍后在某种插件系统中查找)

1 个答案:

答案 0 :(得分:0)

如果使用DI(依赖注入),则对象的生命周期在库外部处理。我更喜欢这种方法,除非生命周期非常简单,并且不需要组件可配置。

相关问题