Index Service Design - Sync/Async

Question

У меня есть требование индексировать элементы. Эта служба должна запускать Sync или Async.

Я начал проектирование интерфейса

public interface IndexService{ 
    public void index(); 
} 

И две реализации, один для индекса асинхронного:

public class AsyncIndex implements IndexService { 

    public void index(){ 
     //... Creates a Thread and index the items 
    } 

} 

И другой один к синхронизации Index

public class SyncIndex implements IndexService { 

    public void index(){ 
     //... Creates a Thread and index the items 
    } 

} 

Но теперь существует еще один проект, который имеет IndexService, у которого есть флаг для выполнения async-сервиса или как служба синхронизации:

public interface IndexService{ 
    public void index(int mode); 
} 

Итак, теперь реализация будет знать, как запустить базу на этом флаге.

Я знаю, что первый дизайн лучше, но мне нужны плюсы и минусы, чтобы объяснить, почему.

Answer 1

я иду на первый подход, потому что

1- код чище класс AsyncInex имеет только коды, связанные с асинхронным вызовом и syncIndex бы имеет свой собственный код. 2- вы можете избежать еще, если

... 
public void runService(IndexService service) { 
    service.index() 
} 

// some where in your code 
runService(new AsyncIndex()); 
// or 
runService(new SyncIndex()); 

, как вы работаете с интерфейсом «IndexService» Вы всегда можете изменить реализацию без изменения коды клиентов. специально, если вы используете каркасы DI, вы можете получить его удар;).

Это настолько важно, что вы не знаете код клиента о реализации. предположим ситуацию, в которой вы индексируете, например, базу данных. вы хотите сделать асинхронный индекс, когда данные огромны или индекс синхронизации, когда данные малы. вызывающий абонент не должен знать, как вызван Индекс. таким образом, вы можете иметь разную стратегию в разных ситуациях без изменения кода вызывающих абонентов.если вы возьмете второй подход, вам нужно сделать дополнительную работу.

Answer 2

Я говорю как.

Предположим, вы планируете использовать второй подход. Ваш implmentation может выглядеть следующим образом:

public SyncOrAsyncIndex implements IndexService { 
public void index(int mode) { 
    if(mode == 0) { 
     //sync processing code 
    } else if (mode == 1) { 
     //async procesisng code 
    } 

} 

Это говорит, вы собираетесь написать все реализации в рамках этого индексного метода или класса SyncOrAsyncIndex. Это, возможно, окажется неуправляемым. Таким образом, индексный метод может в конечном итоге, как это:

public void index(int mode) { 
    if(mode == 0) { 
     new SyncIndex().index(); //for example 
    } else if (mode ==) { 
     new AsyncIndex().index(); //for example 
    } 
} 

Предположим, вы решили на поддержку третьего режима. Представьте себе тяжелое положение метода индекса или класса SyncOrAsyncIndex. Итак, первый подход необходим.

Итак, в соответствии с стратегией «код для интерфейса» предлагается первый подход. Если invoker знает тип индексации, он может просто создать экземпляр конкретного типа и использовать его.

Иначе, наряду с первым подходом, в качестве фабрики или стратегии может потребоваться вторая, чтобы рассчитать, какой тип индексирования использовать на основе переданного параметра. Затем invoker будет использовать SyncIndex или AsyncIndex через SyncOrAsyncIndex.