2016-04-05 2 views
0

Я пытаюсь выяснить, какой из лучших API будет предоставлять клиентам моего 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); 
     } 
    }); 
} 

я бы выбрал Latt (C), так как я рассматриваю его как золотой путь между простотой использования и будущей масштабируемостью. Пожалуйста, ознакомьтесь с моими комментариями и посоветуйте!

+0

Какая часть этого является вашим API и какая часть является клиентским кодом? –

+0

Методы будут представлять собой код клиента. Классы и связанные с ними методы _SessionFactory, StreamingModule_ будут API. –

ответ

1

Я почти выбрал A, потому что он проще в использовании, а среднее имя «бремя» - это «гибкость».

Тем не менее, я бы пошел с ребенком-ублюдком A и C, где нет волшебства с classpath для получения модуля.

Мысли/рассуждения: Каждый раз, когда я слышу слова «JVM», «implicit» и «classpath» в том же предложении, я теряю волосы и чувствую, что меня бьет автобус.

Некоторым пользователям может быть труднее иметь дело с асинхронным SessionCreationCallback по сравнению с последовательным кодом, но это действительно случай RTFM о компьютерах.