Вероятное чрезмерное использование java-интерфейсов в моей реализации Ms. Pac-Man

Интерфейсы хорошие. Их много - не проблема.

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

Используйте интерфейс, если хотите изменить реализацию.

Для чего-то вроде вашего объекта FullGame вам, вероятно, не нужен интерфейс.

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

РЕДАКТИРОВАТЬ 2: усложняйте код только тогда, когда вам нужно. Если вы думаете, что вам нужен интерфейс, сначала остановитесь. Используйте уже имеющийся у вас класс. (Но пока вы его используете, постарайтесь не допустить вызывающих абонентов к деталям реализации.) Когда у вас будет второй аналогичный класс, вы сможете выяснить, что на самом деле интерфейс, а что реализация. Если вашим вызывающим абонентам по-прежнему нужны детали реализации, которые неудобно помещать в общий интерфейс, значит, вы недостаточно четко разделяете их.

ИЗМЕНИТЬ для более полного ответа:

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

1. У вас есть несколько реализаций этих методов с одинаковой семантикой и общими операциями, но с разными базовыми реализациями. Например, List, ArrayList и LinkedList. List - это общий интерфейс, который позволяет многим методам на основе коллекций принимать либо ArrayList, либо LinkedList. Интерфейс Collection допускает аналогичное расположение для всех коллекций.
2. Вам необходимо отделить интерфейс от реализации по архитектурным причинам. Например, у вас может быть вызывающий объект на одной машине и реализующий объект на другой. Прокси-сервер на вызывающей машине реализует интерфейс для вызова по сети реального объекта. Интерфейс означает, что вызывающему абоненту не нужно знать разницу. Это сделал Java RMI.
3. У вас должна быть возможность изменить способ вызова объекта. Например, возьмем интерфейс Image и два средства реализации, FileImage и FileImageProxy. Прокси-сервер загружает FileImage по запросу и передает вызовы интерфейса Image реальному объекту. Клиенты никогда не знают и не заботятся о том, как они получают изображение и действительно ли оно загружено; они просто знают, что есть Image, и могут его использовать.

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

Множественное наследование интерфейса, как и реализация, обычно - плохая идея.

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