Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Кто-нибудь кроме автора топика читал этот 1200-страничный Must Have? Поделитесь пожалуйста отзывами.
Я читал, но у меня есть оправдание — был в армии. Очень хороший труд, рекомендую всем программистам.
Я прошла оба интутовских курса по книге (это считается?). Понравилось. Думаю, что надо бы повторить.
«Complete Code» Файлера Вы, естественно, тоже не читали? :-)
Язык Эйфель — отстой.
Идея дизайна по контракту — неплохая, но не тогда, когда контракты встроены в язык.
1. Когда начинается взаимодействие с внешним миром, для качественного описания контракта приходится написать очень много кода.
2. Когда начинается конкурентное программирование, начинаются костыли. В обычном ОО-языке синхронизацию и доступ, свободный от блокировок, можно изящно реализовать. В концепции дизайна по контракту — нет.
Майер предложил идею маркировать типы специальным образом; с помощью этой насадки можно реализовать потоковую модель наподобие Microsoft COM Apartment, но у неё есть известные ограничения. Когда на CSA Russia в ЕКБ пару лет назад аудитория начала говорить ему об этом, он психанул, бросил на пол ноутбук и выбежал из аудитории :-)
Идея дизайна по контракту — неплохая, но не тогда, когда контракты встроены в язык.
1. Когда начинается взаимодействие с внешним миром, для качественного описания контракта приходится написать очень много кода.
2. Когда начинается конкурентное программирование, начинаются костыли. В обычном ОО-языке синхронизацию и доступ, свободный от блокировок, можно изящно реализовать. В концепции дизайна по контракту — нет.
Майер предложил идею маркировать типы специальным образом; с помощью этой насадки можно реализовать потоковую модель наподобие Microsoft COM Apartment, но у неё есть известные ограничения. Когда на CSA Russia в ЕКБ пару лет назад аудитория начала говорить ему об этом, он психанул, бросил на пол ноутбук и выбежал из аудитории :-)
В обычном ОО-языке есть, условно говоря, правила гигиены и шаблоны, по которым надо проектировать конкурентный доступ.
1. Состояние, разделённое (shared) потоками, должно быть как можно меньше.
2. Доступ к разделённым данным должен производиться через как можно меньшее количество входных точек.
3. Работа с разделёнными данными должна быть либо блокирующей, либо неблокирующей.
3.1. Если работа блокирующая, надо проектировать в терминах последовательностей операций, не нарушающих заранее определённые инварианты.
3.2. Если работа не блокирующая, надо чётко определять гарантии работы кода в плане доступа к протухшим данным.
В Эйфеле проблемы возникают с пунктом 3: описанные инварианты (собственно инварианты, постусловия, предусловия) обеспечивают корректность только для неразделённых данных.
1. Состояние, разделённое (shared) потоками, должно быть как можно меньше.
2. Доступ к разделённым данным должен производиться через как можно меньшее количество входных точек.
3. Работа с разделёнными данными должна быть либо блокирующей, либо неблокирующей.
3.1. Если работа блокирующая, надо проектировать в терминах последовательностей операций, не нарушающих заранее определённые инварианты.
3.2. Если работа не блокирующая, надо чётко определять гарантии работы кода в плане доступа к протухшим данным.
В Эйфеле проблемы возникают с пунктом 3: описанные инварианты (собственно инварианты, постусловия, предусловия) обеспечивают корректность только для неразделённых данных.
> инварианты (собственно инварианты, постусловия, предусловия) обеспечивают корректность только для неразделённых данных.
CAS знаете?
CAS знаете?
Ну и пусть говорят. Еще можно настаивать на отдельности бит в машинном слове.
CQRS, на самом деле, всего лишь частный случай требования правильно именовать методы и не вводить неочевидных побочных эффектов.
CAS же по способу употребления — однозначно mutator. CAS без цикла еще заслуживает приставки «try-», но CAS внутри своего обычного цикла — mutator в чистом виде, команда с гарантированным эффектом.
CQRS, на самом деле, всего лишь частный случай требования правильно именовать методы и не вводить неочевидных побочных эффектов.
CAS же по способу употребления — однозначно mutator. CAS без цикла еще заслуживает приставки «try-», но CAS внутри своего обычного цикла — mutator в чистом виде, команда с гарантированным эффектом.
Я прочел в оригинале. И всем советую.
Майер поэтичен и кэролловски элегантен. Его должен переводить, как минимум, Заходер. А Заходер умер.
Майер поэтичен и кэролловски элегантен. Его должен переводить, как минимум, Заходер. А Заходер умер.
Слушал его лично, будучи студентом.
Может быть сейчас было бы иначе, но тогда – не впечатлил совершенно.
Может быть сейчас было бы иначе, но тогда – не впечатлил совершенно.
Что-то на Amazon не очень много фанатов, я бы не определил что это must have, скорее на любителя (классика же)
Кстати позволю себе заметить, книга переведена на русский язык коллективом преподавателей факультета ПМиК Тверского Государственного Университета.
Плюсую за это
жаль тех кто не понимает этого.
Во-первых, запоминание всех этих принципов и паттернов слишком утомительно, во-вторых, значительно проще получить определенные базовые знания, из которых вытекает многое другое, нежели тренировать память и из года в год стараться запомнить всякие новомодные словечки.
жаль тех кто не понимает этого.
Эй, а как же Банда Четырёх? Тут на амазоне она намного популярнее.
Конечно популярнее, ведь это приятно когда тебе дают готовый алгоритм, который ты можешь использовать без понимания. То, что описано в статье дает фундаментальные знания, как я понял. А это гораздо важнее всех паттернов, т.к. паттерн это всего лишь формализация идеи, которую многие слепо используют. А потом начинается спор о том кто круче может паттерн «мост» релизовать, и кто правильнее его понимает. Забывая то, что никакого эталона не существует и любые формализации паттернов есть лишь воплощение идей конкретных авторов и ваше видение может отличаться. Это как с кодом: можно копирастить с SO, а можно самому придумывать алгоритмы.
Основная сложность при изучении объектно-ориентированного программирования (или любой другой парадигмы программирования) заключается в том, что весьма сложно подобрать формальные критерии, которые бы сказали: «ок, теперь я знаю ООП и стану писать более клевые (читай модульные, реюзабельные и легкие в сопровождении) программы».
Та же проблема в астрологии. Такая же астральная штука, в которой никто не понимает зачем она нужна и как именно помогает писать клёвые программы, но считает что просто ещё не достиг просветления
Единственная польза — структуризация программы. Но того же эффекта можно достичь просто грамотно разделяя продцедуры на модули в процедурном программировании. Да хотя бы просто логически сгрупировать процедуры в исходнике — абсолютно тот же эффект без оверхэда на булшит.
Ну и наследование. Хотя никто не может объяснить какая от него польза в реальном продакшене. Ну да, можно определить базовый класс и от него наследовать. Единственная польза от этого это то, что можно определить базовый класс и от него наследовать. Это не какой-то универсальный метод и ничем обычно реально не помогает. Просто какой-то абсурдный частный случай.
p.s. Да, я в курсе что я ещё не просветлел, у меня мало опыта и вообще низкий уровень интеллекта. И, разумеется, зря противоречу постулатам, которые намертво выжжены в подкорке опытных С++ и джава программистов.
Та же проблема в астрологии. Такая же астральная штука, в которой никто не понимает зачем она нужна и как именно помогает писать клёвые программы, но считает что просто ещё не достиг просветления
Единственная польза — структуризация программы. Но того же эффекта можно достичь просто грамотно разделяя продцедуры на модули в процедурном программировании. Да хотя бы просто логически сгрупировать процедуры в исходнике — абсолютно тот же эффект без оверхэда на булшит.
Ну и наследование. Хотя никто не может объяснить какая от него польза в реальном продакшене. Ну да, можно определить базовый класс и от него наследовать. Единственная польза от этого это то, что можно определить базовый класс и от него наследовать. Это не какой-то универсальный метод и ничем обычно реально не помогает. Просто какой-то абсурдный частный случай.
p.s. Да, я в курсе что я ещё не просветлел, у меня мало опыта и вообще низкий уровень интеллекта. И, разумеется, зря противоречу постулатам, которые намертво выжжены в подкорке опытных С++ и джава программистов.
похоже тэги в комментах не работают, первый абзац делал курсивом
s/намертво/необратимо/
s/намертво/необратимо/
Единственная польза от этого это то, что можно определить базовый класс и от него наследовать.
Есть два момента: наследование интерфейса и наследование реализации.
Польза у них разная.
Если реализацию можно использовать, использую обычную агрегацию, то подстановку объектов разных классов по одному интерфейсу в большинстве языков со строгой типизацией без наследования не сделаешь.
цитата:
Если реализацию можно использовать, использую обычную агрегацию, то подстановку объектов разных классов по одному интерфейсу в большинстве языков со строгой типизацией без наследования не сделаешь.
Согласен, если никак по-другому не сделаешь, приходится наследовать. Но тут от наследование скорее не польза, а неизбежный костыль. В некоторых языках со статической типизацией эта проблема решена без наследования.
Если реализацию можно использовать, использую обычную агрегацию, то подстановку объектов разных классов по одному интерфейсу в большинстве языков со строгой типизацией без наследования не сделаешь.
Согласен, если никак по-другому не сделаешь, приходится наследовать. Но тут от наследование скорее не польза, а неизбежный костыль. В некоторых языках со статической типизацией эта проблема решена без наследования.
В вашем комментарии словосочетание «объектно-ориентированное программирование» можно заменить на любую другую изучаемую технику (будь то какой-либо язык программирования, или умение готовить суп). Кто бы спорил, что ООП — не панацея, и, конечно, все прелести ООП можно достигнуть другими средствами.
ООП — только инструмент. Процедурное программирование — тоже инструмент. Они разные, выбирай какой больше нравится, какой лаконичнее решает поставленную задачу и используй. Не поняв наследование — вы не сможете грамотно использовать объектные языки программирования, но это совсем не значит — что без наследования вообще программировать нельзя.
А то, что ООП так популярен — так это заслуга популярности языков программирования на нем. Здесь вообще все просто — больше популярности, дешевле использование. Становится JS популярнее — и прототипное программирование, вдруг, стало актуально как никогда.
ООП — только инструмент. Процедурное программирование — тоже инструмент. Они разные, выбирай какой больше нравится, какой лаконичнее решает поставленную задачу и используй. Не поняв наследование — вы не сможете грамотно использовать объектные языки программирования, но это совсем не значит — что без наследования вообще программировать нельзя.
А то, что ООП так популярен — так это заслуга популярности языков программирования на нем. Здесь вообще все просто — больше популярности, дешевле использование. Становится JS популярнее — и прототипное программирование, вдруг, стало актуально как никогда.
Цитата:
В вашем комментарии словосочетание «объектно-ориентированное программирование» можно заменить на любую другую изучаемую технику
В том то и дело что не любую другую. Многие другие технологии имеют рациональный инженерный и научный подход. И решают какие-либо проблемы. ООП не решает никакие проблемы, только создаёт. Это сугубо гуманитарная штука, как отмечено в комментарии ниже.
В вашем комментарии словосочетание «объектно-ориентированное программирование» можно заменить на любую другую изучаемую технику
В том то и дело что не любую другую. Многие другие технологии имеют рациональный инженерный и научный подход. И решают какие-либо проблемы. ООП не решает никакие проблемы, только создаёт. Это сугубо гуманитарная штука, как отмечено в комментарии ниже.
Я рекомендую полистать эту книгу; вот что что, а назвать формальное изложение Мейером ООП гуманитарным подходом язык никак не поворачивается.
«Не решает никаких проблем» о технолгии, являющейся мэйнстримом как-то слишком громко сказано. Вроде как, основная задача ООП — это уменьшение сложности кода, а инкапсуляция, наследование, полиморфизм и т. п. лишь выбранные для этого инструменты. Может не идеальные, но основную задачу они решают.
В таких статьях не хватает magnet-ссылок.
>Основная сложность при изучении объектно-ориентированного программирования (или любой другой парадигмы программирования) заключается в том, что…
Сложность заключается в том, что ООП-идеология подсовывает плохо формализуемые, составные понятия, как базовые и атомарные. Это гуманитарный подход. Можно писать 1200-страничные трактаты про то, от кого наследовать утконоса, но это не приблизит понимание сути вопроса.
По факту же в тех же явах и C#-ах мы имеем диспетчерезацию по первому параметру, какую-никакую статическую типизацию, и кучу спорных синтаксических штук вроде необходимости размазывать мультиметоды по коду. И кучу заученных приемов обхода всех этих синтаксических выкрутасов, которые называются «ООП-паттернами».
Сложность заключается в том, что ООП-идеология подсовывает плохо формализуемые, составные понятия, как базовые и атомарные. Это гуманитарный подход. Можно писать 1200-страничные трактаты про то, от кого наследовать утконоса, но это не приблизит понимание сути вопроса.
По факту же в тех же явах и C#-ах мы имеем диспетчерезацию по первому параметру, какую-никакую статическую типизацию, и кучу спорных синтаксических штук вроде необходимости размазывать мультиметоды по коду. И кучу заученных приемов обхода всех этих синтаксических выкрутасов, которые называются «ООП-паттернами».
Да, большинство изложений методологий разработки тяжело назвать формальным, но у Мейера очень формальный подход. Так что рекоменую хотя бы ознакомиться с этой книгой. Мейер показывает, что ООП методология может быть весьма формальной.
Так вот почему я нифига не могу разобраться в этом ООП…
мне кажется вся суть не в красоте и правильности кода с точки зрения какой-то концепции…
Одно из основных преимуществ ООП — повторное использование кода, которое не составляет особого труда. Зная и используя этот гуманитарный подход получается достаточно легко писать функциональные библиотеки, которые с легкостью можно использовать где угодно. А ООП тут при том что мы оперируем объектами, что является достаточно природным для нашего мировозрения
Одно из основных преимуществ ООП — повторное использование кода, которое не составляет особого труда. Зная и используя этот гуманитарный подход получается достаточно легко писать функциональные библиотеки, которые с легкостью можно использовать где угодно. А ООП тут при том что мы оперируем объектами, что является достаточно природным для нашего мировозрения
Повторное использование никак, никак не связано с ООП.
Ровно на столько же пригодный для повторного использования код получается в процедурном программировании.
Цитата:
А ООП тут при том что мы оперируем объектами, что является достаточно природным для нашего мировозрения.
Согласен, в каждом руководстве по ООП или С++ написана эта глупость.
Ровно на столько же пригодный для повторного использования код получается в процедурном программировании.
Цитата:
А ООП тут при том что мы оперируем объектами, что является достаточно природным для нашего мировозрения.
Согласен, в каждом руководстве по ООП или С++ написана эта глупость.
ну как это не связано… разве не добавляет удобства повторно использовать код ОО-принцип? Разве не природно отнаследоваться от какого-то функционального класса, переопределить нужные методы, добавить что то свое и получить новый класс, часть поведения которого унаследовано (повторно используется) от написанного ранее класса?
Цитата:
Согласен, в каждом руководстве по ООП или С++ написана эта глупость.
Обоснуйте почему это глупость? Разве не легче создавать сущности из таблиц бд (может не самый лучший пример, но все же) и потом оперировать ими как реальными объектами, строить взаимодействия и т.п. чем писать какой то процедурный код, где все будет не так природно?
Цитата:
Согласен, в каждом руководстве по ООП или С++ написана эта глупость.
Обоснуйте почему это глупость? Разве не легче создавать сущности из таблиц бд (может не самый лучший пример, но все же) и потом оперировать ими как реальными объектами, строить взаимодействия и т.п. чем писать какой то процедурный код, где все будет не так природно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бертран Мейер. Объектно-ориентированное конструирование программных систем