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

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

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

Я вот, в 200кб кода - уже мало что помню.

Более того, в соседней ветке я приводил пример кода из ТРЕХ строк, автор которого тоже уже не помнит, почему он именно такой. Но если все тонкости удерживаются в памяти - то городить огород с виртуализацией и ООП, как у меня - нет никакого смысла.

 
Vitaly Muzichenko:

Ясно, а приобретаете его наверное в обмен на копыто оленя)

на алмазы конечно :))

 

Georgiy Merts:

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

Всё как раз обстоит наоборот. Именно в ООП нужно помнить структуру объектов и что от чего было нагорожено и это без учета основной логики программы, которую тоже еще нужно суметь вычленить если она разбросана по разным углам.

Без ООП вся логика всегда группируется в одном месте. Именно поэтому новому программисту часто проще переписать заново весь код чем разбираться со всеми ООП-ешными финтилями.

 
Georgiy Merts:

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

Я вот, в 200кб кода - уже мало что помню.

Более того, в соседней ветке я приводил пример кода из ТРЕХ строк, автор которого тоже уже не помнит, почему он именно такой. Но если все тонкости удерживаются в памяти - то городить огород с виртуализацией и ООП, как у меня - нет никакого смысла.

Мне трудно судить, являюсь ли я гигантом запоминания. Не уверен. Врядли. 

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

ЗЫ. Безусловно, сущностей в ООП все таки чрезмерно много. На мой взгляд. Но, может быть они кому то помогают решать задачи? Кто знает...
 
Andrei:

Всё как раз обстоит наоборот. Именно в ООП нужно помнить структуру объектов и что от чего было нагорожено и это без учета основной логики программы, которую тоже еще нужно суметь вычленить если она разбросана по разным углам.

Без ООП вся логика всегда группируется в одном месте. Именно поэтому новому программисту часто проще переписать заново весь код чем разбираться со всеми ООП-ешными финтилями.

Ты не прав.

В ООП - не нужно помнить структуру объектов. Достаточно помнить самые базовые, которые есть в каждом эксперте. Скажем, тот же объект эксперта.

Я уже приводил примеры.

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

class CTradePositionI: public CMyObject
{
public:
   void CTradePositionI() {    SetMyObjectType(MOT_TRADE_POSITION_I); };
   virtual void ~CTradePositionI() {};
   
   // Выбор существующей позиции. 
   // Указывается магик и символ, по которому выбираются действующие ордера.
   // Если ulMagic = 0 - выбираются все позиции по всем магикам.
   // Если ECurrencySymbol = CS_UNKNOWN - выбираются все позиции по всем символам
   // Если ECurrencySymbol = CS_CURRENT - запрашивается функция Symbol(), и выбираются все позиции по этому символу
   // Возвращает число компонент позиции внутри позиции (может быть нулевым если позиции нет) или WRONG_VALUE в случае ошибок
   // Каждая фабрика (наследник CEAPartsFactoryT) имеет одну позицию, которая на каждом CEAPartsFactoryT::OnRefresh()
   // обновляется в соответствии с магиком и рабочим символом фабрики. 
   virtual int Select(ulong ulMagic = 0,ECurrencySymbol csSymbol = CS_CURRENT) = 0;

   virtual uint GetTotalComponents() const = 0;  // Получение общего числа компонент
   virtual uint GetNumOfComponentsOnDirection(ENUM_POSITION_TYPE etDirection) const = 0; // Получение числа компонент указанного направления (если tdDirection = TD_FLAT - то всех компонент)  и интерфейс отдельной компоненты
   virtual CTradePosComponentI* GetComponent(uint uiComponentIdx) const = 0;
};

Как видишь, все функции понятно, что делают, и приравнены нулям, ты не знаешь, что за ними стоит, и у тебя нет возможности туда "влезть".

Ты только можешь выбрать позицию функцией Select(), запросить число ее компонент, и получить любую компоненту.

Причем, при запросе компоненты - ты опять же, получаешь чисто виртуальный интерфейс:

class CTradePosComponentI: public CMyObject
{
public:
   void CTradePosComponentI() {    SetMyObjectType(MOT_TRADEPOS_COMPONENT_I); };
   virtual void ~CTradePosComponentI() {};
   
   // Основной интерфейс
   virtual long               GetTPCTicket()       const = 0;
   virtual long               GetTPCMagic()        const = 0;
   virtual ECurrencySymbol    GetTPCSymbol()       const = 0;
   virtual ENUM_POSITION_TYPE GetTPCType()         const = 0;
   virtual datetime           GetTPCOpenTime()     const = 0;
   virtual double             GetTPCVolume()       const = 0;
   virtual double             GetTPCOpenPrice()    const = 0;
   virtual double             GetTPCStopLoss()     const = 0;
   virtual double             GetTPCTakeProfit()   const = 0;
   virtual string             GetTPCCommentary()   const = 0;
   
};

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

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

Потому-то тебе и помнить тут ничего не надо - когда ты кругом ограничен - ты не можешь сделать ничего неправильного.

 
Georgiy Merts:


По сути, ООП это вынесенный "наружу" архетип подсознания, превращенный в свод правил.   

Архетип крепко и четко "впечатан" в Подсознание человека, и его через ООП доводят до Сознания. Человек, познавая ООП начинает понимать, как он сам бессознательно мыслит. Он все дробит на Объекты и свойства. Все подчиняет структуре. Благодаря ООП, человек начинает это делать сознательно.

С помощью ООП, человек сознательно осваивает собственные, базовые когнитивные функции.

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

 
Реter Konow:

Проходят месяцы, годы... Человек взрослеет, 

A Peter Konow все прежний ^)

Борьба с иллюзиями касательно ооп продолжается, вместо того что бы изучить его за неделю и забыть.. :) И использовать когда надо

 
Реter Konow:
Реter Konow 2017.08.11 20:45    RU

Ты или Вы не важно...

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

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

Реter Konow 29.08.2018

Вы не очень то вежливы в общении, дорогой друг (это насчет "Ты или Вы не важно").

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

Опять нескромность. Самоуверенность и преувеличение.

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

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

 
Maxim Dmitrievsky:

A Peter Konow все прежний ^)

Борьба с иллюзиями касательно ооп продолжается, вместо того что бы изучить его за неделю и забыть.. :) И использовать когда надо

Не, тут действительно существенно разный подход.

Насколько я Питера помню - ему наоборот, нравилось, что он из любой точки программы имеет доступ к абсолютно всем ее частям.  Я помню себя лет 30 назад - мне это тоже очень нравилось. Более того, когда в 286 процессоре (даже не в 386) был введен защищенный режим памяти - меня это жутко возмутило - то есть как это ? Я, получается, не имею доступ ко всей памяти ? Шо за дела ?  Помню, уже на 386 процессоре, на Win 3.1 получал доступ к "чужой" памяти, в обход системной защиты (путем программирования контроллера прямого доступа к памяти, это мне удалось, но дальше дело не пошло - блоки-то памяти я копировать себе смог, но что они означают - так и не разобрался).

А потом, гораздо позже, когда работал уже на С++ в больших проектах - по достоинству оценил и защищенный режим, и суть инкапсуляции, и преимущества этого самого принципа - "ты имеешь доступ только к тому, что тебе нужно сейчас, и больше ни к чему".

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

Всех этих плюсов нет при "процедурном" подходе и в ситуации "я имею доступ ко всем частям программы из любой точки".

 

Georgiy Merts:

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

Возьмем простой и типичный пример - нужно передать данные из одного объекта в другой, причем эти данные и сама передача между объектами может меняться по ходу разработки кода - то как тогда будете с этим спровляться и пересылать данные через оболочки, которые же сами себе нагородили?

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

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