ООП vs процедурное программирование - страница 39

Новый комментарий
 
Andrei:

У класса есть только внутренние переменные и нет входных и выходных... Где вы видели применение в программировании такого объекта, который никак не контактирует с внешним миром и варится в собственном соку?


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

 
СанСаныч Фоменко:

1. Это главный ответ на необходимость ООП.

2. Это вопрос опыта работы в командах. Я написал все что нужно 2008-2009 году. Пару лет назад решил написать еще - все читается , никаких проблем.


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


Сколько можно вам повторять одно и тоже? ООП это не просто средство структурирование кода, в нем еще есть такие механизмы, которых нет в вашем процедурном программировании. 

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

 
Реter Konow:

Я лично стремлюсь к универсальности в решениях. Это требует "сращивать" похожие функции в один блок без увеличения объема кода. Повышает эффективность механизма и никакой перегрузки и разделения не надо. Только мозгами хорошо поработать и все.)

То есть было две функции в 20 строчек каждая. Обе исполняют похожие действия или решают однотипные задачи. Моя цель - сделать из них одну функцию не более 20 строчек кода исполняющую работу обоих функций. Так у меня возникают блоки.


Как долго вы корпели над этой своей библиотекой?

 

Холивара ради - R написан абсолютно отвратительно в режиме "все в одну помойку без разграничения доступа". Олдскульный подход двадцатилетней давности без областей видимости, защиты и многосессионности. Пишу как будто я один. Да проект так и рождался под одно лицо непрофессиональными разработчиками. Его переписывать с нуля надо. Хотя бы раз.

Была мысль сделать нормальный интрерфейс в R из MQL5, но после того, как глубже покопался в нем, сразу отказал в интеграции. Система категорически не способна защищать данные и сессии.

Пока программист не поработает в нормальных девелоперских коллективах с жесткими требованиями(битиЁм по рукам в течение пары лет минимум), он не станет разработчиком в нормальном смысле. Мы хватаемся за голову в 90% случаев, когда смотрим на тестовые задания при рассмотрении кандидатов. Тотальный ужас по всей индустрии разработки.

Поэтому еще раз повторю - оппоненты ООП демонстрируют тут какой-то балаган.

Извините еще раз.

 
СанСаныч Фоменко:

Обалдеть!

Мне вот стало интересно: есть ли еще какая-либо возможность в совремнном программировании  круче запутать проблему уровня выеденного яйца?

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

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

 
Dmitry Fedoseev:

А зачем вы тут рассуждаете о том, чего не видели? Создается конструктор класса и он может получать любое количество параметров.

Читайте внимательней, речь шла о классе, а не о конструкторе класса.

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

 
СанСаныч Фоменко:

У меня OnInit() выглядит примерно также - десяток строчек...

И что?

Если уж на то пошло, то у меня во ВСЕМ советнике - десяток строк (если не считать инклюды да комментарии). 

#include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory(uint uiFactIdx = 0)
{
   if(uiFactIdx == 0) return(GetPointer(epfFact_0)); 
   if(uiFactIdx == 1) return(GetPointer(epfFact_1)); 
   if(uiFactIdx == 2) return(GetPointer(epfFact_2)); 
   return(NULL); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

Здесь в одном эксперте - сразу ТРИ совершенно разных ТС. Они - одновременно работают, не мешая друг другу.

Можно добавить дополнительные ТСы, просто объявив соответствующую фабрику, и вписав в функцию код, ее возвращающий.

Но реально вопрос не о том, мало или много строк в коде. Вопрос в том, насколько их просто поддерживать и модифицировать при необходимости.

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

 
Реter Konow:
ООП - это метод разделить, завернуть и спрятать части механизма. Нужно это или нет, решать только разработчику. К повышению эффективности работы механизма это вообще отношения не имеет. Структурирует мышление, - да. Правильно ли структурирует - неизвестно. Нужно ли это - зависит от конкретного человека. имхо.

Именно так. В этом суть инкапсуляции.

Там еще есть наследование и полиморфизм.

 
Реter Konow:
ООП - это метод разделить, завернуть и спрятать части механизма. Нужно ли это - зависит от конкретного человека. имхо.

Вот именно, что от конкретного человека. Зачем программисту, который не страдает шизофренией, усиленно прятать от себя самого доступ к какой-то части собственного кода, отладкой которого он же и занимается? Может лучше руки себе завязать? :)

 
Renat Fatkhullin:

Пока программист не поработает в нормальных девелоперских коллективах с жесткими требованиями(битиЁм по рукам в течение пары лет минимум), он не станет разработчиком в нормальном смысле. Мы хватаемся за голову в 90% случаев, когда смотрим на тестовые задания при рассмотрении кандидатов. Тотальный ужас по всей индустрии разработки.

А вот интересно в чем проявляется этот "ужас".

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

1...323334353637383940414243444546...48
Новый комментарий
Причина обращения: