Первое, на что стоит обратить внимание, это то, что мы видим не задачу. Задача может звучать, например, как «создать систему поддержки пекарни», а в подзадачи входить отслеживание прихода и ухода продуктов, расхода топлива, контроль условий эксплуатации и т.д. ООП нас учит как раз тому, что предложил автор — смоделировать процесс приготовления пищи
Если задача стоит «создать систему поддержки пекарни, подзадачи которой 1), 2) и 3)», то зачем моделировать процесс приготовления пищи? И почему именно этому учит ООП? Что-то подобное идёт из DDD, да. Опишем модель процесса приготовления пищи и затем поверх забабахаем то, что нам на самом деле нужно. Но разве ООП нас заставляет так делать? Если я включаю мозг на 1 шаг раньше и не бросаюсь описывать модель, а бью систему на актёров и юзкейсы и уже в рамках каждого смотрю, что мне с ним делать дальше — это что? (Исходя из вашей логики, складывается ощущение что вы бы это назвали чем-то другим, нежели ООП-подходом)
Если не сложно, поясните, пожалуйста, почему означенная проблема особенно заметна в ООП. Именно этот тезис я извлёк из вашей статьи и именно он у меня вызывал абсолютное непонимание.
Опять ведь за старое. Это претензия к разработанной вами структуре классов, а не к ООП! И опять же, когда нужно просто удалить файл, для этого можно написать метод, который делает только удаление файла. Зачем, если вы используете ООП, обязательно пытаться всё усложнить и предусматривать ненужные мелочи? А затем всё сваливать на парадигму. Просто решайте поставленную задачу, а правильное применение ООП поможет снизить стоимость переделок.
Это типа вы сейчас сказали, что DSL, SOA и прочее — это какая-то новая парадигма? И сервисы не имеют поведения, не имеют внутреннего состояния, а DSL не оперируют предметной областью и мы на них не описываем поведение объектов этой самой области? И кубик — это не объект с кучей данных, да? И даже когда задача сводится к установке готового продукта, его настройке и интеграции с кучей других — там внутри нет ООП? По-моему, это оно самое — проектирование, объектно-ориентированное. Код тут лишь вершина айсберга, а в его низах кое-что другое, о чём писал автор в статье.
Вот для вас и написана эта статья :)
Ну зачем предусматривать ВСЕ нюансы поведения модели и пытаться учесть всё-всё? Вы же при проектировании ПО так никогда не делаете, потому что YAGNI. И невозможно это. К ООП это не имеет никакого отношения. А только к выбору правильной абстракции.
Ну я же чувствую, что в глубине души мы все втрём согласны :) GoF — это офигенно! Но только после того, как ты сделаешь первый уверенный шаг в сторону ООП, не спотыкаясь
Нет, вы именно ругаетесь. Даже вот последней строчкой вашего комментария. В ООП на самом деле всё хорошо, если не сводить логические рассуждения к холиварам get/set vs public field. Концентрация на такой ерунде вторична и только лишь говорит о том, что обе стороны спора — не знают или не хотят знать ООП.
Вы так подробно сконцентрировались на 4х принципах ООП, расписали их и пришли к выводу, что ООП их не открывало, эти принципы были всегда, и удовлетворение им — это ещё далеко не ООП. Разве кто-то утверждал обратное? Вспомните банально математику — из ООП следуют эти 4 принципа. Наоборот — нет. Значит, есть что-то ещё. Правильно, моделирование. Оно всегда было с нами, ещё до изобретения компьютеров и С++. Просто в какой-то момент программисты осознали, что оказывается можно моделировать и в коде! И назвали это ООП. Чётко и понятно — парадигма, вводящая понятия объектов, связей между ними, что даёт нам возможность моделировать предметную область на её же языке, используя объекты. Объект может иметь поведение и состояние. Как в реальном мире — меня зовут Антон, я живу в Санкт-Петербурге и я умею стучать по клавиатуре. И моделируя окружающий мир, становятся очевидными 4 принципа, без которых модель получается нежизнеспособной. Вам дали мощный инструмент, позволяющий выражать проблему в коде более наглядно, нежели это позволяют структуры и функции! И сформулировали принципы, помогающие проектировать предметную область с меньшим числом нестыковок. Да, чтобы проектировать качественные модели — нужно уметь пользоваться данным инструментом. Вам в этом помогают GoF, Эванс, Макионелл, Фаулер. Кто говорил, что будет просто? Попробуйте вспомнить школу или ВУЗ, когда был процедурный паскаль — ведь всё-равно в любой программе на нём чувствовалась частичка ООП, потому что это довольно естественно, моделировать задачу и её решение. Вот вам и дали объекты, чтобы избавить от всего этого вороха функций и структур, помочь сконцентрироваться на главном — как решить поставленную задачу, а не раздумывать над синтаксисом перегрузки функций, чтобы считать площадь, используя ссылки на структуры типа square, circle или ellipse.
А что же конкретно вы подразумеваете под инкапсуляцией и можно ли назвать код объектно-ориентированным, если не использовать геттеры\сеттеры — это по сути остаётся в стороне. Со временем, спроектировав достаточное количество моделей, ответы на эти вопросы сами появятся. Потому что it depends, и чёткого определения быть не может. Есть только набор базовых общих принципов и объекты :) И никто ничего не изобретал, ООП всегда было вокруг нас.
А вы читали код студента (начинающего программиста) после прочтения GoF? Я видел и чужой, и свой :) Пока ты не в теме ООП и не мыслишь объектно, любая задача сводится к «какие 5 паттернов я смогу сюда применить». Затем, спустя кучу зафакапленных проектов, ты перечитываешь GoF и тут наступает прозрение…
Весь этот эпический… разговор в комментах, по-моему, как раз из-за этого и разразился: со стороны кажется, что автор ругает ООП, потому что он не даёт чёткого алгоритма написания программ. Да, это так. По-этому на мой взгляд статья несколько надуманная.
veitmen выразил мысль, очень похожую на довольно распространённое мнение про GoF и подобные книги. Студенту читать подобное — противопоказано. Он будет думать что ООП == паттерны, паттерны == silver bullet и как результат: «Нам не нужен в будущем такой специалист». Подобные книги можно читать только после того, как мозг настроился на ООП, а юношеский максимализм (утрирую) — прошёл.
Но есть вопрос:
Если задача стоит «создать систему поддержки пекарни, подзадачи которой 1), 2) и 3)», то зачем моделировать процесс приготовления пищи? И почему именно этому учит ООП? Что-то подобное идёт из DDD, да. Опишем модель процесса приготовления пищи и затем поверх забабахаем то, что нам на самом деле нужно. Но разве ООП нас заставляет так делать? Если я включаю мозг на 1 шаг раньше и не бросаюсь описывать модель, а бью систему на актёров и юзкейсы и уже в рамках каждого смотрю, что мне с ним делать дальше — это что? (Исходя из вашей логики, складывается ощущение что вы бы это назвали чем-то другим, нежели ООП-подходом)
Ну зачем предусматривать ВСЕ нюансы поведения модели и пытаться учесть всё-всё? Вы же при проектировании ПО так никогда не делаете, потому что YAGNI. И невозможно это. К ООП это не имеет никакого отношения. А только к выбору правильной абстракции.
Вы так подробно сконцентрировались на 4х принципах ООП, расписали их и пришли к выводу, что ООП их не открывало, эти принципы были всегда, и удовлетворение им — это ещё далеко не ООП. Разве кто-то утверждал обратное? Вспомните банально математику — из ООП следуют эти 4 принципа. Наоборот — нет. Значит, есть что-то ещё. Правильно, моделирование. Оно всегда было с нами, ещё до изобретения компьютеров и С++. Просто в какой-то момент программисты осознали, что оказывается можно моделировать и в коде! И назвали это ООП. Чётко и понятно — парадигма, вводящая понятия объектов, связей между ними, что даёт нам возможность моделировать предметную область на её же языке, используя объекты. Объект может иметь поведение и состояние. Как в реальном мире — меня зовут Антон, я живу в Санкт-Петербурге и я умею стучать по клавиатуре. И моделируя окружающий мир, становятся очевидными 4 принципа, без которых модель получается нежизнеспособной. Вам дали мощный инструмент, позволяющий выражать проблему в коде более наглядно, нежели это позволяют структуры и функции! И сформулировали принципы, помогающие проектировать предметную область с меньшим числом нестыковок. Да, чтобы проектировать качественные модели — нужно уметь пользоваться данным инструментом. Вам в этом помогают GoF, Эванс, Макионелл, Фаулер. Кто говорил, что будет просто? Попробуйте вспомнить школу или ВУЗ, когда был процедурный паскаль — ведь всё-равно в любой программе на нём чувствовалась частичка ООП, потому что это довольно естественно, моделировать задачу и её решение. Вот вам и дали объекты, чтобы избавить от всего этого вороха функций и структур, помочь сконцентрироваться на главном — как решить поставленную задачу, а не раздумывать над синтаксисом перегрузки функций, чтобы считать площадь, используя ссылки на структуры типа square, circle или ellipse.
А что же конкретно вы подразумеваете под инкапсуляцией и можно ли назвать код объектно-ориентированным, если не использовать геттеры\сеттеры — это по сути остаётся в стороне. Со временем, спроектировав достаточное количество моделей, ответы на эти вопросы сами появятся. Потому что it depends, и чёткого определения быть не может. Есть только набор базовых общих принципов и объекты :) И никто ничего не изобретал, ООП всегда было вокруг нас.
+1