Самосознание. - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...
ООП - это революционный прорыв в области программирования, совершенный, кажется, еще в середине прошлого века (или в конце, но ближе к середине). Всемирно и всецело принятый и признанный.
Если кто-то этого не понимает, он просто болван.
Это почти тоже самое, что и против многопоточности выступать за однопоточность.
За NC против Виндос. Между прочим, в свое время, реально случались истерики при установке Виндос, типа оставьте нам NC.
Мысль проста:
Разрастание концептуальной базы ООП начинает снижать КПД программистов и увеличивать оверхед программ. Вот и все.
Программисты конечно будут не против этого, а разработчики наоборот против. Программистам нужна работа, а разработчикам результат.
Отсюда вся моя критика ООП возникает. Мне предлагается делать свою работу дольше и тяжелее, но зато "концептуально мощно". :)
Это вызывает у меня улыбку...
Не все что создается действительно нужно и полезно. Сущности нужно уметь не только добавлять, но и уничтожать.
ЗЫ. Я не против ООП, я за разумное использование способности человека добавлять сущности.
ЗЗЫ. Лучший пример: представьте, что боевое самбо начнет "обрастать" театральными элементами кунг-фу. Что на это скажут матера спорта?
Начиная с программирования в машинном коде, ассемблеры и т.д...., наверно при каждом переходе на новый уровень, всегда находились люди, считавшие, что раньше было лучше. Но прогресс не остановить. Как бы ни был хорош BMW 7, но появление BMW 8 неизбежно произойдёт. Так и с программированием, кто-нибудь придумает новый подход и с ООП возможно придётся расстаться.
Начиная с программирования в машинном коде, ассемблеры и т.д...., наверно при каждом переходе на новый уровень, всегда находились люди, считавшие, что раньше было лучше. Но прогресс не остановить. Как бы ни был хорош BMW 7, но появление BMW 8 неизбежно произойдёт. Так и с программированием, кто-нибудь придумает новый подход и с ООП возможно придётся расстаться.
Нет, с ООП рановато расставаться, этому подходу цены нет. Всё очень кратко, эффектно и немного непонятно, откуда же такой (в принципе очень хороший!) результат прёт?
Петр, а в чем смыл этой ветки? Появились новые аргументы против ООП?
Это смешно, это как защищать дровяные печи в эпоху электричества.
ООП - это революционный прорыв в области программирования, совершенный, кажется, еще в середине прошлого века (или в конце, но ближе к середине). Всемирно и всецело принятый и признанный.
Если кто-то этого не понимает, он просто болван.
Это почти тоже самое, что и против многопоточности выступать за однопоточность.
За NC против Виндос. Между прочим, в свое время, реально случались истерики при установке Виндос, типа оставьте нам NC.
Я бы не был столь категоричен, хотя бы потому что:
Нет, с ООП рановато расставаться, этому подходу цены нет. Всё очень кратко, эффектно и немного непонятно, откуда же такой (в принципе очень хороший!) результат прёт?
Ну допустим какие-то новые гении создали программирующий робот. Вы ему задаёте перечень используемых средств: MT5, MQL5, справочник по документации MT5, MQL5, и параметры, который должен иметь советник. А он пошевелит своими мозгами и через какое-то время выдаёт код прибыльного советника. Разве вы бы от такого робота отказались, наверно не стали бы говорить: нет я лучше с ООП тут лет пять поковыряюсь, может и получится советник со стабильной прибылью.)))
Ну допустим какие-то новые гении создали программирующий робот. Вы ему задаёте перечень используемых средств: MT5, MQL5, справочник по документации MT5, MQL5, и параметры, который должен иметь советник. А он пошевелит своими мозгами и через какое-то время выдаёт код прибыльного советника. Разве вы бы от такого робота отказались, наверно не стали бы говорить: нет я лучше с ООП тут лет пять поковыряюсь, может и получится советник со стабильной прибылью.)))
"Ковыряться" с советниками можно сколько угодно. Важно, что и в MQL4 и в MQL5 возможности ОО-программирования и проектирования уже заложены, надо только их понять, осознать и использовать!
Я бы не был столь категоричен, хотя бы потому что:
1. Наследование - очень даже правильный и хороший механизм. Я за счет наследования легко "прикручиваю" к экспертам новые блоки, совершенно не вмешиваясь в работу уже написанного. Как раз наследование позволяет не думать о том, кто и как будет использовать то, что ты пишешь. Имеется интерфейс, ты наследуешься от него, и реализуешь все функции так, как необходимо. Интерфейс гарантирует, что твой блок будет использоваться именно так, как установлено, и ошибок не будет.
2. Писать семафоры и мьютексы совершенно одинаково неприятно как в ООП, так и в процедурном стиле. И сложность вылавливания ошибок в многопоточных приложениях - мало зависит от процедурности или ООП.
3. Если у объектов много состояний, и они общаются друг с другом - то как раз ООП позволяет упорядочить этот обмен, привести его к единому стандарту, и сосредоточить в одном месте, чтобы потом гораздо проще выявлять ошибки и вносить модификации.
2. Писать семафоры и мьютексы совершенно одинаково неприятно как в ООП, так и в процедурном стиле. И сложность вылавливания ошибок в многопоточных приложениях - мало зависит от процедурности или ООП.
О процедурном программировании я ни слова не сказал. Реальной альтернативой ООП является функциональное программирование. Посмотрите как функциональный подход решает проблему с многопоточностью.
1. Наследование - очень даже правильный и хороший механизм. Я за счет наследования легко "прикручиваю" к экспертам новые блоки, совершенно не вмешиваясь в работу уже написанного. Как раз наследование позволяет не думать о том, кто и как будет использовать то, что ты пишешь. Имеется интерфейс, ты наследуешься от него, и реализуешь все функции так, как необходимо. Интерфейс гарантирует, что твой блок будет использоваться именно так, как установлено, и ошибок не будет.
Правильный механизм до той самой поры, пока вдруг оказывается что нужный тебе функционал зашит в другом классе, наследоваться от которого нельзя (разные ветви наследования). То, о чем Вы говорите это скорее программирование на уровне вертикальных интерфейсов: базовый класс содержит виртуальные методы, а уже его потомки реализуют конкретный функционал. При этом работа на общем уровне идет именно через базовый класс, конструктор которого защищен. Да, это хорошая практика. Но этого не достаточно, т.к. как минимум необходимы горизонтальные взаимосвязи, а их нет.
3. Если у объектов много состояний, и они общаются друг с другом - то как раз ООП позволяет упорядочить этот обмен, привести его к единому стандарту, и сосредоточить в одном месте, чтобы потом гораздо проще выявлять ошибки и вносить модификации.
Позволяет не само ООП, а архитектура ПО. Проблема в том, что бы создать эту самую архитектуру. Для этого дополнительные навыки нужны. Само по себе знание ООП их не дает.
Я бы не был столь категоричен, хотя бы потому что:
Василий, вы же тут как-то рассказывали, что кодите строго в стиле жесткого ООП? Прошла любовь?
Может просто, без действительной надобности не нужно создавать классы?
Мысль проста:
Разрастание концептуальной базы ООП начинает снижать КПД программистов и увеличивать оверхед программ. Вот и все.
Программисты конечно будут не против этого, а разработчики наоборот против. Программистам нужна работа, а разработчикам результат.
Отсюда вся моя критика ООП возникает. Мне предлагается делать свою работу дольше и тяжелее, но зато "концептуально мощно". :)
Это вызывает у меня улыбку...
Не все что создается действительно нужно и полезно. Сущности нужно уметь не только добавлять, но и уничтожать.
ЗЫ. Я не против ООП, я за разумное использование способности человека добавлять сущности.
ЗЗЫ. Лучший пример: представьте, что боевое самбо начнет "обрастать" театральными элементами кунг-фу. Что на это скажут матера спорта?
Ну вот и надо пользоваться ООП разумно, а то сдуру, как говорится, можно и...