> ты за них топишь, как я топлю например за какой то иной подход.

Я за них уже довольно давно не топлю. Я их переосмыслил и сформировал на их основе кое что свое. Причем вполне совместимое с мейнстримом, в определенной мере.

Все за что я топил сегодня выше, это за то, что мы — не фанатики, вот и все.

Точнее, не в большей мере фанатики, чем остальные

но мы все фанатики в какой то мере. или нет

Заходят однажды социолог, искусствовед и инженер в бар. Кто из них вероятнее всего террорист? По мнению двух британских исследователей Диего Гамбетты и Стефена Хертога, это инженер. В относительно недавней книге они показывают, что вероятность для инженера стать радикальным (исламским) террористом – в 3-4 раза выше, чем у выпускников по другим специальностям. И разгадка тут не в том, что инженеры просто нужнее для террористов, потому что умеют конструировать вещи. Основываясь на статистике, авторы говорят, что разгадка - в особом «инженерном мировоззрении». Это мировоззрение имеет одну решительную черту, которая, вероятно, сближает инженеров и террористов: стремление к когнитивному замыканию (closure), или, иначе говоря, предпочтение порядка и нелюбовь к двойственности и неоднозначности. Та же черта характерна и для членов организаций с радикальными правыми взглядами, пишут авторы, и инженеров среди них тоже довольно много.

Данные выводы авторов до сих пор будоражат исследователей инженерного образования. И заставляют некоторых из них менять набор курсов для новых инженеров, делая их более ориентированными на плюрализм и открытость. Другие же полагают, что «инженерное мировоззрение» вообще мало о чем нам говорит. Во-первых, инженеры – это ну очень разные типы специальностей, не говоря уже о должностях. Во-вторых, исследователи образования говорят, что мировоззрение студентов-инженеров формируется не столько в аудиториях с формулами и графиками, сколько в общении со своими сверстниками.

Лично я согласен с критикой некоторого единого инженерного мировоззрения. К примеру, беглый анализ образования террористов-революционеров в конце XIX в Российской империи показывает, что там были и люди с техническим образованием, и с гуманитарным. Но в то же время я согласен и с тем, что в современных разработках и внедрении технологий нужно как из аксиомы исходить из разных перспектив, разных интересов, разных представлений. И об этом – уже в защиту инженеров – есть чудесная книга Гуру Мадхавана «Думай как инженер». Вроде бы тоже о мировоззрении, но совсем иначе.

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

Ты про первую главу "engineers of jihad"?

нет, я про элегантные объекты

Это может звучать абстрактно и философски

хехе, часто повторяющаяся фраза в этой книге

Понятно. "Object must be like a living creature" типа, как то так звучал оригинальный тезис. Он — эмпирический, и обычно противопоставляется всяким обьектам c именем на -ER. Я его перефразировал для себя как "Object must have a business purpose".

То есть: если у нас софт оперирует, например, умным освещением, и есть бизнес-цель — включать лампочки по скедулу, появляется интерфейс Light, а его цель определяет его публичные методы: on()/off(). Настоящая цель имеет бесконечно возможное количество решений, конкретное решение в конечном итоге выбирается бизнесом: какие лампочки мы включаем/выключаем? Может речь идет о конкретном вендоре, который дает апи? Нескольких вендорах? А может управление идет группой лампочек? А может — целой улицей? Какими конкретно лампочками мы оперируем — определяется имплменетацией. С ростом требований растет количество имплементаций, но не их размер (в отличие от сервисов). Но как бы ни росло их количество, пока бизнес-цель постоянна (включать-выключать освещение), постоянен интерфейс. Постоянство интерфейса дает тестируемость и реюзабельность (реюзабельны исключительно стабильные юниты, при этом юнит тест — ни что иное как частный случай реюза юнита). Реюзабельность дает возможность не запариваться о лампочках, при написании клиентской стороны, например, скедулера, который будет, используя интерфейс Light, управлять освещением чего угодно.

В конечном итоге у тебя получается Light — почти что обьект живого мира. Естественно моделировать его прямиком с живого мира как самоцель — не выход. Но конечный результат — такой.

окей, пока что ты понятней объясняешь)

Ну я хотя бы не сектант?

как я уже говорил - мы все сектанты. даже к такому примеру можно придраться. мне например не очень нравится понятие Light, так как оно явно указывает, что мы с каким то светом работаем и я не стал бы его вводить

а ввел бы два интерфеса Oner и Offer например)

ну это шутеечка, название какие то другие

сам считаю что нужно максимально избегать именования сущности, сущность это данные и нас не волнует чем являются эти данные, нас волнуют только свойства данных и что с ними можно сделать

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

Резонно. Поэтому я четко разделяю такие понятия как цель, и требования. Цель — это нечто постоянное. Нечто что врядли когда либо изменится, как бы ни менялись требования. Выделить цель непросто, если нет детальной экспертизы по предметной области, с первой попытки это сделать не получится, но цель архиважна для построения абстракций, она определяет их форму.

В примере выше я предположил что лампочка всегда и включается и выключается, и этом для простоты ограничился (поэтому не было резона делить интерфейс особо). На практике форма могла бы быть иной. Например, если требовалось бы регулировать цвел и яркость лампочки, появились бы Color и Brightness, а вместо Light был бы Switch какой нить...

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

но мне откровенно претит концепция объектов, я их воспринимаю только как структуры данных и не больше. и всегда делаю именно структуры данных

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