есть

незнаю кому верить, Сергею или Кириллу

Может и есть, но ему никто не следует

Кирилл Мокевнин говорил, что никакого Закона Деметры на самом деле нет

Тут ж недавно была статья, все зависит от ього, что Кирилл имеет ввиду

И Сегей говорит, что сеттеры и геттеры это плохо, а на самом деле все не так плохо видимо, много кто их юзает в том числе и симфони

И Сегей говорит, что сеттеры и геттеры это плохо, а на самом деле все не так плохо видимо, много кто их юзает в том числе и симфони

Вопрос в том, для чего их юзать

Ну и в большинстве случаев они не нужны

А на счет публичных методов, согласен полностью с Сергеем

а есть годная лит-ра по ООП?

Бертран Мейер "Объектно-ориентированное конструирование программных систем" классика

Бертран Мейер "Объектно-ориентированное конструирование программных систем" классика

У него стоит еще про контракты почитать

человек спросил про ООП, я написал про ООП

Ну так я не против

@x3medima17 что там про контракты?

Мейер в свое время ввел такую штуку как Design by Contract

так а где почитать, в эой же книге написано?

и там и в почувствуй класс)

Бертран Мейер "Объектно-ориентированное конструирование программных систем" классика

https://vk.com/doc232854130_357487973?hash=2dbb274d25eea6ebba&dl=ee05497ac461ebd684

дима после его курса ооп так проникся эйфелем, что втирал его всем подрят)

@x3medima17 что там про контракты?

И сделал новый ЯП Контракты состоят из 3 частей - preconditions: условия которые должны выполняться в самом начале метода - посткондишн: условия которые должны выполняться после окончания метода - инварианты: условия класса которые должны всегда выполняться

и там и в почувствуй класс)

Это если в двух словах

дима после его курса ооп так проникся эйфелем, что втирал его всем подрят)

Никому я не втирал его, а защищал от тех кто не прочувствовал класс)

так а где почитать, в эой же книге написано?

нет, в другой. Посмотри библиографию Мейера. Это, в принципе, чувак, книжки которого стоит прочитать

хорошо, посмотрю

Бертран Мейер "Объектно-ориентированное конструирование программных систем" классика

Спасибо

так а где почитать, в эой же книге написано?

Touch of Class

Touch of Class

злой ты)

злой ты)

Немного)

хотя не, прочесть книгу полезно) эйфель главное не ставить

На самом деле поставить эйфель еще надо уметь

Touch of Class

Шта?

Шта?

Это книжка Мейера

охренеть, 1.2к страниц

Прикольная книжка, но затянутая

охренеть, 1.2к страниц

Вот-вот)

охренеть, 1.2к страниц

ооп? ну так то да)

кстати, пагни

а что за Вирта сткажете?

хотя это и оффтоп в ооп чате :3

книга по алгоритмам?

тяжело читается)

ну, про ценность его книг в 2017 году

нет, в другой. Посмотри библиографию Мейера. Это, в принципе, чувак, книжки которого стоит прочитать

Это видимо все его книги на русском http://www.ozon.ru/person/2339551/?group=div_book

Из статического метода класса вызывать, создавая ту самую "единственную сущность"?

все нормальные люди понимают что практика нужна выступлений, другое дело в том что стоит начинать с малой аудитории

это не первое мое выступление, где-то 3-ее, просто в тот период времени у меня завал на работе был

стыдно потому что времени на подготовку я потратил в разы меньше чем хотел

ну и из общения с людьми на курилке - никто ничего не понял

Отдельный класс под регистрацию называемый менеджмент объектом, меня сильно удивил, как и существование этого класса

О чем ты? Про то что классы-менеджеры плохо - я это и говорил. Про то что нужны некие классы описывающие последовательность действий для конкретных операций (RegisterUserHandler) - это норм, главное что бы в реализации этого "класса" небыло логики. Тупо декларировалась последовательность действий а вся логика была бы распределена по другим маленьким объектам.

эдакий моноид

эдакий моноид

почему моноид?

а не, не моноид

просто последовательность действий задается монадой

не спойлири, я сейчас в процессе изучения

а моноид это множество с единицей

О чем ты? Про то что классы-менеджеры плохо - я это и говорил. Про то что нужны некие классы описывающие последовательность действий для конкретных операций (RegisterUserHandler) - это норм, главное что бы в реализации этого "класса" небыло логики. Тупо декларировалась последовательность действий а вся логика была бы распределена по другим маленьким объектам.

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

я его даже не пишу. Я сразу пишу хэндлер

его нет смысла покрывать юнит тестами

ну, если я сразу напишу хендлер, то он будет куском говна

он мне там и обход графа сделает

и из консольки спросит через /dev/stdin

а такой тест, во всяком случае пока, помогает думать про интерфейсы и взаимодействия

эм... ну я ж себя ограничиваю)

можно начать например с такого: public function __invoke() { // get user // verify sequrity questions // deactivate account // send confirmation email }

но через тесты норм

просто я ленивый

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

ну я стабами пользуюсь

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

так я в данном случае

продумал интерфейс стабов

и контракт слегка

и понятно что дальше делать

ну через моки тоже можно)

одон и тоже

в данном случае

согласен

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

самым логичным решением потом будет выпилить его просто

ну юнит тесты с большего именно в этом ценность и несут

возможность проектировать "юниты"