Определение пустого интерфейса и его последствий

Question

Недавно я столкнулся с ситуацией, когда я хотел, чтобы набор классов передавался в метод (чтобы метод принимал интерфейс в качестве параметра).

Однако у классов в интерфейсе было разное количество методов, поэтому сам интерфейс был пустым.

Что, если что, это говорит о дизайне моего приложения? В этом случае я собирался использовать абстрактный класс, но у меня были интерфейсы, поэтому что-то, вероятно, мешало мне использовать абстрактные классы (не помню, что).

Язык: C # (хотя это не зависит от языка).

Answer 1

То, что вы описали, это «интерфейс маркера».

http://en.wikipedia.org/wiki/Marker_interface_pattern

Как и в любом шаблоне проектирования, в этом нет ничего хорошего или плохого, если он является правильным шаблоном для выполняемой задачи.

Answer 2

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

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

Answer 3

Что, если что, это говорит о дизайне моего приложения?

Может быть, это говорит о том, что вам нужно немного подумать о том, где на самом деле лежат определенные обязанности? Запомните принцип подстановки Лискова (LSP): подтипы должны заменять свои базовые типы. Также я бы помнил Принцип единой ответственности (SRP). Но самое главное, чтобы все было просто.

Я часто обнаруживал, что только после того, как я собрал что-то подобное и некоторое время работал с ним (с разных точек зрения и в разных случаях использования), все становится понятным. Так что можно сказать, что вы имеете в виду что-то, но вам еще не ясно, как лучше это сделать - это круто; заставить что-то работать, а затем рефакторинг, когда вы будете готовы.