Отдельные интерфейсы декодирования / кодирования или в одном интерфейсе - PullRequest
3 голосов
/ 24 января 2009

Я создаю реализацию, которая выполняет преобразование из одной формы в другую.

Проблема проектирования, с которой я сейчас сталкиваюсь, заключается в том, должен ли API кодировщика и декодера быть в одном интерфейсе или в отдельных. например Apache MINA использует отдельные интерфейсы

В настоящее время я делаю что-то вроде этого:

interface Convertor
{
    A encode( B b );

    B decode( A a );
}

Основанием для их размещения в одном интерфейсе является то, что вы можете централизовать реализации и фиксировать любые изменения протокола в одном месте. Есть мысли по этому поводу?

Ответы [ 8 ]

6 голосов
/ 24 января 2009

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

Итак, я бы использовал отдельные интерфейсы и, по крайней мере, для начала, чтобы один класс реализовывал оба. Таким образом, реализация является общей, но пользовательский код видит кодер и декодер как отдельные и независимые понятия.

2 голосов
/ 24 января 2009

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

True для c / c ++ и т. Д. С заголовочным файлом.

Поиск надежных принципов и см. Принцип разделения интерфейсов.

1 голос
/ 25 января 2009

Делать их отдельно намного гибче. Если вы пишете отдельные интерфейсы, вы всегда можете объединить их в третий интерфейс, который вы используете всякий раз, когда вам нужно одновременно кодировать и функции декодирования.

Обратное неверно. Если вы пишете один интерфейс с самого начала, вы теряете гибкость в выборе включения только функций кодирования или .

1 голос
/ 24 января 2009

Недостаток их наличия в одном интерфейсе состоит в том, что заставляет ваши реализации быть как кодерами, так и декодерами в одном классе. В настоящее время это может показаться разумным, но не всегда так. Поэтому я хотел бы спросить себя, должно ли это быть требованием / желательно?

1 голос
/ 24 января 2009

Ну, вы могли бы иметь два отдельных интерфейса, а затем другой интерфейс, который объединяет их. Это упростит возможность объявления одного параметра для обоих, например,

private IEncoder encoder;
private IDecoder decoder;

public ThingWhichUsesEncodeAndDecode(IEncoder encoder, IDecoder decoder)
{
    this.encoder = encoder;
    this.decoder = decoder;
}

public ThingWhichUsesEncodeAndDecode(IEncoderDecoder both)
{
    this(both, both);
}

Это действительно зависит от того, как часто вы планируете использовать одну часть, а не другую. Большую часть времени я нахожу, что для кодирования / декодирования мне нужны обе части, поэтому я бы , вероятно, просто объявил один интерфейс с обоими методами - но это зависит от конкретной ситуации.

0 голосов
/ 24 января 2009

Зависит от приложения.

Если обычно у вас есть кодировщик и декодер в одном и том же двоичном файле, один интерфейс подойдет. Если они обычно являются отдельными (например, кодирование только приложения захвата, декодирование только приложения управления), используйте отдельные интерфейсы.

0 голосов
/ 24 января 2009

рассмотрите возможность не иметь отдельный интерфейс кодера / декодера, а вместо этого

interface Encodable
{
    Decodable encode();
}
interface Decodable
{
    Encodable decode();
}
class A implements Encodable;
class B implements Decodable;
0 голосов
/ 24 января 2009

Обычно вы используете их вместе, но иногда нет. Это зависит от того, что для вас более естественно. Кстати: если вы определяете их отдельно, вы все равно можете использовать их вместе например,

interface Converter extends Decoder, Encoder { }
...