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