Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
По всей видимости, static и const (это не ООП) не нужны.
Что же касается ООП, то очень интересно, как будет выглядеть в процедурном стиле следующая, имеющая широкое практическое применение (совсем не абстрактная), функция?
Очевидно, что любой ООП можно переписать в процедурном стиле. Но интересует практика. Поэтому взял вышеприведенный крохотный код, где и ООП используется по минимуму.
Так насколько красивее/удобнее/читабельнее/правильнее процедурный стиль по сравнению с ООП будет в данном примере? Ну чтобы не голословить несколько страниц, а просто сравнить короткие исходники процедурный vs ООП. Прошу противников ООП показать мастер-класс. Это не страшный MT5, а старый добрый MT4.
Я не против ООП. Только один из плохого качества и загадочный код. (I am not an opponent of OOP. Just one of bad quality and cryptic code)
Сильно извиняюсь, Вы в контексте какого языка делаете такой вывод? :-)
Денис, в контексте форумного ))))))))))
Я не против ООП. Только один из плохого качества и загадочный код. (I am not an opponent of OOP. Just one of bad quality and cryptic code)
Спасибо за процедурный код! Немного подправил
Плюсы и минусы каждого из решений (ООП-решение) можно теперь воочию лицезреть. Каждый делает для себя свой выбор и навязывать иную точку зрения просто глупо.
Сильно извиняюсь, Вы в контексте какого языка делаете такой вывод? :-)
Про плюсы конечно.
Спасибо за процедурный код! Немного подправил
Для наглядности с компактностью можно ещё чего-нибудь подправить
Можно, конечно, посмотреть насколько существенно изменится быстродействие при сравнении структур/массивов/строк. Но это кусочек задачи, вырванной из контекста, so смысла нет
PS И я не против ООП. За целесообразность
Для наглядности с компактностью можно ещё чего-нибудь подправить
Можно, конечно, посмотреть насколько существенно изменится быстродействие при сравнении структур/массивов/строк. Но это кусочек задачи, вырванной из контекста, so смысла нет
PS И я не против ООП. За целесообразность
Рухнет!
Для наглядности с компактностью можно ещё чего-нибудь подправить
Можно, конечно, посмотреть насколько существенно изменится быстродействие при сравнении структур/массивов/строк. Но это кусочек задачи, вырванной из контекста, so смысла нет
PS И я не против ООП. За целесообразность
Использование DEFINE было шуткой ;-) Ваш подход будет очень медленным. (Usage of DEFINE was a joke ;-) Your approach will be very slow.)
Использование DEFINE было шуткой ;-) Ваш подход будет очень медленным. (Usage of DEFINE was a joke ;-) Your approach will be very slow.)
Sure. This is joke too - this is a code beautiness parade, isn't it?
Это тоже шутка - выкрутас в пользу компактности и наглядности
---
Рухнет!
Это же замер конкретной реализации, частный случай
Sure. This is joke too - this is a code beautiness parade, isn't it?
Yes really nice. (I am not able to catch joke yet unfortunately ;-)
Да, действительно приятно. К сожалению, я не в состоянии поймать шутку ;-)
Плюсы и минусы каждого из решений (ООП-решение) можно теперь воочию лицезреть. Каждый делает для себя свой выбор и навязывать иную точку зрения просто глупо.
Навязывать не надо, но очевидно что в процедурном виде уже просматривается логика кода без лишних телодвижений, а каждое телодвижение наемного программиста стоит работодателю денежку. Поэтому если работодатель не дурак, то он не поведется на ООП, но зато хитрый программист может ему навешать лапшу про прогрессивность ООП чтобы срубить с него побольше воспользовавшись его малограмотностью. :)