количество методов в интерфейсе

Ну интерфейсы с одним методом обычно имеют свою цель, и вы можете реализовать их анонимно более легко. Мое эмпирическое правило - столько методов, сколько нужно. Но большое количество методов в одном интерфейсе обычно говорит о том, что вы можете разделить его на несколько других интерфейсов, особенно если он затрагивает различные области задач (например, интерфейс UserLoginAndAdministrationInterface становится одним интерфейсом UserLogin и одним интерфейсом UserAdministration). Вы можете реализовать в классе столько интерфейсов, сколько хотите, и они также могут быть подклассами. Так что их разделение нисколько не повредит.

Интерфейс должен иметь ровно столько методов, сколько ему нужно.

Если это число велико, то обоснование должно быть тщательно рассмотрено, но оно может быть обоснованным.

С другой стороны, в Java есть (по крайней мере) один случай, когда интерфейс не нуждается в методах (serializable) и поэтому не имеет их. Меньшее количество методов, безусловно, облегчает реализацию интерфейса, но все же может обеспечить очень полезную абстракцию. Существует ряд интерфейсов с одним методом.

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

С одной стороны, интерфейс может быть автоматически сгенерирован программой для использования другой программой и по уважительной причине может содержать 1000 методов.

Для кода, читаемого людьми, правила не могут заменить суждение.

7 ± 2

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

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

Способ работы со многими методами, когда вам нужно реализовать только несколько, - это абстрактные классы, которые предоставляют реализации по умолчанию или выбросить NotImplementedException . Если есть только один метод, это, вероятно, нормально, потому что есть методы, которые ожидают только один Iterface и вызывают этот один метод. Существует множество паттернов, например Vistor, для которых нужен только один метод.

Я бы больше беспокоился о том, чтобы интерфейс был логически последовательным, чем о том, чтобы он имел какое-то произвольное оптимальное количество методов. Тем не менее, большое количество методов может указывать на "божественный" объект, который следует рефакторить. Более четким признаком является то, что методы не согласованы, но количество методов может быть легче заметить и подтолкнуть вас к более тщательному изучению. Иногда, однако, вам просто необходимо иметь много методов, потому что существует множество возможных операций, которые вы хотели бы выполнить над объектами данного типа. Примером этого может быть что-то вроде IEnumerable в .NET. Я не могу придумать ни одной веской причины для разделения этих интерфейсов на отдельные интерфейсы, хотя в интерфейсе есть много методов.

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

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

Однако я бы подумал, что интерфейс, который имеет больше, чем, скажем, 8-10 методов, может быть возможным кодовым дымом - просто чем-то, что заслуживает 5 секунд на исследование.

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