Aggregator резюме программистов

[Вурдалак]

Т.е. Логгер и репозиторий были бы абстрактными классами, чтобы однозначно определять сущность наследника. Т.е. FileLogger extends Logger implements Serializable - это логгер, умеет он сериализоваться или нет. А по текущим привычкам все делать интерфейсом ктото может сделать MegaUserRepoLogger implements Logger, UserRepository.

Мне кажется, что это не совсем справедливое требование по отношению к реализации. Разве для тебя, как для пользователя интерфейса, это что-то поменяет?

 

[Adelf]

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

 

[Вурдалак]

@Adelf я не вполне понимаю твою позицию: именовать интерфейс логгера как Logger — это плохо?

 

[Adelf]

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

 

[fixxxer]

Ну когда еще знакомился с основами ооп были там такие понятия... Т.е. Логгер и репозиторий были бы абстрактными классами, чтобы однозначно определять сущность наследника. Т.е. FileLogger extends Logger implements Serializable - это логгер, умеет он сериализоваться или нет. А по текущим привычкам все делать интерфейсом ктото может сделать MegaUserRepoLogger implements Logger, UserRepository.

Кстати, что-то в этом есть! Если Logger - pure abstract class, то это в принципе тот же интерфейс, но два таких интерфейса заимплементить в одном классе не получится, что логично, так как это основное назначение объекта. А Serializable/Countable/Fooable - пожалуйста, где угодно в любых комбинациях.

 

[fixxxer]

У меня такой подход получился в TypeScript сам по себе из-за технических ограничений, но вот щас кажется, что это и логически вполне разумно.

Там интерфейсы - это чисто compile-time штука для проверки типов, со своим пространством имен, которое не эмитит js-кода, так что в DI их использовать напрямую не получится. А вот абстрактный класс компилируется, так что пожалуйста.

Потому всякие Logger-ы (то, что нужно инжектить) - это у меня pure abstract-классы, а всякие Fooable - интерфейсы (мне в рантайме о них знать и не надо).

Правда, TS позволяет указывать в implements классы (это означает - использовать фактический интерфейс класса в качестве, собственно, интерфейса). Я так и пишу, pure abstract classes это как бы просто такой workaround, чтобы не связываться с дублированием интерфейсов символами (или чем-то еще, что емитит JS) только ради DI. Теперь задумался, может, лучше и в extends

 

[Adelf]

так что в DI их использовать напрямую не получится

Так и должно быть. Никакой класс не будет зависеть от Serializable. Перешли к интерфейсам наверняка из-за возможности отнаследоваться от какого-то класса и реализовать такой интерфейс. Налицо пренебрежение к композиции!