Комментарии 24
Вы все неверно поняли. Статьи были не «процедурное vs ООП» а «функциональное vs ООП» – а это две большие разницы.
>я стал чаще встречать статьи написанные в стиле «процедурное vs ООП».
Проблема видимо сидит еще глубже. Приницпы ООП вполне понятны и хороши сами по себе, однако нарекания есть не на саму концепцию, а на применимость объектной декомпозиции к некоторым предметным областям (например БД-оринетированные приложения, сервис-ориентированные). ООП как инструмент хорош, однако если вы не можете декомпозировать предметную область на объекты (модули, соединяющие состояние с методами их обработки), то вы скорее всего с помощью своего языка опишете более подходящий базис и напишете код на этом базисе (сервисы, функции, предикаты — вот примеры).
И еще одна вещь: такое ощущение, что вы путаете хороший дизайн: модульность, полиморфность, декомпозицию, инкапсуляцию и так далее с ООП. Это общие понятия. Посмотрите хороший код на питоне или хаскеле. Там может не быть объектов, но он будет соответсвовать всем этим критериям.
Проблема видимо сидит еще глубже. Приницпы ООП вполне понятны и хороши сами по себе, однако нарекания есть не на саму концепцию, а на применимость объектной декомпозиции к некоторым предметным областям (например БД-оринетированные приложения, сервис-ориентированные). ООП как инструмент хорош, однако если вы не можете декомпозировать предметную область на объекты (модули, соединяющие состояние с методами их обработки), то вы скорее всего с помощью своего языка опишете более подходящий базис и напишете код на этом базисе (сервисы, функции, предикаты — вот примеры).
И еще одна вещь: такое ощущение, что вы путаете хороший дизайн: модульность, полиморфность, декомпозицию, инкапсуляцию и так далее с ООП. Это общие понятия. Посмотрите хороший код на питоне или хаскеле. Там может не быть объектов, но он будет соответсвовать всем этим критериям.
Если мы говорим об ООП, то это «программирование с использованием концепции системы объектов». Все остальные вытекающие отсюда частные выводы (как, например, «полиморфизм») вторичны.
Применимость этой концепции возможно только при достаточном уровне знаний и навыков. Именно об этом я и пишу в завуалированной (немного литературной) форме. Возможно, что мой язык изложения должен быть попроще.
Каким критериям соответствует код на питоне? Не совсем понятно из вашего комментария…
Применимость этой концепции возможно только при достаточном уровне знаний и навыков. Именно об этом я и пишу в завуалированной (немного литературной) форме. Возможно, что мой язык изложения должен быть попроще.
Каким критериям соответствует код на питоне? Не совсем понятно из вашего комментария…
>Применимость этой концепции возможно только при достаточном уровне знаний и навыков.
А я дополняю, что применимость этой концепции также невозможна без применения объектной декомпозиции. То есть написать программу в стиле OOP невозможно без OOA, OOD. Я уже 5 лет в индустрии и вижу, что функциональная декомпозиция — главенствующая (не путать с функциольным программированием). От сюда же такая любовь к Anemic Domain Model.
А я дополняю, что применимость этой концепции также невозможна без применения объектной декомпозиции. То есть написать программу в стиле OOP невозможно без OOA, OOD. Я уже 5 лет в индустрии и вижу, что функциональная декомпозиция — главенствующая (не путать с функциольным программированием). От сюда же такая любовь к Anemic Domain Model.
Я согласен что без декомпозиции никак нельзя. По большому счету, без нее нигде нельзя.
Если мы начинаем автоматизировать бух.учет, то нам обязательно нужен аналитик, который «в теме бух.учета», он разложит (OOA) всю офф-лайн систему на отдельные составляющие, сконвертирует (OOD) эту информацию в некое ТЗ и дальше отдаст программисту, который уже выберет использовать ему OOP или нет :)
Если мы начинаем автоматизировать бух.учет, то нам обязательно нужен аналитик, который «в теме бух.учета», он разложит (OOA) всю офф-лайн систему на отдельные составляющие, сконвертирует (OOD) эту информацию в некое ТЗ и дальше отдаст программисту, который уже выберет использовать ему OOP или нет :)
Все так, но это как правило хуже применимо, чем функциональный анализ. Собственно вот: c2.com/cgi/wiki?MainstreamOopUsage. Луше не скажешь. Более того я такой подход в большинстве случаев считаю оправданным. Функциональная декомпозиция ставит во главу угла процесс, что хорошо ложится на постановку задач в виде юзер стори. Предположил у нас есть юзер стори регистрации пользователя: пользователь вводит данные и нажимает «зарегестрироваться», после чего ему на почту приходит ссылка для подтверждения. Собственно имеем процесс регистрации, который разбиваем на подпроцессы создания профиля, отправку email и активации через ссылку. Каждый из процессов несложно далее разбить. Каждый процесс оперирует структурами данных: профиль, ссылка, взаимодействует с другими системами (бд, почтовый рассыльщик). Такой подход к проектированию — бомба, он является совершенно естественным и легко реализуемым в коде в виде сервисов, процедур или функций и я не верю что какой другой подход может его заменить в мейнстриме. Что говорить о крупном интерпрайзе то сейчас уже enterprise architecture == soa, что является развитием идей функциональной декомпозиции.
Всё ли что нас окружает — объекты? Идеи тоже являются объектами?
Угу, если объекты так широко трактовать, как автор, то на аргументы, что ФП лучше, можно смело отвечать: «а функция — тоже объект, хуле». Но как тут уже здорово подмечали, тогда не понятно чем ООП отличается от программирования…
Идеи имеют мысленную форму, затем переродаются в свою материальную реализацию. Идеи имеют свойства. Идею можно родить или выкинуть из головы. Почему бы и да.
Как Вы представите в виде объекта процесс? Или, допустим, AST?
Если мы подразумеваем под процессом некое действо, например, — «есть» или «бежать», то это действие (глагол) автоматически переконвертируется в существительное «Приём пищи» или, соответственно, «Оздоровительный бег» и становится объектом со своими свойствами, методами и различными вариантами расширения функциональности: «Приём пищи»->«Приём нездоровой пищи» и т.д.
Хорошо, допустим у нас есть аббревиатура AST, которую мы можем трактовать по-разному, но возьмем для примера (раз уж тут программирование) abstract syntax tree.
У этого AST есть вершина, ветки, листья (которые могу быть вырезаны или вставлены).Объект?
Подробнее об этом AST в википедии.
Но допустим, что AST — это Air Staff Target (разработка штаба ВВС), тогда это уж точно объект со своими свойствами и методами. Свойства — цели, люди (которые, в свою очередь, тоже объекты), методы — разведать, нанести удар и т.п.
Хорошо, допустим у нас есть аббревиатура AST, которую мы можем трактовать по-разному, но возьмем для примера (раз уж тут программирование) abstract syntax tree.
У этого AST есть вершина, ветки, листья (которые могу быть вырезаны или вставлены).Объект?
Подробнее об этом AST в википедии.
Но допустим, что AST — это Air Staff Target (разработка штаба ВВС), тогда это уж точно объект со своими свойствами и методами. Свойства — цели, люди (которые, в свою очередь, тоже объекты), методы — разведать, нанести удар и т.п.
> «Приём пищи» или, соответственно, «Оздоровительный бег» и становится объектом со своими свойствами, методами и различными вариантами расширения функциональности:
Это всего лишь объект-функтор или стратегия, то есть некий холдер процесса, а не сам процесс. Процесс описывается в виде процедурного кода, к примеру. Вы можете конечно же с помощью объектов описать некий процедурный язык, но это уже другая песня, так как с помощью одного базиса можно выразить другой — на функцияхх описать объекты, на объектах фугкции и да и вообще встроить интерпретатор любого языка в свой язык.
>У этого AST есть вершина, ветки, листья (которые могу быть вырезаны или вставлены).Объект?
А чем не структура данных?
Это всего лишь объект-функтор или стратегия, то есть некий холдер процесса, а не сам процесс. Процесс описывается в виде процедурного кода, к примеру. Вы можете конечно же с помощью объектов описать некий процедурный язык, но это уже другая песня, так как с помощью одного базиса можно выразить другой — на функцияхх описать объекты, на объектах фугкции и да и вообще встроить интерпретатор любого языка в свой язык.
>У этого AST есть вершина, ветки, листья (которые могу быть вырезаны или вставлены).Объект?
А чем не структура данных?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Всё что нас окружает — объекты