Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У класса есть только внутренние переменные и нет входных и выходных... Где вы видели применение в программировании такого объекта, который никак не контактирует с внешним миром и варится в собственном соку?
А зачем вы тут рассуждаете о том, чего не видели? Создается конструктор класса и он может получать любое количество параметров. Разные дочерние классы могу в своих конструкторах иметь совершенно разные наборы параметров. Да можно и просто методы писать для установки параметров.
1. Это главный ответ на необходимость ООП.
2. Это вопрос опыта работы в командах. Я написал все что нужно 2008-2009 году. Пару лет назад решил написать еще - все читается , никаких проблем.
Из Ваших ответов я понял одно: ООП - это некий стандарт, который внедряет дисциплину программирования, внедряет однообразие и на этом основании меньше ошибок изначально, а главное, и самое важное, принципиально уменьшаются проблемы при модификации. Но этот же результат получали при тщательном соблюдении ГОСТов, стадийности разработки, документированности.
Сколько можно вам повторять одно и тоже? ООП это не просто средство структурирование кода, в нем еще есть такие механизмы, которых нет в вашем процедурном программировании.
Эти наверно тот случай, если человек не видел гор, он не поймет, что это, хоть обрассказывайся ему.
Я лично стремлюсь к универсальности в решениях. Это требует "сращивать" похожие функции в один блок без увеличения объема кода. Повышает эффективность механизма и никакой перегрузки и разделения не надо. Только мозгами хорошо поработать и все.)
То есть было две функции в 20 строчек каждая. Обе исполняют похожие действия или решают однотипные задачи. Моя цель - сделать из них одну функцию не более 20 строчек кода исполняющую работу обоих функций. Так у меня возникают блоки.
Как долго вы корпели над этой своей библиотекой?
Холивара ради - R написан абсолютно отвратительно в режиме "все в одну помойку без разграничения доступа". Олдскульный подход двадцатилетней давности без областей видимости, защиты и многосессионности. Пишу как будто я один. Да проект так и рождался под одно лицо непрофессиональными разработчиками. Его переписывать с нуля надо. Хотя бы раз.
Была мысль сделать нормальный интрерфейс в R из MQL5, но после того, как глубже покопался в нем, сразу отказал в интеграции. Система категорически не способна защищать данные и сессии.
Пока программист не поработает в нормальных девелоперских коллективах с жесткими требованиями(битиЁм по рукам в течение пары лет минимум), он не станет разработчиком в нормальном смысле. Мы хватаемся за голову в 90% случаев, когда смотрим на тестовые задания при рассмотрении кандидатов. Тотальный ужас по всей индустрии разработки.
Поэтому еще раз повторю - оппоненты ООП демонстрируют тут какой-то балаган.
Извините еще раз.
Обалдеть!
Мне вот стало интересно: есть ли еще какая-либо возможность в совремнном программировании круче запутать проблему уровня выеденного яйца?
Это ты к автомобилю подойди, который стоит в пробке, погляди на то, как он устроен - и скажи водителю, мол, "есть ли какая возможность круче запутать проблему, тут пройти сто метров".
Как показывает мой опыт, в таких вот, "запутанных проблемах" - куда проще разобраться, чем в "беспроблемных" советниках, сделанных с помощью копипасты из единого шаблона со всеми глобальными переменными.
А зачем вы тут рассуждаете о том, чего не видели? Создается конструктор класса и он может получать любое количество параметров.
Читайте внимательней, речь шла о классе, а не о конструкторе класса.
К тому же вы опять предлагаете заняться мартышкиным трудом - городить огород на огороде, если можно иметь доступ к параметрам НИЧЕГО не делая в случае внешних переменных либо передавая их напрямую без всякой ненужной головной боли с конструкторами-деструкторами и всякими сопутствующими утечками памяти.
У меня OnInit() выглядит примерно также - десяток строчек...
И что?
Если уж на то пошло, то у меня во ВСЕМ советнике - десяток строк (если не считать инклюды да комментарии).
Здесь в одном эксперте - сразу ТРИ совершенно разных ТС. Они - одновременно работают, не мешая друг другу.
Можно добавить дополнительные ТСы, просто объявив соответствующую фабрику, и вписав в функцию код, ее возвращающий.
Но реально вопрос не о том, мало или много строк в коде. Вопрос в том, насколько их просто поддерживать и модифицировать при необходимости.
СанСаныч, ты сможешь с легкостью разобраться в файле таблице, предоставленном Петром ? И модификация ее тебе удастся запросто ? Ну, тогда тебе, как и Петру - ООП не нужно.
ООП - это метод разделить, завернуть и спрятать части механизма. Нужно это или нет, решать только разработчику. К повышению эффективности работы механизма это вообще отношения не имеет. Структурирует мышление, - да. Правильно ли структурирует - неизвестно. Нужно ли это - зависит от конкретного человека. имхо.
Именно так. В этом суть инкапсуляции.
Там еще есть наследование и полиморфизм.
ООП - это метод разделить, завернуть и спрятать части механизма. Нужно ли это - зависит от конкретного человека. имхо.
Вот именно, что от конкретного человека. Зачем программисту, который не страдает шизофренией, усиленно прятать от себя самого доступ к какой-то части собственного кода, отладкой которого он же и занимается? Может лучше руки себе завязать? :)
Пока программист не поработает в нормальных девелоперских коллективах с жесткими требованиями(битиЁм по рукам в течение пары лет минимум), он не станет разработчиком в нормальном смысле. Мы хватаемся за голову в 90% случаев, когда смотрим на тестовые задания при рассмотрении кандидатов. Тотальный ужас по всей индустрии разработки.
А вот интересно в чем проявляется этот "ужас".
Могу предположить, что это связано с использованием ООП, так как при процедурном программировании основное внимание уделяется логике работы алгоритма, а не всяким внешним ООП-ешным надстройкам, которыми очень легко нагородить лес любой дремучести.