Самосознание. - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Василий, вы же тут как-то рассказывали, что кодите строго в стиле жесткого ООП? Прошла любовь?
Может просто, без действительной надобности не нужно создавать классы?
Нет, любовь не прошла, и помидоры не завяли. Кожу по-прежнему в стиле жесткого ООП. Просто со временем начинаешь понимать проблемы любимого инструмента. И чем больше практики, тем больше чувствуешь тесноту и ограничения подхода, особенно в среде MQL.
ООП вещь действительно хорошая, но говорить в стиле: "Православие ООП или смерть" это шапкозакидательство.
О процедурном программировании я ни слова не сказал. Реальной альтернативой ООП является функциональное программирование. Посмотрите как функциональный подход решает проблему с многопоточностью.
Правильный механизм до той самой поры, пока вдруг оказывается что нужный тебе функционал зашит в другом классе, наследоваться от которого нельзя (разные ветви наследования). То, о чем Вы говорите это скорее программирование на уровне вертикальных интерфейсов: базовый класс содержит виртуальные методы, а уже его потомки реализуют конкретный функционал. При этом работа на общем уровне идет именно через базовый класс, конструктор которого защищен. Да, это хорошая практика. Но этого не достаточно, т.к. как минимум необходимы горизонтальные взаимосвязи, а их нет.
Позволяет не само ООП, а архитектура ПО. Проблема в том, что бы создать эту самую архитектуру. Для этого дополнительные навыки нужны. Само по себе знание ООП их не дает.
1. Многопоточность - это везде проблема с синхронизацией. В функциональном подходе - тоже.
2. Все верно, изредка оказывается, что нужного функционала нет. Пару раз приходилось писать совершенно немыслимые "костыли" через friend-классы. Но, это явная ошибка проектирования. Если система спроектирована правильно - то базовые классы содержат необходимые методы, и все верно - функционал реализуется в потомках так, как необходимо.
Горизонтальные связи у меня реализуется "концентратором"-синглтоном. Объектом CExpert. Стандартные функции обработки событий - все обращаются именно к этому объекту, и уже он - либо вызывает нужные части, передавая им указатели на необходимые ресурсы, либо эти самые части, внутри вызова - могут обратиться к CExpert'у, получить необходимый интерфейс, и запросить (или передать) нужные данные
3. Так когда говорится "использование ООП" - это ж не только "знание". Это еще и правильное применение. Архитектура ПО, построенная на принципах ООП - уже сама по себе ограничивает возможности бесконтрольного обращения "куда не следует".
...
Горизонтальные связи у меня реализуется "концентратором"-синглтоном. Объектом CExpert. Стандартные функции обработки событий - все обращаются именно к этому объекту, и уже он - либо вызывает нужные части, передавая им указатели на необходимые ресурсы, либо эти самые части, внутри вызова - могут обратиться к CExpert'у, получить необходимый интерфейс, и запросить (или передать) нужные данные
...
Интересное решение. Хотя потенциально синглтоны могут нести определенные проблемы. А код Вашей либы можно посмотреть?
Вот о том и разговор, что ООП это хорошо, но и убиться в ООП еще легче чем в процедурном стиле.
Интересное решение. Хотя потенциально синглтоны могут нести определенные проблемы. А код Вашей либы можно посмотреть?
Слишком много файлов. Давай мейл, скину архивом.
Слишком много файлов. Давай мейл, скину архивом.
Скинул в личку
Мои высказывания всегда стоит воспринимать как только мое мнение. Я не претендую на истину в последней инстанции. Все что я говорю - субъективно.
//--------------------------------------------------------------------------------------------------------------------------------------------------------------
Что ЛИЧНО меня не устраивает в ООП:
Когда я думаю об ООП, я всегда протестую против жестких рамок, правил и ограничений в которые попадает моя мысль. Я ведь не ищу костылей в работе. Я хочу свободно творить и воплощать идеи. На ум приходят формации и структуры разной формы. Но ООП мне говорит: ТАК НЕЛЬЗЯ. Нужно подчинятся обязательной классификации. То есть:
1. В ООП, важность классификации преобладает над важностью эффективности кода. Важность порядка преобладает над важностью хаоса (ниже поясню).
2. В ООП предопределены способы построения архитектуры и внутренних связей функционала.
//--------------------------------------------------------------------------------------------------------------------------------------------------------------
1. Первый пункт рождается из необходимости в "костыле" для сознания, которое стремится незапутаться в своих мыслях.
С точки зрения эффективности устройства механизмов, четкая классификация является вредным явлением. Она увеличивает дистанции между деталями. Создает дополнительные барьеры в механизмах.
С точки зрения нашего сознания, классификация, - это путь к порядку и легкости понимания.
Таким образом, - на первом этапе, стремление к порядку ведет к повышению эффективности, а на последнем, - уводит от него.
Абсолютная эффективность не появляется от человеческого стремления к порядку, а наоборот страдает от этого.
Стремление к абсолютному порядку, это НЕ стремление к абсолютной эффективности, а стремление овладеть "волшебным костылем", который будет всегда выручать. Это, - слабое место нашего мышления.
//--------------------------------------------------------------------------------------------------------------------------------------------------------------
2. Второй пункт рождается из негласного тезиса: "Архетип сознания у всех один, а следовательно все должны следовать общей схеме".
Но это не так. Архетипы могут различаться. Я например, склонен смотреть на вещи через призму "Явление-Суть". То есть, вижу Явление и сразу ищу Суть.
Другие могут смотреть на вещи иначе. Например "Явление, Явление, и еще Явление...".
Я могу создавать сущности (свои понятия) и уничтожать их.
Некоторые другие могут только добавлять сущности, но не способны их уничтожать. Третьи вообще не создают и не уничтожают сущности. Вся их задача - ориентироваться среди уже созданных вещей и явлений.
Поэтому, лично для меня ООП может быть совершенно неэффективен, но для других - самое то. Все субъективно.
//--------------------------------------------------------------------------------------------------------------------------------------------------------------
Иногда чья то свободная творческая энергия стремится разрушить деспотизм жесткой предопределенности. Утверждает свой выбор, вопреки выбору миллионов других людей.
Это заложено в человеческую природу. Благодаря этому, мир развивается. Запрем свободу творческого поиска и попадем в вечную стагнацию.
//--------------------------------------------------------------------------------------------------------------------------------------------------------------
Похоже вы все тут не с той стороны подъехали к ООП.
ООП это в первую очередь средство группировки функций и переменных. Поэтому, никакой борьбы и противостояния функционального программирования и ООП в принципе быть не должно.
Надо группировать - группируй - пиши класс, а не надо - пиши просто функцию.
ООП это наша жизнь.
Оно описывает взаимосвязь, взаимоотношение а также поведение различных систем нашего общества.
ООП начально-конечен. На первом этапе он способствует и развивает, а на последнем, - все больше тормозит и мешает.
В силу начально-конечной природы ООП, рост его концептуальной базы давно миновал границы смысла его применения.
ООП начально-конечен. На первом этапе он способствует и развивает, а на последнем, - все больше тормозит и мешает.
В силу начально-конечной природы ООП, рост его концептуальной базы давно миновал границы смысла его применения.
Вместо того, чтобы тратить столько времени на этом форуме, за столько лет вы могли бы учится ООП.
И наконец то поняли бы, что без ООП, организовать работу при коллективной разработке больших проектов, просто не возможно.