Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
бабушка с татуировкой Кобола— это отсылка к «Девушка с татуировкой дракона»?
Смысл ООП совершенно не в инкапсуляции и наследования, а в обмене сообщениями между обьектами. И инкапсуляция, и наследование существует и безо всякого ООП.
Смысл ФП вовсе даже не в иммутабельности, а в чистых функциях без побочных эффектов. Мутабельность внутри них вполне себе имеет место быть.
Смысл ООП совершенно не в инкапсуляции и наследования, а в обмене сообщениями между обьектами.
Это неправильное определение ООП. ООП — это как раз инкапсуляция, наследование и полиморфизм.
Смысл ФП вовсе даже не в иммутабельности, а в чистых функциях без побочных эффектов. Мутабельность внутри них вполне себе имеет место быть.
Знаем, на Хаскелле писали. Но в Хаскелле действительно все переменные неизменяемые, так что Дядя Боб всё верно написал. И когда пишешь на Хаскелле, то пытаешься всеми силами не прибегать к мутабельности, т.к. такие действия приходится в монады заворачивать, что резко усложняет код.
Этой войне миллион лет.
И трактовок от основателей до современных.
Уж не помню, что пишет конкретно Дядя Боб, хотя «чистая архитектура» очень годная, но человек в чем то прав — смысл ООП в структурировании кода в объекты и формирования связей между ними. Автор концепции вообще считал, что самое важное — это сообщения.
А полиморфизм, инкапсуляция и наследование — это принципы, инструменты для достижения этих целей.
При этом полиморфизм вообще не фича ООП (хотя и нужна для него), инкапсуляцию можно успешно имитировать организационными мерами, а наследование реализаций вообще во многих кругах предано анафеме. Кроме того, существует прекрасный компонентный подход, который реализуется через композицию.
И да, ООП — это лишь идея, и организовать код в ООП стиле можно во многих языках с достаточыным количеством возможностей, даже если средства не полностью адаптированы, например С и Rust
И трактовок от основателей до современных.
Уж не помню, что пишет конкретно Дядя Боб, хотя «чистая архитектура» очень годная, но человек в чем то прав — смысл ООП в структурировании кода в объекты и формирования связей между ними. Автор концепции вообще считал, что самое важное — это сообщения.
А полиморфизм, инкапсуляция и наследование — это принципы, инструменты для достижения этих целей.
При этом полиморфизм вообще не фича ООП (хотя и нужна для него), инкапсуляцию можно успешно имитировать организационными мерами, а наследование реализаций вообще во многих кругах предано анафеме. Кроме того, существует прекрасный компонентный подход, который реализуется через композицию.
И да, ООП — это лишь идея, и организовать код в ООП стиле можно во многих языках с достаточыным количеством возможностей, даже если средства не полностью адаптированы, например С и Rust
ООП — это как раз инкапсуляция, наследование и полиморфизм.
а вот Алан Кей, создатель ООП, говорит об обратном, сами объекты менее важны, чем сообщения.
В Rust есть инкапсуляция, наследование и полиморфизм, но это не ООП язык.
И когда пишешь на Хаскелле, то пытаешься всеми силами не прибегать к мутабельности
стараться не прибегать к мутабельности, и смысл ФП — разные вещи. ФП — это скорее отсутствие состояния, а вовсе не иммутабельность. И в том же Хаскеле кстати вполне себе есть наследование, полиморфизм и инкапсуляция. Но что то никто его к ООП-языкам не причисляет. Что как бы намекает.
Вы (и автор статьи) путаете сами концепции с часто используемыми инструментами реализации этих концепций.
А вот Алан Кей, создатель ООП, говорит об обратном, сами объекты менее важны, чем сообщения.
То, что создал Алан Кей, мало имеет отношения к тому, что сейчас принято называть ООП. То самое ООП, которое он создал, это скорее модель акторов типа Akka или Erlang. Мне удобнее мыслить в терминах интерфейсов и классов, и там нет никаких сообщений (по крайней мере first-class), а есть инкапсуляция, наследование и полиморфизм.
В Rust есть инкапсуляция, наследование и полиморфизм, но это не ООП язык.
Ну и что? Самокат – это транспортное средство, но транспортное средство – это не обязательно самокат.
стараться не прибегать к мутабельности, и смысл ФП — разные вещи. ФП — это скорее отсутствие состояния, а вовсе не иммутабельность
Какая-то каша. Сначала вы про чистые функции говорите, теперь вот почему-то уже это отсутствие состояния. Вообще иммутабельность, отсутствие состояния и чистые функции – это вовсе не взаимоисключающие понятия. Скорее наоборот, это тесно связанные вещи, и если используешь что-то одно, то, скорее всего, ты автоматически получаешь другое. Если ты используешь только иммутабельность, то у тебя 99% кода будет чистым. И если ты пишешь только чистые функции, то у тебя, почти всё будет иммутабельное.
И в том же Хаскеле кстати вполне себе есть наследование, полиморфизм и инкапсуляция
Откуда в Хаскелле наследование? Тайпклассы – это не наследование. Это реализация интерфейса, что совсем не то же самое. Полиморфизм там есть, но другой. В ООП это подтиповой полиморфизм, а там параметрический.
если в программах использовать только if, do, while, то тогда такие программы можно легко рекурсивно разделять на более мелкие единицы, которые в свою очередь уже легко доказуемы
Это все хорошо, но мало. Сейчас, по факту, нужны иерархическая модульность программ и, возможно, «итерационное» программирование.
Модульность может быть на уровне кода, функций, файлов, каталогов, проектов, решений (в терминологии Visual Studio). Кроме того, может быть внешняя модульность на уровне, плагинов, dll, компонент (COM / ocx), драйверов и т.п. Можно еще говорить о сетевом распределении программного кода, типа клиент-серверных систем и т.д. и т.п.
Также достаточно интересно «итерационное» программирование. В моем понимании, это упорядоченная последовательность каталогов с проектами / решениями, скажем, Visual Studio. Каждый последующий проект расширяет возможности предыдущего, причем в документации четко оговаривается, что именно, каким образом и за счет чего. Расширения должны быть обозримыми, чтобы не перенапрягать мозг.
Я лично предпочитаю стандартизацию имен на уровне файлов и каталогов для общего решения. Допустим, главный проект (папка) называется «Модульный Учет». В ней расположены папки Main000, Main001, Main002 и т.д.
Все проекты в папках MainXXX имеют основное имя «Main»: Main.sln, Main.vcxproj, Main.cpp, Main.h, Main.rc и т.п. Имена файлов классов тоже стандартизированы, типа: MainFrame.cpp, MainFrame.h. Также унифицируется файловая структура проекта, которая постепенно наращивается.
Если на уровне итерации M обнаружены ошибки из модуля N, то они исправляются в начальном каталоге и всех последующих. Для этого можно использовать средства Питона для рефакторинга всей иерархии проекта.
Постепенно подобная организация наводит на мысль, что проектирование приложения это что-то похоже на конструктор. Скажем в WTL (и не только) есть мастер генерации приложения по выбранным параметрам. Очень хотелось бы иметь некий, более мощный, супермастер для генерации проектов определенного класса, например, задач со стандартным оконным интерфейсом, который мог бы иметь расширяемую модульную структуру. Само приложение могло бы быть основано на сценарии, по которому бы скрипт, типа Питона, генерировал конечный проект.
Так что было бы более интересно что-то почитать на эту тему, а не про то нужен оператор goto или нет.
«Не позволяет нам доступаться до» — сие какой-то колхоз. Еще б «докопаться» придумали…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чистая архитектура. Часть II — Парадигмы программирования