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

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Vasiliy Sokolov
41196
Vasiliy Sokolov  
Dmitry Fedoseev:

Василий, вы же тут как-то рассказывали, что кодите строго в стиле жесткого ООП? Прошла любовь? 

Может просто, без действительной надобности не нужно создавать классы?

Нет, любовь не прошла, и помидоры не завяли. Кожу по-прежнему в стиле жесткого ООП. Просто со временем начинаешь понимать проблемы любимого инструмента. И чем больше практики, тем больше чувствуешь тесноту и ограничения подхода, особенно в среде MQL. 

ООП вещь действительно хорошая, но говорить в стиле: "Православие ООП или смерть" это шапкозакидательство.

Georgiy Merts
8812
Georgiy Merts  
Vasiliy Sokolov:

О процедурном программировании я ни слова не сказал. Реальной альтернативой ООП является функциональное программирование. Посмотрите как функциональный подход решает проблему с многопоточностью.

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

 Позволяет не само ООП, а архитектура ПО. Проблема в том, что бы создать эту самую архитектуру. Для этого дополнительные навыки нужны. Само по себе знание ООП их не дает. 

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

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

Горизонтальные связи у меня реализуется "концентратором"-синглтоном. Объектом CExpert.  Стандартные функции обработки событий - все обращаются именно к этому объекту, и уже он - либо вызывает нужные части, передавая им указатели на необходимые ресурсы, либо эти самые части, внутри вызова - могут обратиться к CExpert'у, получить необходимый интерфейс, и запросить (или передать) нужные данные

3. Так когда говорится "использование ООП" - это ж не только "знание". Это еще и правильное применение. Архитектура ПО, построенная на принципах ООП - уже сама по себе ограничивает возможности бесконтрольного обращения "куда не следует".

Vasiliy Sokolov
41196
Vasiliy Sokolov  
Georgiy Merts:

...

Горизонтальные связи у меня реализуется "концентратором"-синглтоном. Объектом CExpert.  Стандартные функции обработки событий - все обращаются именно к этому объекту, и уже он - либо вызывает нужные части, передавая им указатели на необходимые ресурсы, либо эти самые части, внутри вызова - могут обратиться к CExpert'у, получить необходимый интерфейс, и запросить (или передать) нужные данные

...

Интересное решение. Хотя потенциально синглтоны могут нести определенные проблемы. А код Вашей либы можно посмотреть?

Georgiy Merts:

Вот о том и разговор, что ООП это хорошо, но и убиться в ООП еще легче чем в процедурном стиле.  

Georgiy Merts
8812
Georgiy Merts  
Vasiliy Sokolov:

Интересное решение. Хотя потенциально синглтоны могут нести определенные проблемы. А код Вашей либы можно посмотреть?

Слишком много файлов. Давай мейл, скину архивом.

Vasiliy Sokolov
41196
Vasiliy Sokolov  
Georgiy Merts:

Слишком много файлов. Давай мейл, скину архивом.

Скинул в личку

Реter Konow
7341
Реter Konow  

Мои высказывания всегда стоит воспринимать как только мое мнение. Я не претендую на истину в последней инстанции. Все что я говорю - субъективно.

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

Что ЛИЧНО меня не устраивает в ООП:

Когда я думаю об ООП, я всегда протестую против жестких рамок, правил и ограничений в которые попадает моя мысль. Я ведь не ищу костылей в работе. Я хочу свободно творить и воплощать идеи. На ум приходят формации и структуры разной формы. Но ООП мне говорит: ТАК НЕЛЬЗЯ. Нужно подчинятся обязательной классификации. То есть:

1. В ООП, важность классификации преобладает над важностью эффективности кода. Важность порядка преобладает над важностью хаоса (ниже поясню).   

2. В ООП предопределены способы построения архитектуры и внутренних связей функционала.

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

1. Первый пункт рождается из необходимости в "костыле" для сознания, которое стремится незапутаться в своих мыслях.

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

С точки зрения нашего сознания, классификация, - это путь к порядку и легкости понимания.

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

Абсолютная эффективность не появляется от человеческого стремления к порядку, а наоборот страдает от этого.

Стремление к абсолютному порядку, это НЕ стремление к абсолютной эффективности, а стремление овладеть "волшебным костылем", который будет всегда выручать. Это, - слабое место нашего мышления.

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

2. Второй пункт рождается из негласного тезиса: "Архетип сознания у всех один, а следовательно все должны следовать общей схеме".  

Но это не так. Архетипы могут различаться. Я например, склонен смотреть на вещи через призму "Явление-Суть". То есть, вижу Явление и сразу ищу Суть.

Другие могут смотреть на вещи иначе. Например "Явление, Явление, и еще Явление...".

Я могу создавать сущности (свои понятия) и уничтожать их.

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

Поэтому, лично для меня ООП может быть совершенно неэффективен, но для других - самое то. Все субъективно.

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

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

Это заложено в человеческую природу. Благодаря этому, мир развивается. Запрем свободу творческого поиска и попадем в вечную стагнацию.

//--------------------------------------------------------------------------------------------------------------------------------------------------------------

Dmitry Fedoseev
54223
Dmitry Fedoseev  

Похоже вы все тут не с той стороны подъехали к ООП.

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

Надо группировать - группируй - пиши класс, а не надо - пиши просто функцию.

Petros Shatakhtsyan
13673
Petros Shatakhtsyan  

ООП это наша жизнь.

Оно описывает взаимосвязь, взаимоотношение а также поведение различных систем нашего общества.

Реter Konow
7341
Реter Konow  

ООП начально-конечен. На первом этапе он способствует и развивает, а на последнем, - все больше тормозит и мешает. 

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

Petros Shatakhtsyan
13673
Petros Shatakhtsyan  
Реter Konow:

ООП начально-конечен. На первом этапе он способствует и развивает, а на последнем, - все больше тормозит и мешает. 

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

Вместо того, чтобы тратить столько времени на этом форуме, за столько лет вы могли бы учится ООП.

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

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий