我正在努力找出向我的SDK的客户端提供的最好的API。基本上,在一个应用程序中,典型的用例将是一个会话实例和一个呈现器,但是,这在将来可能会发生变化。
关键点:易用性应从用户的前瞻性、稳定性和前瞻性出发.
方法A:
/**
* The user have to create and maintain the module
*
* pros:
* -module explicitly added at construction time
* -uses an object that would be only available using the extension
*
* cons:
* -does not enforce one-o-one relation between renderer and session
* -the burden of maintaining the module leaved to the user
* -the burden of creating the module leaved to the user
* -fixed StreamingModule implementation forever
* */
public void createSessionWithUserInstalledModule(VideoRenderer.Callbacks renderer) throws Exception {
SessionFactory factory = SessionFactory.newInstance();
StreamingModule module = new StreamingModule();
module.useRenderer(renderer);
factory.install(module);
factory.create(context, sessionCreatedCallback);
}
方法B:
/**
* A static field of the module holds the instance.
* The module will be implicitly picked up, and instantiated
* when it's on the classpath.
* It will be injected into the session during construction time.
*
* pros:
* -module doesn't need to be maintained by user
* -trivial implementation from user side
*
* cons:
* -only one renderer is possible
* -only one renderer will be available to all session instances
* -possibility of leaking the renderer instance
* */
public void createSessionWithStaticHolder(VideoRenderer.Callbacks renderer) throws Exception {
SessionFactory factory = SessionFactory.newInstance();
StreamingModule.setRenderer(renderer);
factory.create(context, sessionCreatedCallback);
}
方法C:
/**
* The module can be retrieved from the session instance, after the
* session is created.
* The module will be implicitly picked up, and instantiated
* when it's on the classpath.
* It will be injected into the session during construction time.
*
* pros:
* -StreamingModule implementation can be replaced in the future
* -session instances have their own module
* -only the session instance needed to be maintained (which is probably
* already done on the user side)
*
* cons:
* -less trivial implementation on user side
* */
public void createSessionUsingServiceStyle(final VideoRenderer.Callbacks renderer) throws Exception {
SessionFactory factory = SessionFactory.newInstance();
factory.create(context, new SessionFactory.SessionCreationCallback() {
@Override
public void onSessionCreated(Session session) {
StreamingModule module = session.getModule(StreamingModule.class);
module.useRenderer(renderer);
}
});
}
我选择后一种解决方案(C),因为我认为它是在易用性和未来可伸缩性之间的一条黄金之路。请看我的意见,并提出建议!
发布于 2016-04-19 15:06:34
我几乎选择了A,因为它使用起来更简单,中间的名字“负担”是“灵活性”。
尽管如此,我还是会和A和C的私生子一起去,那里没有魔法和类路径来获得模块。
思考/推理:每当我在同一个句子中听到'JVM‘、’隐式‘和’类路径‘这个词时,我就会失去一些头发,感觉自己被一辆公共汽车撞到了。
一些用户可能会发现与顺序代码相比,异步SessionCreationCallback更难处理,但这实际上只是计算机RTFM的一个例子。
https://stackoverflow.com/questions/36434725
复制相似问题