ООП vs процедурное программирование - страница 26
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да тут нечего особо думать.
ООП - это механизм, позволяющий переложить на компилятор немалую часть проверок и согласований. Однако, для его использования надо затратить дополнительные усилия.
Но если все эти проверки и согласования нам не нужны - смысла в ООП - никакого.
Скажем, я бы поопасался работать с многомерным массивом графического ядра - потому, что в нем слишком много лишних сущностей, не нужных в данный момент. Они отвлекают, и провоцируют на трудно вычисляемые ошибки. Я бы заменил его набором объектов, к которым бы обращался по простым компактным интерфейсам. Получив интерфейс - мне не надо ничего помнить - сам интерфейс ограничивает меня, и не дает мне, скажем, обратиться не к тому полю или объекту. В случае с массивом графического ядра - такое обращение очень даже возможно.
То есть, в случае, когда блок получает интерфейс - сам компилятор "обрезает" все лишние сущности, и не дает пользователю ошибаться. С массивом же графического ядра - пользователь имеет кучу лишней информации, в которой запросто можно допустить ошибку.
Я по своему опыту знаю, что мне гораздо лучше, когда за меня сам компилятор будет следить, чтобы я не влезал туда, куда из текущего блока мне влезать не следует. А с массивом графического ядра - я должен это помнить. Минус моей системы - это продолжение плюса. Если в блоке внезапно потребуется что-то, что выходит за рамки текущей задачи - то с массивом графического ядра все просто - берем нужные данные, и с ними работаем. А вот с ООП-интерфейсами - придется либо запрашивать необходимые данные в дополнительном интерфейсе, либо (что гораздо неприятнее) модифицировать имеющийся интерфейс.
Да тут нечего особо думать.
ООП - это механизм, позволяющий переложить на компилятор немалую часть проверок и согласований. Однако, для его использования надо затратить дополнительные усилия.
Но если все эти проверки и согласования нам не нужны - смысла в ООП - никакого.
Ну зачем же так упрощать. А наглядность и читаемость? А упрощение выявления и исправления ошибок? А переносимость? А упрощение модернизации? и т.д. и т.п. ....
Ну тогда тема должна звучать по другому. Что-то вроде: "Новый инструментарий в программировании" или "Новая парадигма программирования"...
Если это правда, что ты создал что-то круче ООП, тогда автограф дашь свой, когда станешь знаменитым?
Без проблем! Автографа для друзей не жалко.))))
Ты вот шутишь, но в моем воображение такие переспективы рисуются с этим подходом, что "мама не горюй". Кажется, что со временем я смогу запустить механизм самосовершенствования системы. Если сделать логическое ядро и заставить его в случайном порядке генерировать различные механизмы. Потом только проводить селекцию и отбирать нужные. Дальше шлифовать их немного... благодаря ядру можно невероятные вещи сделать.
Ну зачем же так упрощать. А наглядность и читаемость? А упрощение выявления и исправления ошибок? А переносимость? А упрощение модернизации? и т.д. и т.п. ....
знатный рекламный баннер :-) "покупайте наших слонов"
все приведённые тезисы одинаково относимы и к ООП и не к ООП и к ФП и вообще куда угодно
Да тут нечего особо думать.
ООП - это механизм, позволяющий переложить на компилятор немалую часть проверок и согласований. Однако, для его использования надо затратить дополнительные усилия.
Но если все эти проверки и согласования нам не нужны - смысла в ООП - никакого.
Скажем, я бы поопасался работать с многомерным массивом графического ядра - потому, что в нем слишком много лишних сущностей, не нужных в данный момент. Они отвлекают, и провоцируют на трудно вычисляемые ошибки. Я бы заменил его набором объектов, к которым бы обращался по простым компактным интерфейсам. Получив интерфейс - мне не надо ничего помнить - сам интерфейс ограничивает меня, и не дает мне, скажем, обратиться не к тому полю или объекту. В случае с массивом графического ядра - такое обращение очень даже возможно.
То есть, в случае, когда блок получает интерфейс - сам компилятор "обрезает" все лишние сущности, и не дает пользователю ошибаться. С массивом же графического ядра - пользователь имеет кучу лишней информации, в которой запросто можно допустить ошибку.
Я по своему опыту знаю, что мне гораздо лучше, когда за меня сам компилятор будет следить, чтобы я не влезал туда, куда из текущего блока мне влезать не следует. А с массивом графического ядра - я должен это помнить. Минус моей системы - это продолжение плюса. Если в блоке внезапно потребуется что-то, что выходит за рамки текущей задачи - то с массивом графического ядра все просто - берем нужные данные, и с ними работаем. А вот с ООП-интерфейсами - придется либо запрашивать необходимые данные в дополнительном интерфейсе, либо (что гораздо неприятнее) модифицировать имеющийся интерфейс.
Ты совершенно напрасно думаешь, что в ядре есть что то лишнее. И запоминать его сущности очень легко, так как через дефайны они облачаются в человеческие слова. Там собрано все, но это содержание имеет четкий и неизменный порядок. Свойства обьектов, окон, элементов находятся в прямой доступности в любой точке программы. А какие чудеса можно творить благодаря ядру в циклах...
Ты совершенно напрасно думаешь, что в ядре есть что то лишнее. И запоминать его сущности очень легко, так как через дефайны они облачаются в человеческие слова. Там собрано все, но это содержание имеет четкий и неизменный порядок. Свойства обьектов, окон, элементов находятся в прямой доступности в любой точке программы. А какие чудеса можно творить благодаря ядру в циклах...
Я не сказал, что "в ядре есть что-то лишнее", я сказал "ненужное в данный момент". Если я работаю с линией графика - у меня не должно быть возможности доступа к свойствам окон.
Как раз то, что все эти свойства находятся в прямой доступности в любой точке программы - и есть основной минус твоего подхода. В любом месте программы должен быть доступ исключительно только к тем элементам, которые необходимы именно в этом месте в этот момент. Все остальное - должно быть недоступно. Это - позволяет в автоматическом режиме избегать многих ошибок.
Все "чудеса, которые можно творить благодаря доступности всего ядра" - это, на мой взгляд, потенциальный источник трудно выявляемых ошибок и проблем с пониманием кода. Надо стараться избегать всех этих хитростей.
Мне подобный подход напоминает глупейшие задачки, когда в одну строку записывают указатели, инкременты, ссылки в дикой перемешке, что, возмоожно, с точки зрения языка и корректно, но совершенно нечитабельно. Да я выше приводил свою собственную функцию, которая также выглядит совершенно безумно, просто я посчитал, компактность в данном случае важнее.
Ну зачем же так упрощать. А наглядность и читаемость? А упрощение выявления и исправления ошибок? А переносимость? А упрощение модернизации? и т.д. и т.п. ....
Фантастика!
1. До ооп мы все конструировали из БЕСполезных компонент, обладающих исключительно сложными инструментами
2. До ООП программы представляли исключительно хорошо перемешанный компот
3. До ООП мы НЕ слышали о локализации данных и кода и от этого жуть как мучились при сопровождении
4. Защита данных между разными частями одной программы - это просто пипец!
5. До ООП никто и никогда не расширял системы.
Просто полный аут.
Вот сижу и думаю, что может из меня и вырос этот самый ООП, потому я все это применял еще в конце 70-х и еще очень много чего, что относится к культуре программирования.
Я не сказал, что "в ядре есть что-то лишнее", я сказал "ненужное в данный момент". Если я работаю с линией графика - у меня не должно быть возможности доступа к свойствам окон.
Как раз то, что все эти свойства находятся в прямой доступности в любой точке программы - и есть основной минус твоего подхода. В любом месте программы должен быть доступ исключительно только к тем элементам, которые необходимы именно в этом месте в этот момент. Все остальное - должно быть недоступно. Это - позволяет в автоматическом режиме избегать многих ошибок.
Все "чудеса, которые можно творить благодаря доступности всего ядра" - это, на мой взгляд, потенциальный источник трудно выявляемых ошибок и проблем с пониманием кода. Надо стараться избегать всех этих хитростей.
Мне подобный подход напоминает глупейшие задачки, когда в одну строку записывают указатели, инкременты, ссылки в дикой перемешке, что, возмоожно, с точки зрения языка и корректно, но совершенно нечитабельно. Да я выше приводил свою собственную функцию, которая также выглядит совершенно безумно, просто я посчитал, компактность в данном случае важнее.
Ты рассуждаешь о ядре исходя из сиюминутных теоритических представлений, базирующихся на твоем опыте, который не имеет отношения к той технологии, о которой ты говоришь. Отсюда появляются какие то проблемы с доступом, запоминанием сущностей...
Я рассуждаю на основе практического опыта работы с этой технологией, и говорю - никаких подобных проблем с доступом или его ограничением нет. Честно говоря, вообще не понимаю о каких вопросах доступа ты говоришь. Нет и небыло никогда подобных сложностей.
Расскажи подробнее, какие проблемы с доступом ты имеешь ввиду.
С чего ты решил, что доступ должен ограничиватся, иначе это провоцирует ошибки? Для меня это что то новенькое.
Разве прямой доступ к глобальному массиву в процедурном коде может служить причиной трудно-выявляемых ошибок сам по себе?
Ты рассуждаешь о ядре исходя из сиюминутных теоритических представлений, базирующихся на твоем опыте, который не имеет отношения к той технологии, о которой ты говоришь. Отсюда появляются какие то проблемы с доступом, запоминанием сущностей...
Я рассуждаю на основе практического опыта работы с этой технологией, и говорю - никаких подобных проблем с доступом или его ограничением нет. Честно говоря, вообще не понимаю о каких вопросах доступа ты говоришь. Нет и небыло никогда подобных сложностей.
Да как же "нет проблем", если говоришь, что "из любого места все доступно" ?
Это же и есть главная проблема ! Не должно быть доступно !
Суть-то как раз в том, чтобы переложить задачу контроля доступа на компилятор. А у тебя - все открыто, и контроль доступа осуществляет программист.
Сложностей не было, потому, что ты все помнишь. Привык уже. Ничего, со временем ты обнаружишь, что память начинает подводить - тогда ты и оценишь возможности компилятора по контролю доступа. Я вот - не помню. И, подозреваю, что большинство тоже периодически забывает, как работает то, что написано месяцы назад. Именно в этих условиях разграничение доступа становится благом.
Скажем, если ты внутри блока, который отвечает за выставление ордеров - ты имеешь возможность только выставлять ордера. И не имеешь возможность рисовать график. Если ты находишься в блоке, который отвечает за рисование графика - ты оттуда никак не можешь выставить ордер. Это очень упрощает работу. А когда в функции отрисовки графика ты ВНЕЗАПНО видишь запрос на выставление ордера - тебе придется долго вспоминать, почему ты тут так поступил. Хорошо, если есть подробный комментарий, который объясняет, почему такое решение было принято... Но лучше - когда ордера выставляются в одном, специально для этого предназначенном блоке.
Да как же "нет проблем", если говоришь, что "из любого места все доступно" ?
Это же и есть главная проблема ! Не должно быть доступно !
Суть-то как раз в том, чтобы переложить задачу контроля доступа на компилятор. А у тебя - все открыто, и контроль доступа осуществляет программист.
Сложностей не было, потому, что ты все помнишь. Привык уже. Ничего, со временем ты обнаружишь, что память начинает подводить - тогда ты и оценишь возможности компилятора по контролю доступа. Я вот - не помню. И, подозреваю, что большинство тоже периодически забывает, как работает то, что написано месяцы назад. Именно в этих условиях разграничение доступа становится благом.
Скажем, если ты внутри блока, который отвечает за выставление ордеров - ты имеешь возможность только выставлять ордера. И не имеешь возможность рисовать график. Если ты находишься в блоке, который отвечает за рисование графика - ты оттуда никак не можешь выставить ордер. Это очень упрощает работу. А когда в функции отрисовки графика ты ВНЕЗАПНО видишь запрос на выставление ордера - тебе придется долго вспоминать, почему ты тут так поступил. Хорошо, если есть подробный комментарий, который объясняет, почему такое решение было принято... Но лучше - когда ордера выставляются в одном, специально для этого предназначенном блоке.