я имел в виду не на Си, а в принципе сначала был Си потом функциональщина вот до опп добрался

а функциональщина на чем была?

О том, о чем говорим)

в смысле?

много чего пробовал, потом назад на си вернулся, был erlang,scala

Каноничные труды по ООП, что есть класс в "космическом" смысле и т.п.

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

Или я хз

Каноничные труды по ООП, что есть класс в "космическом" смысле и т.п.

....тебе не надо читать "что есть класс в космическом смысле"

тебе надо что есть объект в космическом смысле и это... сложно)

потому что объект - это что-то что хранит состояние и поведение для работы с этим состоянием

Ага

мне дико нравится аналогия, что объект - это по сути мини комьютер

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

(то есть никаких геттеров и сеттеров)

стэйт должен лежать там где его надо обрабатывать

(GRASP принципы можешь почитать)

там это называлось "информационный эксперт"

Крэйг Ларман если что

Инкапсулирует в себе состояние, позволяет им управлять по строго определённой логике

http://danielwhittaker.me/2015/05/25/is-a-cqrs-command-gof-command/?utm_medium=social&utm_campaign=postplanner&utm_source=twitter.com

Ой

Данные

Инкапсулирует в себе состояние, позволяет им управлять по строго определённой логике

не только состояние, еще и логику работы с ним

ооооочень часто об этом забывают

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

Ну я это и имел в виду после

про GRASP весьма неплохо изложено тут https://www.youtube.com/playlist?list=PLmqFxxywkatStbd9hdzVOS1hZa9dc56k4

Не добавил просто

нуу то есть цель не данные спрятать, а сделать так что бы логика работы с этими данными была строго в одном месте, и логично сделать это там где данные и лежат. Именно в том "компьютере" у которого данные в его личной памяти лежат

ну и Дядю Боба - Clean Code почитай

При этом важно сохранение назначения обьекта

там все советы дельные, просто часто не объясняется в чем профит

А можно спросить? https://refactoring.guru/ru Кто-то в курсе

.хочу книжку почитать, стоит ли?

Да, на очереди вот

При этом важно сохранение назначения обьекта

опять же тут есть нюанс. Принцип единой ответственности весьма сложная штука и его часто нарушают потому что не понимают что есть "единая ответственность"

подходить к этому стоит исходя из возможных изменений

у меня как раз пример есть

Если че, я про "класс == объект" вычитал в "elemental design patterns"

class User { // ... public function isFirstMonthSinceRegistration(): bool; public function isSecondMonthSinceRegistration(): bool; }

Показалось не бредом, решил обсудить

Если че, я про "класс == объект" вычитал в "elemental design patterns"

это скорее было диким упрощением

.хочу книжку почитать, стоит ли?

хз. У Фаулера есть одноименная книжка. вот ее советую точно.

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

хз. У Фаулера есть одноименная книжка. вот ее советую точно.

а можно линк?

НО

Код с Душком Фаулера, оно?

а можно линк?

https://www.refactoring.com/refactoringBook.jpg

? спасибки

Ну да, там так и говорится. Это ради классификации отношений между четырьмя сущностями в ООП

Ну да, там так и говорится. Это ради классификации отношений между четырьмя сущностями в ООП

объект и контракт.... я насчитал только 2 сущности(

все что больше - это уже не относится чисто к ООП

Поля и методы

Тип, объект, поле, метод

https://www.refactoring.com/refactoringBook.jpg

2008 г?

короч... в моем примере если придет бизнес аналитик и скажет "а если прошло 3 месяца с регистрации что-то должно работать по другому" и нам приедся изменять User-а тоьлко ради этого. То есть этих методов там быть не должно (не та зона ответственности)

короч ладно

SOLID слишком жирный топик

Да, я понимаю о чем ты

Как вообще, имеет смысл читать относительно старую литературу, офк в ней могут подниматся темы вечные, но много времени и воды утекло, возможно есть куда более изящные решения подходы и тд?

работать надо

Как вообще, имеет смысл читать относительно старую литературу, офк в ней могут подниматся темы вечные, но много времени и воды утекло, возможно есть куда более изящные решения подходы и тд?

норм. Ничего нового за 30-40 лет так и не придумали если что

2008 г?

XP был провозглашен в 1999, думаешь много изменилось с тех пор?

только если ты по функциональщине и по теории типов загоняешься

Спасибо за пояснения)

XP был провозглашен в 1999, думаешь много изменилось с тех пор?

я не про кардинальные изменения говорю, а так минорные, мажорные)

ERROR: S client not available

минорные/мержерные идеи не относятся к концепциям

я не про кардинальные изменения говорю, а так минорные, мажорные)

книга 100% актуальна сегодня

книга 100% актуальна сегодня

спасибо)

поддерживаю

Ну да, там так и говорится. Это ради классификации отношений между четырьмя сущностями в ООП

Там чел пытался написать софт, автоматически выявляющий паттерны в коде

Ввёл свою нотацию, попытался простые отношения между методами систематизировать и уточнить. Просто не с кем это все обсудить мне было)

Там чел пытался написать софт, автоматически выявляющий паттерны в коде

А код писать оно не может само?

Ну одно из другого

Он только с отношениями между методами попытался разобраться

Делегирование, перенаправление, вот это все

Clean code - на русском дерьмовый перевод у книги?

Там чел пытался написать софт, автоматически выявляющий паттерны в коде

нуууу.... ценность софта такого весьма сомнительна. По сути все будет сводиться к анализу UML диаграммы отношений и т.д. и в целом... в этом не практической ценности. Намного интереснее просто дампнуть визуальную репрезентацию отношений (например тулзами вроде sonar или phpmetrics) и проанализировать на предмет связей.

ну то есть "паттерны" это ни в коем случае не цель а их наличие/отсутствие (хотя они так и так будут) - это так себе метрика

есть метрики получше

Clean code - на русском дерьмовый перевод у книги?

хз

по метрикам - там есть LoC (lack of cohesion) и метрики для связанности. Вот эти штуки могут быть полезными

почему для cohesion не взяли перевод "сплоченность" или альтернативное слово "целостность"

почему зацепление блин)

почему для cohesion не взяли перевод "сплоченность" или альтернативное слово "целостность"

Связность же. Как раз отражает смысл того что ты пишешь.

а coupling?)

связанность и связность ну ваще не ок, кмк

а coupling?)

А это как раз зацепление. ?

надеюсь при проектировании ты их не путаешь?)

википедия плохой источник, но все-таки https://ru.wikipedia.org/wiki/GRASP

Я их пока не использую. Я пока только изучаю.

Но название мне кажется верным.

Интересно мнение тех кто с ними давно знаком. ? Хотя это уже вопрос конкретно перевода и восприятия слова.

А это как раз зацепление. ?

Если по смыслу - coupling - внешняя связанность - coheasion - внутренняя связанность То есть coupling - это то, как модули между собой связаны, а coheasion про то, как ты объеденяешь все в модули. То есть "сцепляешь" вместе. С этой аналогией проще добиться понимания что "связанность" должна быть низкой а "зацепление" высоким. Вариант перевода со "сплоченностью" мне тож нравится но...

хз, мне в последнее время больше нравится вообще их не переводить. Хотя если я засяду таки за свои статьи мне придется какой-то вариант перевода юзать потому можно похоливарить)

в целом вариант с "зацеплением" я у Немчинского когда-то подсмотрел

так и пошло у меня

у Грега Янга вообще проще - внутренняя и внешняя связанность