Что может делать ООП-код, чего не может процедурный код? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В небольших проектах вы можете показать, что любую проблему можно разложить на процедурный код. Однако все становится намного сложнее, когда у вас есть многомиллионные базы кода с командами из 100+ разработчиков, нескольких бизнес-аналитиков и архитекторов, желающих одновременно вносить изменения в "модель". В таких условиях "бизнес" модель обычно определяется в инструменте проектирования, таком как UML, и доступна для всей команды.
Одна только бизнес-модель содержит 5000+ классов. На основе этой бизнес-модели существуют инструменты, которые "генерируют" классы для объектной модели, интерфейсов SQL и сетевых уровней, в результате чего базовое количество классов достигает 15 000.
Для этого обсуждения я хотел бы разбить спор между процедурным и ООП на три "расширения", которые были добавлены к процедурному с 1960/1970-х годов
1) "Основанная на объектах" - это когда объекты и код инкапсулируются для создания продвинутых "структур", которые также могут иметь поведение.
2) "Основанные на классах" - это когда объекты могут наследоваться друг от друга и располагаться в иерархии.
3) "Объектно-ориентированная" - это когда пользователь может определить "полиморфное" поведение (виртуальные методы или интерфейсы) в иерархии классов.
Существует аргумент, что все вышеперечисленное может быть реализовано в процедурных языках при достаточных усилиях, например, большинство наборов инструментов GUI в 80/90-х годах были созданы на c и имели эти возможности, но их нелегко реализовать случайному кодеру, и они не совсем применимы к данному обсуждению.
Итак, отвечая на вопрос, можем ли мы реализовать многомиллионный проект со 100+ разработчиками без использования 3 функций ООП?
Мое личное мнение - практически невозможно реализовать крупномасштабный проект без 1) и 2), потому что без системы, основанной на классах, очень трудно отобразить структуры данных и поведение реального мира в код чистым и лаконичным образом. И более того, по мере увеличения размера проекта то, что начинается как "мы можем реализовать это на c", превращается в бесконечный список методов с меньшей структурой, которые становится сложнее поддерживать.
Теперь языки, которые обеспечивают только 1) и 2), не являются полностью ООП языками. Поэтому мы должны подумать, действительно ли необходимы "полиморфные (виртуальные) методы". Это скорее "может быть" или "иногда", потому что полиморфизм не всегда является правильным инструментом для решения проблемы и может переусложнить дизайн. Например, при моделировании некоторых структур данных, которые отображаются на хранилище объектов или базу данных SQL, добавление виртуальных моделей поведения может усложнить отображение данных, однако при определении расширяемых наборов инструментов или API использование "интерфейса" или базового класса с "виртуальными методами" неоценимо. В целом я большой поклонник полиморфизма, если он используется редко и в правильном контексте.
Я работал над несколькими многомиллионными кодовыми базами на Си и еще несколькими многомиллионными кодовыми базами на C++/Java/C#, и большинство кодовых баз на Си сходят на "режим обслуживания" через 5 лет, потому что разработчики боятся менять архитектуру, так как код слишком хрупок, а модификации часто приводят к месяцам болезненной перестройки и тестирования. В целом, объектно-ориентированные проекты гораздо более устойчивы к изменениям и рефакторингу.
Оператор "if...then...else..." должен сделать свою работу.
if...then...else не способен кодировать "виртуальные" методы.
Существует несколько реализаций "полиморфизма" в "C", и большинство из них используют векторы указателей функций для хранения необходимых отображений. Более того, эти "векторы указателей функций" должны быть определены для каждого "типа", который вы хотите смоделировать в "иерархии". Конечно, "C" не поддерживает иерархии напрямую, поэтому вам придется решить и эту проблему.
Если вы действительно хотите залезть в мешок с червями, которым являются "виртуальные" методы, реализованные в "Си", то вы можете откопать инструментарий X Windows, который свободно доступен в каждом дистрибутиве Linux.
Windows, конечно, должна быть немного другой, и она использует расширяемые структуры с целочисленными идентификаторами сообщений. Это означает, что "полиморфное" поведение реализуется через операторы переключения идентификаторов. (вероятно, это самый грязный способ, но он поможет вам достичь цели)
Согласны ли вы с тем, что операционная система Windows предлагает хороший графический интерфейс? Насколько я знаю, она написана на C. Процедурный язык, а не ООП.
Вы ошибаетесь, Дирк, если думаете, что сложная программа может быть построена только с помощью ООП. Вам лучше объяснить, почему лучше написать ее на ООП.
Ядро Windows написано на "C", но ядро - лишь небольшой компонент кодовой базы Windows, а большая часть кодовой базы более высокого уровня реализована на C++ с внешними интерфейсами в стиле "C" для поддержки нескольких языков.
Даже устаревшие компоненты графического интерфейса Windows реализуют свои собственные "полиморфные поведения", которые по сути являются "ООП", реализованным на "С". Например, когда вы получаете "Handle" обратно от элемента управления GUI, вы получаете расширяемую структуру "C" с полиморфным поведением, это ООП, просто обернутое в уродливый набор синтаксиса "C".
Говорить, что Windows не ООП, потому что она написана на "С", не совсем точно.
Я не буду создавать GUI на процедурном языке, чтобы доказать, что вы не правы. Но я мог бы, без сомнения.
Кстати, в ООП также легко написать нечитаемый и гораздо более медленный код, и, как вы знаете, стандартная библиотека Metaquotes является хорошим доказательством этого.
То, что ООП намного медленнее процедурного кода - это полный миф. Причина, по которой многие ООП-проекты работают медленнее, заключается в том, что они плохо спроектированы. Накладные расходы на вызов виртуальной функции намного меньше, чем вы ожидаете, особенно с современными архитектурами выборки памяти на чипе, которые могут искать и выполнять параллельно.
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
Цитата из приведенной выше ссылки: "Но стоимость вызова, независимо от его вида, определяется оценкой его аргументов. Мы видели, что косвенные вызовы, будь то виртуальные методы в стиле C или C++, по своей сути недороги. Вызов виртуального метода не дороже, чем косвенный вызов с использованием члена структуры (something->function(arg1,arg2)), поэтому считать виртуальную функцию невероятно медленной - просто дезинформация."
Java может быть намного медленнее, чем C++, потому что каждая часть инкапсулированных данных должна сама быть классом, основанным на куче, поэтому вы получаете намного больше разыменований объектов. Однако даже в циклах и основных математических операциях Java может работать с той же скоростью, что и C.
Если сравнивать C и C#, то действительно очень трудно написать код, который был бы значительно быстрее в C по сравнению с C#, даже если включить некоторые возможности ООП.
Если стандартная библиотека Metaquotes медленная, то это на 90% связано с дизайном библиотечных функций и имеет очень мало общего с используемыми функциями ООП.
(Для сравнения, стандартная библиотека шаблонов C++ превосходит 95% всех когда-либо написанных проектов на Си).
...
Спасибо за ваш большой вклад.
Спасибо за ваш большой вклад.
Спасибо, и я на вас не обижался, просто вы единственный, кто отстаивает процедурный аргумент :)
Не беспокойтесь, я должен играть роль "модератора".
Конечно, было бы неплохо увидеть примеры того, о чем вы говорите. Говорить/печатать - это все хорошо для людей, которые имеют опыт во всем этом, но я - визуальный студент, который работает руками, пожалуйста, опубликуйте примеры.
Я нахожусь в раздумьях, продолжать ли мне изучать mql4, переходить на mql5 или просто выбрать другую платформу.
Спасибо Алене за создание этой темы. Этот форум действительно нуждается в этом.
Вы действительно ожидаете, что кто-то профессиональный выложит библиотеку compex, просто так, в качестве "доказательства"? ;) Я мог бы дать вам ссылку на что-то готовое, что не может быть продано на рынке здесь, но Ален даст мне пинка, если я это сделаю ;) Вы можете посетить мой профиль и взглянуть на картинку на стене, чтобы получить представление или написать мне в почту.
Другая платформа? Вы не найдете другой платформы с таким мощным компилятором. Вовсе нет.
@James Cater - спасибо большое за ваши комментарии.
Вы действительно ожидаете, что кто-то профессиональный выложит библиотеку compex, просто так, в качестве "доказательства"? ;) Я мог бы дать вам ссылку на что-то готовое, что не может быть продано на рынке здесь, но Ален даст мне пинка, если я это сделаю ;) Вы можете посетить мой профиль и взглянуть на картинку на стене, чтобы получить представление, или написать мне в почту.
Другая платформа? Вы не найдете другой платформы с таким мощным компилятором. Вовсе нет.
@James Cater - спасибо большое за ваши комментарии.