Я видел канонические вопросы об именах классов / интерфейсов в StackOverflow и прочтите множество других мнения по этому вопросу, но у меня есть связанный с этим вопрос, на который я не уверен, что в любом из этих мест есть ответ. Я склонен ненавидеть соглашения об именах IInterface или ClassImpl, потому что я согласен с мнениями как в ответах на вопросы, которые я связал, так и в статье: они не нужны (с учетом современных IDE), затрудняют чтение кода и в во многих случаях необходимость использования одной из этих схем именования, кажется, подразумевает неправильный дизайн.
Однако я часто сталкиваюсь со сценарием, когда у меня есть интерфейс, который я хочу предоставить как часть моего API (обычно в отдельном пакете), а затем я создаю абстрактную реализацию интерфейса, содержащую некоторые общие функции, которые я ожидаю больше всего. (но не все) конкретные реализации. Например:
public interface Foo {
public String getBar();
}
public abstract class BasicFoo implements Bar {
private String bar;
@Override
public String getBar() {
return bar;
}
}
На практике я обычно ставлю перед именем реализации префикс Basic, но то, что я делаю, по сути, является именно тем, для чего некоторые люди используют суффикс Impl: обеспечение базовой реализации / реализации по умолчанию. Я мог бы попробовать имя, которое подразумевает, что это Foo, поддерживаемый в хранилище памяти (например, Bar), но которое всегда захватывает все функциональные возможности BasicFoo. Я также не уверен, что мне следует отказаться от интерфейса и напрямую раскрыть реализацию, потому что интерфейс обеспечивает дополнительную гибкость и развязку.
Мысли о том, как лучше справиться с этим сценарием, или о логическом соглашении об именах?
