Вопрос знатокам ООП. - страница 6

Новый комментарий
 
Реter Konow:

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

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

Пример. Найден баг связанный с тем, что значение глобальной переменной явно не соответствует тому, которое должно быть. В проекте уже пару десятков файлов и 100500 строк кода. В скольких местах кода эта переменная меняется уже никто не помнит. Как результат - банка кофе и здоровый сон головой в клаву.

А теперь то же самое, но ООП. Мы же правильно написали код и все поля у нас private. Соответственно на прямую у нас он меняется только в методах класса, а из вне только методом Set. Соответственно вешаем точки останова на метод Set и, сколько у нас там методов в классе, где поле меняется, и спокойно отслеживаем откуда вносятся изменения и где поменяли неправильно.

 
Реter Konow:

 Не было у меня никогда никаких багов связанных с глобальной видимостью переменных. От слова совсем.

даже не знаю как Вас убедить в очевидном, но наверное не стоит, мне же за это не платят?

Вы чего добиваетесь? ну если хотите чтобы Вас похвалили - держите:

Петр! Молодца, так держать!

))))

 
Vladimir Simakov:

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

Пример. Найден баг связанный с тем, что значение глобальной переменной явно не соответствует тому, которое должно быть. В проекте уже пару десятков файлов и 100500 строк кода. В скольких местах кода эта переменная меняется уже никто не помнит. Как результат - банка кофе и здоровый сон головой в клаву.

А теперь то же самое, но ООП. Мы же правильно написали код и все поля у нас private. Соответственно на прямую у нас он меняется только в методах класса, а из вне только методом Set. Соответственно вешаем точки останова на метод Set и, сколько у нас там методов в классе, где поле меняется, и спокойно отслеживаем откуда вносятся изменения и где поменяли неправильно.

Из практики. У меня в проекте более 100 подключенных файлов. В некоторых более 2000 строк кода. Повсюду используются глобальные переменные. Никаких багов связанных именно с их глобальностью никогда не было. Может я просто приспособился?)) Нет их наверное потому, что все переменные на русском и все их названия осмысленны. Никаких sdf или iukj. Поэтому, и ошибок с ними связанных нет. В основном, глобальные переменные использую для флагов глобальных событий, - например открытие окна, нажатие на кнопку мышки, развертка древ.списка и прочее... Также, для фокуса. То есть, мышка путешествует по GUI, и номера всех объектов и элементов и их свойств заносятся в глоб.переменные, а из OnChartEvent вызываются нужные блоки, которые сразу работают с объектами и элементами в фокусе. Очень удобно.
 
Igor Makanu:

даже не знаю как Вас убедить в очевидном, но наверное не стоит, мне же за это не платят?

Вы чего добиваетесь? ну если хотите чтобы Вас похвалили - держите:

Петр! Молодца, так держать!

))))

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

дело не в ООП, а в самих принципах написания кода, я второй раз об этом и вот @Vladimir Simakov выше пример написал

использовать глобальную видимость переменных - да не вопрос, никто не запрещает, это можно делать - но по тихому, пока никто не видит! )))

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

ЗЫ: еще один контрольный выстрел - посмотрите справку MQL, Вы видите что все функции выполнены отдельными законченными самостоятельными блоками? - передал параметры = получил результат! Вы считаете, что программисты Метаквот опять все делают не правильно? нужно использовать некие свободные стили написания функций - тут в глобальной видимости опишем, а вот тут юзер будет вызвать функцию и получит результат! )))) - процедурный стиль (когда каждая подпрограмма - законченный логический блок) это правильный код, пишите коды правильно! а не правильно ... ну оно само "когда нужно по быстрому" придет ;)

 
Реter Konow:
Из практики. У меня в проекте более 100 подключенных файлов. В некоторых более 2000 строк кода. Повсюду используются глобальные переменные. Никаких багов связанных именно с их глобальностью никогда не было. Может я просто приспособился?))

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

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

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

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

void OrdersControl(){
   for (CTrade* it=gPos.Begine();
        it!=NULL;
        it=it.Control()?gPos.Next():gPos.Delete());}

, где gPos - это CList<CTrade> gPos

CList и CTrade не из стандартной библиотеки.

CTrade - наследует от моего же библиотечного CPosition.

Собственно ниже весь CTrade, который нужен только для обеспечения удобочитаемости кода проекта:

#include "..\Header.mqh"

#ifndef _C_TRADE_
#define _C_TRADE_

#include "..\..\..\Shared Projects\mqlLib\Objects\Trade\CPosition.mqh"

class CTrade:public CPosition
  {
public:
                     CTrade(double mVolume,int mDirect,double mSL,double mTP);
   bool              Control() {return !(CPosition::Control()&TRADE_FINISH);}
  };
//-------------------------------------------------------------------------------------
void CTrade::CTrade(double mVolume,int mDirect,double mSL,double mTP):
   CPosition(NULL,
             mDirect>0?OP_BUY:OP_SELL,
             mVolume,
             0.0,
             mSL,
             mTP)
{}

#endif
Вся реализация работы с ордерами/позициями скрыта в кросплатформенном библиотечном файле CPosition.
 
Реter Konow:
Спасибо всем за участие в обсуждении. Я попробую вникнуть в ООП, чтобы по настоящему сравнить возможности двух подходов. Заинтересовала иерархия, которую может обеспечить ООП, и если польза от нее не будет погребена под его синтаксисом, непременно возьму на вооружение.

Ютуб в помощь. Там много чего. Особенно на английском, с которым ты дружишь.


Не пожалей, Петр, 45 минут. На начальном этапе очень важно понять, о чем этот товарищ толкует. Возможно многие с ним будут спорить, но в целом он прав:


 
Nikolai Semko:

Ютуб в помощь. Там много чего. Особенно на английском, с которым ты дружишь.


Не пожалей, Петр, 45 минут. На начальном этапе очень важно понять, о чем этот товарищ толкует. Возможно многие с ним будут спорить, но в целом он прав:


Спасибо, Николай. Буду смотреть.
12345678910111213...55
Новый комментарий
Причина обращения: