Самосознание. - страница 4

 
Andrei:

Возьмем простой и типичный пример - нужно передать данные из одного объекта в другой, причем эти данные и сама передача между объектами может меняться по ходу разработки кода - то как тогда будете с этим спровляться и пересылать данные через оболочки, которые же сами себе нагородили?

Только вот не надо говорить, что данные передавать из одного места программы в другое не требуется, это смешно. ))

Именно это и буду говорить.

Если данные надо передавать (скажем, объекту-Торгового Процессора надо получать приказы от объекта - Анализатора), то изначально должен существовать механизм этой передачи. Еще на стадии проектирования определяем интерфейс передачи этих данных. После этого Анализатор, когда надо запрашивает этот интерфейс у Приложения, получает его, и передает данные. Торговый Процессор получает эти данные, и выполняет полученные приказы.

Теперь смотри - ты решаешь, что у нас будет кнопка, разрешающая или запрещающая торговые приказы. В процедурном подходе - ты прямо из Торгового Процессора запрашиваешь эту самую кнопку, и либо останавливаешься, либо продолжаешь обрабатывать приказы. А вот в ООП подходе - этого не выйдет. Твой интерфейс не предусматривает получение информации о кнопке Торговым Процессором.

Это и есть тот самый случай, когда "передавать данные не требуется". Торговый Процессор должен выполнять приказы, получаемые через свой интерфейс, и он не должен лезть во всякие кнопки.

В ООП-подходе доступ к кнопкам будет иметь Анализатор. Вот он и будет решать, отослать ли в Торговый процессор приказы (полядев на эту кнопку) или нет.

Таким образом, определив интерфейс Торгового Процессора - ты сразу обрезал возможности из него влезать в кнопки, в другие органы управления, в цены, индикаторы, и в любые прочие подобные вещи. Что это тебе дает ? Это тебе позволяет быть уверенным, что вся логика работы эксперта не будет "размазана" по программе, а будет сконцентрированна в Аналазаторе. А вся техническая часть отправки ордеров на сервер - будет сконцентрирована в Торговом Процессоре, а нигде в другом месте. Ты всегда будешь уверен, что если была проведена торговая операция - то она была проведена Процессором по приказу, полученному через интерфейс. И в случае ошибок - отлавливать их надо именно в этом месте, не опасаясь, что приказ мог быть получен какими-то другими путями.

Да, бывают случаи, когда неожиданно выясняется, что через интерфейс требуется передать информацию, на которую раньше не расчитывали. Это - серьезная ошибка проектирования, надо всеми силами избегать подобных ситуаций. А когда они, все же, происходят - приходится тратить много усилий на переработку системы. Но, тем не менее, это исключение.


 

 
Georgiy Merts:

Не, тут действительно существенно разный подход.

...

Инкапсуляция - это как раз очень важный момент ООП. Дальше осталось добавить только виртуализацию - когда ты имеешь доступ не к реальным кодам классов, а к "оболочке", к чисто виртуальному интерфейсу, где все функции "нулевые", что не позволяет тебе влезать туда, для чего данный интерфейс не предназначен.  В тоже время та же виртуализация позволяет при написании реализации этого интерфейса - не думать о том, как и что будет делать пользователь. Имеется виртуальный интерфейс, все его функции ты должен реализовать в соответствии с объявлениями. А кто там будет что и зачем использовать - тебе неважно.

Всех этих плюсов нет при "процедурном" подходе и в ситуации "я имею доступ ко всем частям программы из любой точки".

Да, подходы очень разные. Разная расстановка приоритетов в программировании.

Мое видиние ООП:

Упорядочивание кода начинается с создания прото-структуры программы через разбитие будущего функционала на классы. Все намечается наперед. Заранее. Строиться "дерево" из классов, в котором есть базовый класс("ствол") и дочерние классы ("ответвления").

Далее, пишется функционал. Прототип каждой функции указывается в классе. Создаются "объекты" (по сути ссылки), являющиеся смысловыми "смычками". К ним присоединяются переменные. Получаются человеческие словосочетания, упрощающие понимание кода.

До этого момента все хорошо. Но потом, начинается обратный процесс. От читабельности и порядка к царству нечитабельного кода. К загромождению сущностями и правилами, которыми беспрерывно "накачивается" современное программирование. 

Вместо упрощения связи человека с компьютером, получается коллосальное усложнение, которое на практике не ускоряет процесс разработки, а тормозит его. Из за большого количества сущностей появляются новые правила. Ведь каждая сущность требует правил. А новые правила устанавливают новые сущности. Это замкнутый круг.

В итоге, бесконтрольное увеличение концептуальной базы ООП ведет к потере КПД от человеческого труда. Разобраться в коде становится все сложнее, и потому программу нужно все больше дробить на части. Разграничивать доступ, чтобы отдельные части можно было забыть. Однако, необходимость забыть и не смотреть куда то, появляется от чрезмерной "синтаксичности" кода и разбитости. Разбросанности. Из за загроможденности препятствиями и барьерами. Опять замкнутый круг.

Нужно понимать, что углубление в классификацию - ведет к увеличению функций и переменных. Следовательно, увеличивает количество объектов (связок-ссылок). Следовательно, увеличивает необходимость разделения доступа. И следовательно, - увеличивает время на освоение и запоминание программы.

В итоге - получается низкий КПД программиста и увеличение оверхеда программы. 

ЗЫ. Использование концептуальной базы ООП нужно контроллировать. Не стоит помещать в программу все, что в ней есть. Там много лишнего. 

 
Реter Konow:
 

ЗЫ. Использование концептуальной базы ООП нужно контроллировать. Не стоит помещать в программу все, что в ней есть. Там много лишнего.         

Да, конечно. Для написания простейшего индикатора - нет смысла писать структуру классов дата-провайдера, менеджера экрана, виртуальные интерфейсы логики индикатора, и так далее... Преимущество принципов ООП раскрывается в работе с большими и комплексными задачами.

 
Реter Konow:

Проходят месяцы, годы... Человек взрослеет, и взгляд на мир меняется. Меняется и взгляд на себя.  

Читая свои посты на этом форуме, я обнаруживаю, что хотел бы ответить сам себе. Возразить, или даже осадить себя за чрезмерную уверенность, высокомерие, резкость. Подметить неверное отношение к сути, лишнюю эмоциональность, многословие... Есть много вещей, которые хочется исправить.  

Если ваши взгляды изменились, предлагаю в этой ветке приводить свои ранние посты и отвечать на них самим, так, как вы ответили бы постороннему человеку.


(В этой ветке, каждый может вести диалог только с самим собой. Для этого она предназначена.)

Хорошо быть молодым. Мозги у них все время в тонусе, им какие-то отвлеченные от жизни идеи приходят. Их зачем-то обсуждают с такими же. Результат на выходе, как правило,  ноль.

Бесплатный совет могу дать. Направьте интеллектуальную деятельность в конкретное русло - на зарабатывание бабла.

 

Georgiy Merts:

Да, бывают случаи, когда неожиданно выясняется, что через интерфейс требуется передать информацию, на которую раньше не расчитывали. Это - серьезная ошибка проектирования, надо всеми силами избегать подобных ситуаций. А когда они, все же, происходят - приходится тратить много усилий на переработку системы. Но, тем не менее, это исключение.

Всё очень неубедительно. В сложных программах никогда заранее нельзя сказать как будет выглядеть конечный код поэтому спроектировать конечный вид программы невозможно и тем более избежать проверок различных конфигураций.

Это уже не говоря про добавку слоя интерфейса который вносит свои баги и затрудняет отладку кода.

 
Georgiy Merts:

Да, конечно. Для написания простейшего индикатора - нет смысла писать структуру классов дата-провайдера, менеджера экрана, виртуальные интерфейсы логики индикатора, и так далее... Преимущество принципов ООП раскрывается в работе с большими и комплексными задачами.

Нюансы о которых говорил Реter Konow существуют и мы их на верняка замечаем в ошибках которые постоянно вылезая от одной билд МТ4 или МТ5   к другому напоминают. Могут перескакивать через несколько-несколько  билдов и опять встречаться или повторятся.

Ничего идеального в ООП тоже нет. 

 
Georgiy Merts:

Да, конечно. Для написания простейшего индикатора - нет смысла писать структуру классов дата-провайдера, менеджера экрана, виртуальные интерфейсы логики индикатора, и так далее... Преимущество принципов ООП раскрывается в работе с большими и комплексными задачами.

Классы - это еще не ООП. Концепция ООП гораздо шире. А классы - это так, ни о чем.

 

Петр, а в чем смыл этой ветки? Появились новые аргументы против ООП?

Это смешно, это как защищать дровяные печи в эпоху электричества.

ООП - это революционный прорыв в области программирования, совершенный, кажется, еще в середине прошлого века (или в конце, но ближе к середине). Всемирно и всецело принятый и признанный.

Если кто-то этого не понимает, он просто болван. 

Это почти  тоже самое, что и против многопоточности выступать за однопоточность.

За NC против Виндос. Между прочим, в свое время, реально случались истерики при установке Виндос, типа оставьте нам NC. 

 
Andrei:

Всё очень неубедительно. В сложных программах никогда заранее нельзя сказать как будет выглядеть конечный код поэтому спроектировать конечный вид программы невозможно и тем более избежать проверок различных конфигураций.

Это уже не говоря про добавку слоя интерфейса который вносит свои баги и затрудняет отладку кода.

Это окончательный вид нельзя спроектировать. А вот базовые интерфейсы - очень даже нормально проектируются.

Выше я показал базовый интерфейс "компоненты торговой позиции". Реально, реализация этого интерфейса - это либо ордер МТ4 либо позиция МТ5. Плюс я не исключаю переходна С++ или С# в WLD - и, думаю, что этот интерфейс вполне сгодится и для торговой позиции на этой платформе.

Далее - базовые интерфейсы  торгового процессора, базовые интерфейсы индикатора, базовые интерфейсы частей эксперта, дата провайдера - все они вполне нормально были спроектированы изначально.

Сейчас - я занимаюсь чисто реализацией этих интерфейсов там, где надо. Причем, виртуальные интерфейсы хороши тем, что можно реализовывать далеко не все сразу. Скажем, мой дата-провайдер сейчас поставляет далеко не все индикаторы, а только лишь те, что мне необходимы. Но, запросить можно любой индикатор, и написать код, который будет с ним работать - как раз через виртуальный интерфейс индикатора. Но, в момент окончательной компиляции - компилятор тут же предупредит, что вызванный индикатор не имеет реализации, ее требуется написать, я и напишу ее. При этом весь код, который будет использовать этот индикатор - будет написан.

 
Uladzimir Izerski:

Ничего идеального в ООП тоже нет. 

Да ООП - это просто технология, которая сильно упрощает сопровождение и модификацию кода. Но при этом требует дополнительные ресурсы при написании. Об "идеальности" никто не говорит. Я уже не раз писал - если всю структуру и особенности кода удается держать в памяти - то смысла в ООП нет.