Самосознание. - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Возьмем простой и типичный пример - нужно передать данные из одного объекта в другой, причем эти данные и сама передача между объектами может меняться по ходу разработки кода - то как тогда будете с этим спровляться и пересылать данные через оболочки, которые же сами себе нагородили?
Только вот не надо говорить, что данные передавать из одного места программы в другое не требуется, это смешно. ))
Именно это и буду говорить.
Если данные надо передавать (скажем, объекту-Торгового Процессора надо получать приказы от объекта - Анализатора), то изначально должен существовать механизм этой передачи. Еще на стадии проектирования определяем интерфейс передачи этих данных. После этого Анализатор, когда надо запрашивает этот интерфейс у Приложения, получает его, и передает данные. Торговый Процессор получает эти данные, и выполняет полученные приказы.
Теперь смотри - ты решаешь, что у нас будет кнопка, разрешающая или запрещающая торговые приказы. В процедурном подходе - ты прямо из Торгового Процессора запрашиваешь эту самую кнопку, и либо останавливаешься, либо продолжаешь обрабатывать приказы. А вот в ООП подходе - этого не выйдет. Твой интерфейс не предусматривает получение информации о кнопке Торговым Процессором.
Это и есть тот самый случай, когда "передавать данные не требуется". Торговый Процессор должен выполнять приказы, получаемые через свой интерфейс, и он не должен лезть во всякие кнопки.
В ООП-подходе доступ к кнопкам будет иметь Анализатор. Вот он и будет решать, отослать ли в Торговый процессор приказы (полядев на эту кнопку) или нет.
Таким образом, определив интерфейс Торгового Процессора - ты сразу обрезал возможности из него влезать в кнопки, в другие органы управления, в цены, индикаторы, и в любые прочие подобные вещи. Что это тебе дает ? Это тебе позволяет быть уверенным, что вся логика работы эксперта не будет "размазана" по программе, а будет сконцентрированна в Аналазаторе. А вся техническая часть отправки ордеров на сервер - будет сконцентрирована в Торговом Процессоре, а нигде в другом месте. Ты всегда будешь уверен, что если была проведена торговая операция - то она была проведена Процессором по приказу, полученному через интерфейс. И в случае ошибок - отлавливать их надо именно в этом месте, не опасаясь, что приказ мог быть получен какими-то другими путями.
Да, бывают случаи, когда неожиданно выясняется, что через интерфейс требуется передать информацию, на которую раньше не расчитывали. Это - серьезная ошибка проектирования, надо всеми силами избегать подобных ситуаций. А когда они, все же, происходят - приходится тратить много усилий на переработку системы. Но, тем не менее, это исключение.
Не, тут действительно существенно разный подход.
...
Инкапсуляция - это как раз очень важный момент ООП. Дальше осталось добавить только виртуализацию - когда ты имеешь доступ не к реальным кодам классов, а к "оболочке", к чисто виртуальному интерфейсу, где все функции "нулевые", что не позволяет тебе влезать туда, для чего данный интерфейс не предназначен. В тоже время та же виртуализация позволяет при написании реализации этого интерфейса - не думать о том, как и что будет делать пользователь. Имеется виртуальный интерфейс, все его функции ты должен реализовать в соответствии с объявлениями. А кто там будет что и зачем использовать - тебе неважно.
Всех этих плюсов нет при "процедурном" подходе и в ситуации "я имею доступ ко всем частям программы из любой точки".
Да, подходы очень разные. Разная расстановка приоритетов в программировании.
Мое видиние ООП:
Упорядочивание кода начинается с создания прото-структуры программы через разбитие будущего функционала на классы. Все намечается наперед. Заранее. Строиться "дерево" из классов, в котором есть базовый класс("ствол") и дочерние классы ("ответвления").
Далее, пишется функционал. Прототип каждой функции указывается в классе. Создаются "объекты" (по сути ссылки), являющиеся смысловыми "смычками". К ним присоединяются переменные. Получаются человеческие словосочетания, упрощающие понимание кода.
До этого момента все хорошо. Но потом, начинается обратный процесс. От читабельности и порядка к царству нечитабельного кода. К загромождению сущностями и правилами, которыми беспрерывно "накачивается" современное программирование.
Вместо упрощения связи человека с компьютером, получается коллосальное усложнение, которое на практике не ускоряет процесс разработки, а тормозит его. Из за большого количества сущностей появляются новые правила. Ведь каждая сущность требует правил. А новые правила устанавливают новые сущности. Это замкнутый круг.
В итоге, бесконтрольное увеличение концептуальной базы ООП ведет к потере КПД от человеческого труда. Разобраться в коде становится все сложнее, и потому программу нужно все больше дробить на части. Разграничивать доступ, чтобы отдельные части можно было забыть. Однако, необходимость забыть и не смотреть куда то, появляется от чрезмерной "синтаксичности" кода и разбитости. Разбросанности. Из за загроможденности препятствиями и барьерами. Опять замкнутый круг.
Нужно понимать, что углубление в классификацию - ведет к увеличению функций и переменных. Следовательно, увеличивает количество объектов (связок-ссылок). Следовательно, увеличивает необходимость разделения доступа. И следовательно, - увеличивает время на освоение и запоминание программы.
В итоге - получается низкий КПД программиста и увеличение оверхеда программы.
ЗЫ. Использование концептуальной базы ООП нужно контроллировать. Не стоит помещать в программу все, что в ней есть. Там много лишнего.
ЗЫ. Использование концептуальной базы ООП нужно контроллировать. Не стоит помещать в программу все, что в ней есть. Там много лишнего.
Да, конечно. Для написания простейшего индикатора - нет смысла писать структуру классов дата-провайдера, менеджера экрана, виртуальные интерфейсы логики индикатора, и так далее... Преимущество принципов ООП раскрывается в работе с большими и комплексными задачами.
Проходят месяцы, годы... Человек взрослеет, и взгляд на мир меняется. Меняется и взгляд на себя.
Читая свои посты на этом форуме, я обнаруживаю, что хотел бы ответить сам себе. Возразить, или даже осадить себя за чрезмерную уверенность, высокомерие, резкость. Подметить неверное отношение к сути, лишнюю эмоциональность, многословие... Есть много вещей, которые хочется исправить.
Если ваши взгляды изменились, предлагаю в этой ветке приводить свои ранние посты и отвечать на них самим, так, как вы ответили бы постороннему человеку.
(В этой ветке, каждый может вести диалог только с самим собой. Для этого она предназначена.)
Бесплатный совет могу дать. Направьте интеллектуальную деятельность в конкретное русло - на зарабатывание бабла.
Georgiy Merts:
Да, бывают случаи, когда неожиданно выясняется, что через интерфейс требуется передать информацию, на которую раньше не расчитывали. Это - серьезная ошибка проектирования, надо всеми силами избегать подобных ситуаций. А когда они, все же, происходят - приходится тратить много усилий на переработку системы. Но, тем не менее, это исключение.
Всё очень неубедительно. В сложных программах никогда заранее нельзя сказать как будет выглядеть конечный код поэтому спроектировать конечный вид программы невозможно и тем более избежать проверок различных конфигураций.
Это уже не говоря про добавку слоя интерфейса который вносит свои баги и затрудняет отладку кода.
Да, конечно. Для написания простейшего индикатора - нет смысла писать структуру классов дата-провайдера, менеджера экрана, виртуальные интерфейсы логики индикатора, и так далее... Преимущество принципов ООП раскрывается в работе с большими и комплексными задачами.
Нюансы о которых говорил Реter Konow существуют и мы их на верняка замечаем в ошибках которые постоянно вылезая от одной билд МТ4 или МТ5 к другому напоминают. Могут перескакивать через несколько-несколько билдов и опять встречаться или повторятся.
Ничего идеального в ООП тоже нет.
Да, конечно. Для написания простейшего индикатора - нет смысла писать структуру классов дата-провайдера, менеджера экрана, виртуальные интерфейсы логики индикатора, и так далее... Преимущество принципов ООП раскрывается в работе с большими и комплексными задачами.
Классы - это еще не ООП. Концепция ООП гораздо шире. А классы - это так, ни о чем.
Петр, а в чем смыл этой ветки? Появились новые аргументы против ООП?
Это смешно, это как защищать дровяные печи в эпоху электричества.
ООП - это революционный прорыв в области программирования, совершенный, кажется, еще в середине прошлого века (или в конце, но ближе к середине). Всемирно и всецело принятый и признанный.
Если кто-то этого не понимает, он просто болван.
Это почти тоже самое, что и против многопоточности выступать за однопоточность.
За NC против Виндос. Между прочим, в свое время, реально случались истерики при установке Виндос, типа оставьте нам NC.
Всё очень неубедительно. В сложных программах никогда заранее нельзя сказать как будет выглядеть конечный код поэтому спроектировать конечный вид программы невозможно и тем более избежать проверок различных конфигураций.
Это уже не говоря про добавку слоя интерфейса который вносит свои баги и затрудняет отладку кода.
Это окончательный вид нельзя спроектировать. А вот базовые интерфейсы - очень даже нормально проектируются.
Выше я показал базовый интерфейс "компоненты торговой позиции". Реально, реализация этого интерфейса - это либо ордер МТ4 либо позиция МТ5. Плюс я не исключаю переходна С++ или С# в WLD - и, думаю, что этот интерфейс вполне сгодится и для торговой позиции на этой платформе.
Далее - базовые интерфейсы торгового процессора, базовые интерфейсы индикатора, базовые интерфейсы частей эксперта, дата провайдера - все они вполне нормально были спроектированы изначально.
Сейчас - я занимаюсь чисто реализацией этих интерфейсов там, где надо. Причем, виртуальные интерфейсы хороши тем, что можно реализовывать далеко не все сразу. Скажем, мой дата-провайдер сейчас поставляет далеко не все индикаторы, а только лишь те, что мне необходимы. Но, запросить можно любой индикатор, и написать код, который будет с ним работать - как раз через виртуальный интерфейс индикатора. Но, в момент окончательной компиляции - компилятор тут же предупредит, что вызванный индикатор не имеет реализации, ее требуется написать, я и напишу ее. При этом весь код, который будет использовать этот индикатор - будет написан.
Ничего идеального в ООП тоже нет.
Да ООП - это просто технология, которая сильно упрощает сопровождение и модификацию кода. Но при этом требует дополнительные ресурсы при написании. Об "идеальности" никто не говорит. Я уже не раз писал - если всю структуру и особенности кода удается держать в памяти - то смысла в ООП нет.