Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В функционально-процедурном программировании, проблем с доступом описанных тобой не существует. Без перегрузки функций, без полей и обьектов, без указателей и прочего, когда у тебя только одна память для всех глобальных переменных к которым ты можешь обращатся отвсюду, как может вызватся не та функция? Какие ошибки связанные с доступом могут возникнуть? Да и запоминать все в разы легче.
Да ошибка простейшая - обратиться не к той переменной, содержащей близкое по величине значение.
Такая ошибка может быть не выявлена очень долго, но, по закону подлости - "вылезет" она как раз в то время, когда безошибочная работа в этом месте была бы очень нужна !
И вычислить ее будет ох, как трудно... Ты пытаешься понять, почему эксперт закрыл сделку по хорошему тренду, когда ТС - никак не должна была ее закрыть - и не можешь. Все вроде работает верно.
Это как раз одни из наиболее неприятных ошибок - неинициализация переменных, или обращение не к той, но близкой по значению. И чем больше переменных доступно в той или иной части программы - тем больше вероятность такой ошибки.
Да, конечно, если у тебя глобально доступно графическое ядро, а ты в данном месте работаешь с ордерами - то обратиться не к той переменной, действительно, сложно. Но, вот в более раннем блоке, там, где ты определяешь необходимость открытия ордера, для чего обращаешься к индикаторам, и, возможно, действиям пользователя - перепутать переменные уже вполне реально.
Ты просто всю структуру системы - держишь в памяти, и не видишь тут никаких проблем. Если структур будет побольше, что периодически из памяти будут выветриваться важные тонкости - ты сам придешь к выводу, что глобальный доступ - это источник проблем, и надо всемерно избегать его использование. И что код следует писать так, чтобы помнить надо было как можно меньше. В идеале - вобще ничего не держать в памяти - каждый блок имеет название, говорящее о его функции, на входе он получает данные, необходимые и достаточные для этой функции, остается только реализовать функцию, вобще никаких других знаний "извне" не привлекая.
Да ошибка простейшая - обратиться не к той переменной, содержащей близкое по величине значение.
Такая ошибка может быть не выявлена очень долго, но, по закону подлости - "вылезет" она как раз в то время, когда безошибочная работа в этом месте была бы очень нужна !
И вычислить ее будет ох, как трудно... Ты пытаешься понять, почему эксперт закрыл сделку по хорошему тренду, когда ТС - никак не должна была ее закрыть - и не можешь. Все вроде работает верно.
Это как раз одни из наиболее неприятных ошибок - неинициализация переменных, или обращение не к той, но близкой по значению. И чем больше переменных доступно в той или иной части программы - тем больше вероятность такой ошибки.
Да, конечно, если у тебя глобально доступно графическое ядро, а ты в данном месте работаешь с ордерами - то обратиться не к той переменной, действительно, сложно. Но, вот в более раннем блоке, там, где ты определяешь необходимость открытия ордера, для чего обращаешься к индикаторам, и, возможно, действиям пользователя - перепутать переменные уже вполне реально.
Ты просто всю структуру системы - держишь в памяти, и не видишь тут никаких проблем. Если структур будет побольше, что периодически из памяти будут выветриваться важные тонкости - ты сам придешь к выводу, что глобальный доступ - это источник проблем, и надо всемерно избегать его использование. И что код следует писать так, чтобы помнить надо было как можно меньше. В идеале - вобще ничего не держать в памяти - каждый блок имеет название, говорящее о его функции, на входе он получает данные, необходимые и достаточные для этой функции, остается только реализовать функцию, вобще никаких других знаний "извне" не привлекая.
Блин, ну как можно обратится не к той переменной, если они все по разному называются? Как может вызватся не та функция, если у нее уникальное имя и перегрузки нет? Внутри массива ядра все индексы ячеек названы дефайнами человеческими словами. Что здесь можно перепутать? Пойми, проблем о которых ты говоришь не существует ВООБЩЕ.
В памяти я держу только структуру ядра, которая очень проста. Также я знаю перечень свойств обьектов. Свойства у всех объектов одинаковые, только значения разные. Всего 140 свойств, но в памяти держу только самые важные, штук 30. Остальные вспоминаю когда нужно. Захожу для это в файл с дефайнами и смотрю полный список свойств. Ничего сложного. Глобальные переменные в фокусе, как например "ОБЬЕКТ" или "ОКНО" вообще запонинать не нужно. И перепутать ни с чем невозможно.
У моих переменных осмысленные названия на русском языке. Перепутать что либо можно только после бурной вечеринки.))Мои глобальные переменные - это переменные используемые в фокусе, который "нацелен" на ядро и перемещается по нему при перемещении курсора.
Например: переменная "ОКНО" постоянно несет в себе номер того окна, на котором находится курсор. Переменная "ОБЪЕКТ" - номер того объекта на котором находится курсор.
Через них я обращаюсь к ядру, - к конкретному окну, объекту и свойству в ядре - G_CORE[ОКНО][ОБЪЕКТ][_NAME] или G_CORE[ОКНО][ОБЪЕКТ][_OBJECT_GROUP]. В любой функции, если мне нужна Х-координата объекта то я ее беру из G_CORE[ОКНО][ОБЪЕКТ][_X], если высота объекта - из G_CORE[ОКНО][ОБЪЕКТ][_Y_SIZE] и тд...
Всего у меня около сотни отдельно объявленных глобальных переменных, но в глобальном массиве ядра их тысячи, ведь каждая ячейка массива - это переменная. Однако, управлятся с этим количеством переменных очень легко, потому что они упорядочены. Каждое окно в ядре - это поле массива, каждый ряд - это один объект, который состоит из 140 свойств. Элементы в данном случае, - это наборы объектов. У каждого элемента есть главный объект, в котором записаны главные свойства всего элемента. Объекты принадлежащиее конкретному элементу связаны между собой специальными индексами, поэтому какой бы объект не попал в фокус, элемент которому он принадлежит тоже попадает в фокус. Также и канвас на котором он нарисован. Благодаря четкой архетиктуре ядра и прямому доступу из любой функции, я могу управлять тысячами переменных которые из себя представляют ячейки массива ядра, ничего не забывая и свободно ориентируясь.
Совершенно бессмысленный разговор: нет критерия отнесения кода к "хорошему" или "плохому". Именно поэтому не ясно про ООП.
Для меня таким критерием является НАГЛЯДНОСТЬ кода, которая проявляется в том, что автор или сторонний человек через довольно большой промежуток времени сможет прочесть код и его использовать для модификации, поиска багов.....
Вот выше Федосеев заменил переключатель ООП. Этот конкретный пример, может быть неудачный, для меня это доказательством порочности ООП: наглядный код с переключателем из 100 позиций заменен одной строкой. Чтобы понять эту строку необходимо куда-то лезть. Для меня это не допустимо.
Второй пример выше George Merts
Когда наглядный код после отладки был заменен на НЕ наглядный. По моему критерию качественный код (легко читался) был заменен на недопустимый для меня.
Поэтому у меня вопрос ко всем сторонникам ООП: становится ли программа более наглядной при применении ООП, а пример, приведенный Федосеевым по переключателю является неудачным, или же наоборот, пример Федосеева очень точно характеризует ООП и ООП практически всегда ведет к потере наглядности?
Ну с СС все ясно. Все, что выше уроdня его понимания, является ненаглядным. Зато он знает букву R ))))))))))))))
Ну с СС все ясно. Все, что выше уроdня его понимания, является ненаглядным. Зато он знает букву R ))))))))))))))
К ООП добавлю еще и китайский, можно японский...
Зачем ООП? ЧТО будет лучше?
Наглядность - это упрощение отладки, модификации. Наглядность проистекает из тщательного проектирования программы, из структурирования на ФУНКЦИИ, а не на ОБЪЕКТЫ, потому что весь мир устроен на действиях над объектами, но не наоборот.
Когда разбивка на функции вытекает из последовательности преобразования входных данных в выходные. Например, преобразование котира на входе в выходные данные BUY|SELL возможно только через указание ДЕЙСТВИЙ.
Именно так устроено мышление человека.
ПС.
По поводу Вашего замечания про R.
Желаете поерничать?
Отвечаю крайне редко, но могу и ответить
Блин, ну как можно обратится не к той переменной, если они все по разному называются? Как может вызватся не та функция, если у нее уникальное имя и перегрузки нет? Внутри массива ядра все индексы ячеек названы дефайнами человеческими словами. Что здесь можно перепутать? Пойми, проблем о которых ты говоришь не существует ВООБЩЕ.
Ну, вот у меня была пара таких случаев.
Наиболее часто ошибки подобного рода возникают, когда ты копируешь кусок кода из другого места и "поправляешь" его, в соответствии с текущим блоком. Если у тебя глобальный доступ - ты вполне можешь пропустить изменение одной из переменных. Если же тебе доступно только лишь то, с чем ты в данном случае должен работать - то после копирования - компилятор сам тебе выдает список всех переменных и мест, которые необходимо изменить.
Реter Konow:
В памяти я держу только структуру ядра, которая очень проста. Также я знаю перечень свойств обьектов. Свойства у всех объектов одинаковые, только значения разные. Всего 140 свойств, но в памяти держу только самые важные, штук 30. Остальные вспоминаю когда нужно. Захожу для это в файл с дефайнами и смотрю полный список свойств. Ничего сложного.
30 свойств ??? Ну, вот, для меня это неприемлемо. Не то, чтобы я не мог их запомнить, но надеяться на память я не хочу. Куда лучше, когда в каждом блоке - всегда ты имеешь именно те переменные, которые в этом блоке должны обрабатываться, и доступа к другим - просто нет.
Но, это меня напрягает необходимость помнить... А раз тебе это несложно - вполне объяснимо, что лишних ООП-телодвижений делать смысла нет.
Ну, вот у меня была пара таких случаев.
Наиболее часто ошибки подобного рода возникают, когда ты копируешь кусок кода из другого места и "поправляешь" его, в соответствии с текущим блоком. Если у тебя глобальный доступ - ты вполне можешь пропустить изменение одной из переменных. Если же тебе доступно только лишь то, с чем ты в данном случае должен работать - то после копирования - компилятор сам тебе выдает список всех переменных и мест, которые необходимо изменить.
30 свойств ??? Ну, вот, для меня это неприемлемо. Не то, чтобы я не мог их запомнить, но надеяться на память я не хочу. Куда лучше, когда в каждом блоке - всегда ты имеешь именно те переменные, которые в этом блоке должны обрабатываться, и доступа к другим - просто нет.
Но, это меня напрягает необходимость помнить... А раз тебе это несложно - вполне объяснимо, что лишних ООП-телодвижений делать смысла нет.
Ну, говоря откровенно я помню очень много всего. Чего стоят только одни абрравиатуры привязок обьектов _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C и т.д... каждая определяет положение одного обьекта относительно другого. Они находятся в параметрах A1,B1,C1,A2,B2,C2,A3,B3,С3,А4,В4,С4,А5... Также помню пару десятков названий категорий и подкатегорий обьектов, еще пару десятков свойств окон (их более 100). В блоке построения например, находятся десятки функций, и занимают более 4000 строк кода. Приходится ориентироватся и помнить очень много. Но запоминание возникает от длительной практики, не сразу, а постепенно. Раньше у меня голова пухла от количества сущностей и размеров кода, но потом все утрамбовалось и стало просто.
Ну, говоря откровенно я помню очень много всего. Чего стоят только одни абрравиатуры привязок обьектов _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C и т.д... каждая определяет определенное положение одного обьекта к другому, находятся в параметрах A1,B1,C1,A2,B2,C2,A3,B3,С3,А4,В4,С4,А5... Также помню пару десятков названий категорий и подкатегорий обьектов, еще пару десятков свойств окон (их более 100). В блоке построения например, находятся десятки функций, и занимают более 4000 строк кода. Приходится ориентироватся и помнить очень много. Но запоминание возникает от длительной практики, не сразу, а постепенно. Раньше у меня голова пухла от количества сущностей и размеров кода, но потом все утрамбовалось и стало просто.
отвлечься, забыв обо всём уехать на месяц в отпуск, не думая о коде. После приехать, увидеть все эти а1, б1 и т.д. и забиться в истерике :)
отвлечься, забыв обо всём уехать на месяц в отпуск, не думая о коде. После приехать, увидеть все эти а1, б1 и т.д. и забиться в истерике :)
Для примера, - вот что представляет из себя элемент "чекбокс" в прото-ядре: