Нууу, вариант из пропозала, выглядит симпатичнее, не требует таких изменений в reflect и ast + честно говоря, я не понимаю смысл инициализиторов как таковых - это решается конструкторами, зачем два способа делать одно и то же
Ну по поводу ORM, соглашусь плностью. Мне кажется люди приходят с других языков и такие, хм а где ту орм? надо написать.
По поводу тегов ну их уже используют, кто как кому не лень, ну и во многих вещах(например форматы кодирования) определенно есть смысл - типизированные теги, хотя бы навели некоторый порядок
когда потребителей несколько, интерфейс можно вынести в слой. Важно, что он всё равно формируется от требований использования, а не от реализации, просто потребителей становится несколько.
Давненько не читал код на пхп, но точно помню что как минимум публичные методы пишутся в начале файла, приватные и протектед под ними. Даже если написано в таком стиле, вы же не в блокноте работаете, IDE и так показывает структуру
Есть документация плюс сигнатуру публичных методов и так видно в структуре их не надо искать. Если реализация написана хорошо, в ней легко ориентироваться, если там бардак, то интерфейс не поможет.
Лучший способ помочь читающему, это хорошо оформить свой код, на это надо тратить время, тк код пишется один раз а читается сотни и тысячи.
Это не вопрос экономии времени, философия языка в том, что интерфейсы, в общем случае (те, когда нет явных причин сделать по другому), принадлежат потребителю
Контракт и так объявляется реализацией, очевидным образом. Все остальное, как правило, относиться к зоне ответственности того, кто ей пользуется. Go way не создавать ненужные абстракции. Интерфейс ради интерфейса не добавляет никакой ценности
А с ним все в порядке. Смысл ISP в классических ооп языках состоит в том, чтобы заставить автора разделять крупные интерфейсы на маленькие, чтобы потребитель не был вынужден реализовывать методы, которые ему не нужны. В го интерфейс вообще не обязан существовать до тех пор, пока его не потребуют. ISP проявляется, а на стороне потребителя который создаёт настолько маленький интерфейс, насколько ему нужно, так что все ок с соблюдением принципа
плюс если автор следует принципу единственной ответственности (SRP), то поверхность апи у реализации и так будет небольшой
при желании выйти за абстракцию GC можно c помощью очисток и вялых указателей
ну вот со стандартизацией как раз и проблема(
Нууу, вариант из пропозала, выглядит симпатичнее, не требует таких изменений в reflect и ast + честно говоря, я не понимаю смысл инициализиторов как таковых - это решается конструкторами, зачем два способа делать одно и то же
Ну по поводу ORM, соглашусь плностью. Мне кажется люди приходят с других языков и такие, хм а где ту орм? надо написать.
По поводу тегов ну их уже используют, кто как кому не лень, ну и во многих вещах(например форматы кодирования) определенно есть смысл - типизированные теги, хотя бы навели некоторый порядок
Если честно, не очень из коммента понял, как вы видите аннотации/атрибуты в го. Можно пример каким нибудь псевдокодом?
чтобы потребитель мог не знать о реализации и не иметь зависимости от пакета с ней
пока потребитель один интерфейс живет приватно, на уровне пакета потребителя, не надо ничего преждевременно делать.
Экспортируемые методы реализации это и есть контракт. Интерфейс тут ничего не улучшит.
Извините, а вы точно дочитали до конца? я просто про это же и говорил примерно
когда потребителей несколько, интерфейс можно вынести в слой. Важно, что он всё равно формируется от требований использования, а не от реализации, просто потребителей становится несколько.
great minds think alike=) Спасибо, почитаю
в го поля и методы именованные с маленькой буквы видны только на уровне пакета
Давненько не читал код на пхп, но точно помню что как минимум публичные методы пишутся в начале файла, приватные и протектед под ними. Даже если написано в таком стиле, вы же не в блокноте работаете, IDE и так показывает структуру
Все так, не знаю кто вам минус поставил
Да, но в целом если возникли циклические зависимости, то скорее всего что то не то с этим кодом
Есть документация плюс сигнатуру публичных методов и так видно в структуре их не надо искать. Если реализация написана хорошо, в ней легко ориентироваться, если там бардак, то интерфейс не поможет.
Лучший способ помочь читающему, это хорошо оформить свой код, на это надо тратить время, тк код пишется один раз а читается сотни и тысячи.
Это не вопрос экономии времени, философия языка в том, что интерфейсы, в общем случае (те, когда нет явных причин сделать по другому), принадлежат потребителю
Контракт и так объявляется реализацией, очевидным образом. Все остальное, как правило, относиться к зоне ответственности того, кто ей пользуется. Go way не создавать ненужные абстракции. Интерфейс ради интерфейса не добавляет никакой ценности
абсолютно верно, инкапсуляция достигается не интерфейсами
>возвращают разные типы
и это первая хорошая причина, сделать интерфейс
А с ним все в порядке. Смысл ISP в классических ооп языках состоит в том, чтобы заставить автора разделять крупные интерфейсы на маленькие, чтобы потребитель не был вынужден реализовывать методы, которые ему не нужны. В го интерфейс вообще не обязан существовать до тех пор, пока его не потребуют. ISP проявляется, а на стороне потребителя который создаёт настолько маленький интерфейс, насколько ему нужно, так что все ок с соблюдением принципа
плюс если автор следует принципу единственной ответственности (SRP), то поверхность апи у реализации и так будет небольшой