так можно в классах имена полей придумывать каждый раз разное

Правильный ответ, если что, "зачем вообще в билдере такие же поля как у класса, пускай хранит сам объект класса)"

потому что там name и там name

потому что поле name хранится уже в одном классе

что в этом такого, это ж билдер

все проще - поля не часть контракта

в java могут быть частью интерфейса а значит и контракта, в пхп не часть 100% согласен

в java могут быть частью интерфейса а значит и контракта, в пхп не часть 100% согласен

в смысле?

в том что можно в конктракте знать что есть метод возвращающий что то с другим контрактом(интерфейсом) и вызывать что то у него

а может быть свойство с нужным интерфейсом обращаешься к свойству

в java могут быть частью интерфейса а значит и контракта, в пхп не часть 100% согласен

еще раз. каким боком в java проперти могут быть частью контракта?

а может быть свойство с нужным интерфейсом обращаешься к свойству

ты типа LoD решил нарушить?

Что за LoD

Law of Demeter

ты типа LoD решил нарушить?

это уже програмисты будут нарушать

и тут вопрос к команде

по хорошему я согласен с тобой и такое делать не надо

но опять же зависит от команды

когда у тебя группа из программистов и так исторически принято

то ты в меньшинстве

и тебе надо объяснять почему это плохо

такова реальность

стой

ты опять начинаешь уходить от ответа

хорошо

вопрос - каким образом в java поля являются частью контракта?

публичные поля абстрактного класса?

в java в Interface могут быть объявленны fields (там их так называют, в php property но смысл один)

в java в Interface могут быть объявленны fields (там их так называют, в php property но смысл один)

давай пруфы

сейчас

Блин, ООП сложнее ФП)

Ребят, есть у кого может быть статейка нормальная как работают генераторы? В частности в php Сорри за оффтоп.

Блин, ООП сложнее ФП)

фп чуть-чуть проще но идеи примерно те же

Ребят, есть у кого может быть статейка нормальная как работают генераторы? В частности в php Сорри за оффтоп.

не тот чатик и вообще это есть в гугле

Ребят, есть у кого может быть статейка нормальная как работают генераторы? В частности в php Сорри за оффтоп.

так врде в офф доке все норм описано, даже на русском

в java в Interface могут быть объявленны fields (там их так называют, в php property но смысл один)

Они случаем не static final?

то есть это константы по сути

Угу

ясно понятно

ну я уже нагуглил

а то уж испугался

ну тогда это не может быть частью контракта

у кого тут контракт головного мозга?))) Можешь сказать откуда это понятие возникло, ну т.е. когда это решили и кто (назови имена!!! шучу))). Я как то гуглил не нашел.

ну можно попробовать назвать Барнтрана Мэйерса

86-ой год вроде или 88-ой

у кого тут контракт головного мозга?))) Можешь сказать откуда это понятие возникло, ну т.е. когда это решили и кто (назови имена!!! шучу))). Я как то гуглил не нашел.

Так было всегда с момента сотворения мира

ну и в целом это развитие идей information hiding которые были еще в начале 70-хэ

во у меня на столе

а вообще можешь Хоара обвинить с его логикой)

во у меня на столе

а ты читал то ее?) а то про Мэйерса говорят что все цитируют но никто не читал)

читаю, она на английском - тяжко

давай пруфы

https://gist.github.com/29ccd964b5f8356869805b5f717fc01e

мы уже выяснили что это просто контстанты

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

String это объект

такойже как например ArrayList

внутри которого есть свои методы с поведением

как например такое https://gist.github.com/eecd9199c810e50af9a37f39980c09d4

пихаешь туда любой mutable объект и творишь магию

String это объект

и каким образом это относится к контракту MagicInterface?

это все очень плохо

но возможно

а еще в Java 8 в интерфейсе можно писать код который со своими ограничениями но возможно что то исполнять)

это не его часть

мне кажется твоя проблема в том, что "интерфейсы" != контракты

ну мол интерфейс объекта это не тоже самое что что-то с ключевым словом interface

мне кажется твоя проблема в том, что "интерфейсы" != контракты

возможно

а ты читал то ее?) а то про Мэйерса говорят что все цитируют но никто не читал)

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

интерфейс объекта это класс и его публичные методы и свойства

иногда от класса отходят и используют какой то интерфейс который реализует объект

и тогда интерфейс это набор методов в данной роли

ну так очень идеализированно

и с кучей допущений

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

ты про DbC? там суть в прекондишенах, инвариантах и посткондишенах

ну то есть у тебя контракт

контрактом может быть только поведение какое-то

его можно характеризовать как раз таки прекондишенами, посткондишенами и инвариантами

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

Вся теория накладывается просто на конкретную реализацию в ооп языке интерфейсов и других способов использования объекта

Вся теория накладывается просто на конкретную реализацию в ооп языке интерфейсов и других способов использования объекта

поэтому мне нравится erlang

А мне паскал

его можно характеризовать как раз таки прекондишенами, посткондишенами и инвариантами

хм, ну ладно согласен...вероятно ветер дует от него

Теперь пинайте

хм, ну ладно согласен...вероятно ветер дует от него

ну тут такое, можно еще работы той же Барбары лисков попробовать порыть, там те же идеи

мэйерс просто слово контракт как мне кажется популяризировал но это не точно

Барбара там вродь над АТД мучались помоему

http://wiki.c2.com/?DesignByContract

там чуть больше истории

Pre- and postconditions were first supported natively in a language in BarbaraLiskovs CLU (circa 1974 - 1977).

Hoare's 1972 Acta Informatica paper described the use of representation invariants and abstraction functions to prove correctness of abstract data types.

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

Hoare's 1972 Acta Informatica paper described the use of representation invariants and abstraction functions to prove correctness of abstract data types.

Да уж, точно походу дойдем что Иисус придумал и передал Лисков

Ну круто, теперь хоть что то

Как это знание на практике поможет?

это чисто мне было интересно

что бы понять контракты, нужно стать контрактом, думать как контракт....Это я шучу, просто иногда на некоторые вещи интересно посмотреть со стороны имено авторов

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

Три строки кода превращаются в три модуля с пятью лишними абстракциями

Но потом скажут ЗАТО ООООООП

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

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