Вы реально уже одолели своими догадками. Пример с прорабом слишком прост. Когда Вам на физкультуре говорили — бери мяч и кидай его в корзину, Вы что простите говорили? Что это слишком просто, что в мире нет понятия кидай, а есть совокупность законов физики? Вы либо хотите чтобы люди в этой теме прекратили говорить о ооп, так как Вы в каждом коменте пишите, да это вообщене так и это тоже не так и просите рассказать Вам, при этом сами только предположения пишите. И знаете, для для меня слово человек, это абстракция из реального мира. Мир в котором живу я, есть люди. А если, простите придираться к словам, то что значит, подождите подождите, Вас заклинило?
Что значит для дошколят? Если Вам просто слышаться как глупо, то можете нервную систему представить, электросеть. А то что можно придумать, Вас не напрягает что Вы на английском пишите? Почему не на китайском? Почему не на клингонском? Скорее всего из-за того что Вы не любите напрягаться, а сейчас фразой о школьниках, просто сумничали. И все дело в том что ооп и должно работать с абстракциями которыми мы мыслим. Если Вы пишите по другому, то это означает только одно, Вы пишите в структурном стиле. У Вас массивы, коллекции, и объекты, вместо абстракций. Да я тоже так частенько пишу, но в такие моменты я не считаю что пишу на ооп.
Я неудачно выразился. Конкретно Вас я упомянул в контексте что где-то на школьном уровне Вам показалось что фп это круто, так как Вы описывали, какой-то выдуманный парсер. Также не понятно что Вам кажется странным по поводу асинхронности и параллельности? Даже в статье идет речь об этом, да и сегодня, мне кажется никто фп не продвигает, а продвигают все фрп. Если Вы реально говорите о школьной программе чистого фп, то я извиняюсь. И правильно, давайте скажите что я не прав сказав что нужно учить ооп! А то я знаю, я предполагаю… Чувство что Вы хотите на меня переложить свою неосведомленность, придумывая безумные выражения, что я читаю Ваши слова и уменя картина вырисовывается, что я прям монстр какой-то.
Я даже не знаю что Вы хотите услышать… то ли надеетесь, что я целую статью напишу, а возможно ждете что-то, типа «в муравейнике, муравей прораб выдает всем поручения, запечатанные в конверты… и т.д.»?
Я согласен, что посыл должен звучать, как — 'Вы должны знать прежде всего ооп, а уже когда Вы его реально поймете, тогда будет просто великолепно забивать голову чем-то другим, особенно если Вы склонны к алгебре, уравнениям и теориям множеств и хотите писать компиляторы'. Но дело в том, что те кто хвалит фп, как например Вы, имели дело с ним только в минимальном количестве и естественно пример был подогнан под него. И даже это не страшно. самое страшное что люди его хвалят за… как бы сказать… способность работать в асинхронном стиле.
Сделай это — потом это — если не смог, то — это — или это —
Так вот эта асинхронщина или параллельность, тоже никакого отношения к фп не имеет. Это просто обычная библиотека реализующая шаблоны спецификация, комманда, обсервер и прочие. И почему-то мне кажется, что такой подход впервые был применен в ооп, а затем его уже стали выдавать как фичу фп.
А можно спросить, что именно Вы писали на питоне? Возможно какой-то редактор? Или может быть выдуманный парсер чего-то, для чего реально удобней по быстрому все на функциях сделать?
На мой взгляд, плюсы ооп в том, что он повторяет абстракции реального мира. Лично мне проще понимать на примерах с зверюшками, а не на примерах математических формулах и теории множеств. Каждый раз когда мне попадается информация о функциональном программировании, то даже описание такого простого механизма как полиморфизм, больше напоминает текст для письменной доски из декораций о фильме об Альберте Эйнштейне.
Ну вот лично я никогда не сталкивался с проблемой перекрытия идентификаторов в css. А размер загружаемого css, при правильном подходе к сборке, будет, если не меньше, то точно не больше, чем c inline (который как раз увеличивает размер) или созданию из js. Понимаете, все хотят быть лучше и наверняка мечтают что в будущем, технологии смогут сделать нас совершеннее, как вид. Но если это спроецировать на конкретную проблему, то окажется, что вместо стильного, умного, многофункционального костюма, как у супергероев, с Вас сдерут кожу и кости до мяса и вкрутят дрелью стальные рельсы. Есть разница? Вот также и с css. решать проблему с помощью сборщиков, означает создать костюм супер героя, то есть не вмешиваться в процесс — внутренности, в которые предлагает лезть jsincss.
Из всех пяти перечисленных в начале плюсов, выделил для себя только один, последний, но после прочтения стало понятно, что мне, пишущему только под вэб, предлагают полюбить cssinjs потому, что кто-то, наверняка 0,,,00000%, пишет на react native. Получается что 0,001% разработчиков, которые решают каждый день проблемы, которые по другому решить невозможно, решили что теперь всем нужен их cssinjs. В большинстве случаев причины надуманы. Вместо css нужно загрузить столько же js + кавычки + сам cssinjs.
ну так ответа однозначного нет. Все дело в том, что машина может быть выражена множеством вариантов в зависимости от позиции наблюдателя — предметной области. Если бы я продавал авто, то мне бы было удобно чтобы тип «авто» инкапсулировал даже цвет. Если бы я продовал машины по запчастям, то авто бы выражалось в виде коллекции её частей. Если бы мне сказали перепроектировать архитектуру магазина авто в магазин запчастей без изменения кода, да ещё за пару часов и пару тыщь, то скорее всего я бы послал просто нафиг.
И почему не введено понятие «товар» с которым бы и проводились все операции. В условиях явно перемешались области-слои, какой Вывод Вы хотели получить? И Вы описываете структуру, а не поведение модели предметной области.
Я понимаю что мысленный, но звучит он как «овощи очень вредны, ведь если съесть три тонны лука — то умрешь».
Мне кажется что если задачу поставить заведомо неправильным образом, то она может привести к неправильным решениям. Почему Вы говорите авто-плаволка, а не транспортное средство? Почему поведение зависит от второстепенных данных не относящихся к предметной области, как например цвет?
А можно попросить объяснить мне что такое предметная область? А то я не понимаю, какое отношение имеет цвет, когда описывается предметная область сбыта автомобилей.
Но все дело в том, что у нас в голове находится в данный момент. Вы объясняете на примере рисования фигур, каким замечательным является паттерн визитер. Я говорю что он замечательный, когда работает с деревом.
Вот представьте что Вам нужно в программе напрямую работать с прямоугольником — производить расчеты сторон, площади. А вместо этого Вам дадут в руки голую модель и щепотку алгоритмов. Это немного странно.
но если Вы создаете что-то крутое, как например физический движок или библиотеку рендера в играх, то это самое то.
интерфейс это гарантия наличия api, либо выполнения контракта. а абстракция, это абстракция, которая выражается ключевым словом abstract. То есть для меня словосочетание абстрактная ЯФигура, немного дико.
и прямоугольник один, он выражен членами структуры, которые описывают информационную модель конкретной фигуры. два одноименных класса в разных пространствах это модели содержащие логику. одна считает, другая рисует. Поэтому мне не совсем понятно как в виде класса содержащего Rectangle.getArea может быть совместима с интерфейсом Rectangle.draw. Ну а так, если это дерево, то визитер, а если что-то другое, то тоже, что-то другое.
Я полностью согласен. в большинстве случаев авторы только хелпы пересказывают, а в тех случаях когда не пересказывают, в 98% несут полную чушь. А свой авторитет они доказывают воплями и нападками, а так же железными аргументами, что они все знают, а все остальные дураки.
Но несмотря на это, я легче усваиваю предварительно посмотрев, пересказ того же хелпа. Не знаю почему, но так я быстрее усваиваю информацию. Но советовать эти уроки новичкам я бы не стал, 98% из них просто не окажут никакого влияния. И мне кажется что это из-за того, что они не развиваются делая уроки, а те кто припадает удалено, вообще наняты с улицы и отбираются по критериям книжной зубрилки, которая только пересказывать может, а то что пересказывает вообще не понимает.
В программе, сама геометрическая фигура, будет выражена исключительно value object.
Если мне нужно работать с прямоугольником в калькуляторе, то я напишу класс Rectangle, который будет находится в пространстве имен geom и именно он будет работать с тем самым vo. Если мне нужно нарисовать прямоугольник, то я создам класс Rectangle в пространстве имен shape и этот класс будет производить расчеты с помощью класса rectangle из пространства имен geom. Разве нет? Мне вообще кажется, что применять визитер уместно только в структурной архитектуре, как например, деревья, как например рендер или физичиские движки, да и то в самых низкоуровневых реализациях.
Сделай это — потом это — если не смог, то — это — или это —
Так вот эта асинхронщина или параллельность, тоже никакого отношения к фп не имеет. Это просто обычная библиотека реализующая шаблоны спецификация, комманда, обсервер и прочие. И почему-то мне кажется, что такой подход впервые был применен в ооп, а затем его уже стали выдавать как фичу фп.
Мне кажется что если задачу поставить заведомо неправильным образом, то она может привести к неправильным решениям. Почему Вы говорите авто-плаволка, а не транспортное средство? Почему поведение зависит от второстепенных данных не относящихся к предметной области, как например цвет?
Вот представьте что Вам нужно в программе напрямую работать с прямоугольником — производить расчеты сторон, площади. А вместо этого Вам дадут в руки голую модель и щепотку алгоритмов. Это немного странно.
но если Вы создаете что-то крутое, как например физический движок или библиотеку рендера в играх, то это самое то.
А статья классная, кратко, но очень информативно.
и прямоугольник один, он выражен членами структуры, которые описывают информационную модель конкретной фигуры. два одноименных класса в разных пространствах это модели содержащие логику. одна считает, другая рисует. Поэтому мне не совсем понятно как в виде класса содержащего Rectangle.getArea может быть совместима с интерфейсом Rectangle.draw. Ну а так, если это дерево, то визитер, а если что-то другое, то тоже, что-то другое.
Но несмотря на это, я легче усваиваю предварительно посмотрев, пересказ того же хелпа. Не знаю почему, но так я быстрее усваиваю информацию. Но советовать эти уроки новичкам я бы не стал, 98% из них просто не окажут никакого влияния. И мне кажется что это из-за того, что они не развиваются делая уроки, а те кто припадает удалено, вообще наняты с улицы и отбираются по критериям книжной зубрилки, которая только пересказывать может, а то что пересказывает вообще не понимает.
Если мне нужно работать с прямоугольником в калькуляторе, то я напишу класс Rectangle, который будет находится в пространстве имен geom и именно он будет работать с тем самым vo. Если мне нужно нарисовать прямоугольник, то я создам класс Rectangle в пространстве имен shape и этот класс будет производить расчеты с помощью класса rectangle из пространства имен geom. Разве нет? Мне вообще кажется, что применять визитер уместно только в структурной архитектуре, как например, деревья, как например рендер или физичиские движки, да и то в самых низкоуровневых реализациях.