Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
сама концепция ООП подразумевает как раз и не писать - Вы не должны знать реализацию метода (в Вашем примере return(SymbolSelect(m_name,select)))
представьте, что вместо этой строчки:
нужно выполнить очень много запросов, различных проверок и т.п. - на это у Вас уйдет время на написание собственной библиотеки и на само изучение материала
Пусть Ваша задача как раз и сводится всего к использованию одного метода уже готового решения в виде класса - Вы создаете экземпляр класса (обьект) и используете готовый метод Select(const bool select)
Если дальше не предполагается выполнять еще такие операции, освободим память = уничтожим обьект
Пусть Ваша задача сводится к отображению кнопки по нажатию которой Вы включаете / отключаете символ в обзоре рынка ---> создаете свой класс и инкапсулируете в него уже готовый класс кнопка и готовый класс CSymbolInfo - все задача решена
Парадигме ООП дает лишь общие сведения что можно делать с классом - не хотите инкапсулировать CSymbolInfo - ну возьмите наследуйте от него свой класс
Верю, не понимаю и не принимаю. Вот когда будет конкретная задача что без всех этих наворотов не обойтись, тогда придёт "просветление в уму" и понимание. А так, пока с моей точки зрения просто модные навороты не всегда оправданные. Не всегда не означает, что никогда. Я с удовольствием пользуюсь классом Ctrade но такими как указал выше не принимаю. Если описание функции SymbolSelect в документации найти не составляет труда, то в СБ найти описание для меня уже определённые трудности.
ЗЫ: если "на пальцах", то суть ООП - это быстрое решение поставленной задачи без знания реализации
В таком случае вместо знания реализации надо знать как вызвать нужный метод, где его искать и прочее. Это что? своеобразный язык в языке программирования?
Ну можно понять если в одном проекте нужно иметь несколько экземпляров объекта. Но ведь пока я не встречал таких реализаций, за исключением упомянутой ранее демонстрации Артёма. В том случае понятно, что так лучше, легче, проще, но до полного понимания я не дошёл именно по причине ненадобности, отсутствия задачи. Ради единичного использования функции языка mql5 наворачивать объект не имеет смысла. Вот так я рассуждаю.
В таком случае вместо знания реализации надо знать как вызвать нужный метод, где его искать и прочее. Это что? своеобразный язык в языке программирования?
искать в документации, все что выкладывают публично - сопровождают мануалами, так сказать этика
это не стиль, а парадигма! - концепция, правила хорошего тона, никто не заставляет так писать, но почему то это самый распространенный стиль
суть ООП - это быстрое решение поставленной задачи без знания реализации
Можно вызвать некую функцию, передав в неё структуру с данными, и получить столь же быстрое решение без знания реализации этой функции.
да, но на этом Ваш метод будет ограничен, в ООП Вы можете еще и наследоваться - даже не зная реализацию и дописать под свою задачу, первое что приходит на ум - Button с скругленными краями, в сети примеров вагон
ЗЫ: ну и сама логика разворачивания обьекта через конструкторы довольно удобная штука
Класс - это описание объекта. Хорошо. Содержит свойства объекта и его функционал. Ок. Все это упорядочено, открыто или защищено.
Тогда САМ ОБЪЕКТ - за кадром. Он в контексте класса. В контексте его названия и описания. То есть в ООП, Объект, - именнованный комплекс атрибутов (не только свойств, но и функциональных элементов - методов), но более упорядоченный и инкапсулированный, чем у меня. (Так мне понятнее).
Чтобы всё было понятно, надо читать книги. Хотя бы VC++ за 21 день.
Советую на первое время использовать MFC, создавать windows приложение на основе CDialog, создавая всякие объекты и посмотреть как легко они управляются.
После этого будете выбросить вашу затею. К сожалению.
Ну, это вряд ли. Дело в том, что концептуальных различий моего подхода и ООП я нашел очень мало. Мой подход тоже объектно ориентированный. Объекты инкапсулируются в ядре и имеют совершенно конкретное представление. Они связываются между собой указателями, образуя комплексы - элементы, окна... Если выйти за рамки графики и создать иную форму ядра, которое будет включать в себя больше разнообразия, получится не хуже чем в ООП.
Разница подходов в стиле написания кода, синтаксисе и методах распределения функционала. В моем подходе функционал стремиться к объединению, в ООП - к дроблению. При этом, объединение функционала гарантированно повышает эффективность системы и малое кол-во синтаксиса, а дробление функционала - облегчает переносимость кода. Дает возможность подключения модулей. В общих чертах, таковы различия.
Конечно, мой подход пока не обладает такой широкой "объектностью". Но, у меня уже есть мысли как это исправить. Ядро имеет один тип и это ограничивает хранимые в нем свойства, но ядро не обязательно должно быть одной матрицей. Это может быть комплекс ядер. Главное преимущество - цифровое представлении объектов, не требующее длинного описания, доп.синтаксиса и дробления функционала.
Но, ООП мне очень интересен. Буду от него учится.))Петр, погуглите наконец про классы, что они из себя представляют в контексте выделения памяти, вызова методов, то есть, во что это все компилятор преобразует. Большая часть вопросов сама по себе испарится после этого.
Немало размышлял над концепцией ООП и вот что:
Абстрагируемся от синтаксиса и технических терминов, оставив понятия "Класс", "Объект", "Свойство", "Инкапсуляция", "Полиморфизм", "Наследование". Опишу философский "корень" концепции.
Действительность воспринимается сознанием через призмы "Пространства", "Времени" и "Материи" (так работают органы чувств), а "Объект" - это дискретный результат их непрерывного взаимодействия.
Многообразие форм взаимодействия порождает многообразие объектов, которые "насаждаются" бессознательным субъекта на некий "каркас". Этот каркас имеет ветвистую, каскадную структуру и "встроен" в бессознательное, являясь одним из его "архетипов". Каркас принимает на себя новые и новые объекты (информацию о них), которые распределяются по его структуре. Отсюда и берет начало концепция ООП. Это осознанное распределение и связывание объектов имитирующее "алгоритм" бессознательного. Освоивший методы собственного мышления субъект, способен моделировать его работу в механизме, являющимся "калькой" мозга - компьютере. Пусть компьютер лишь жалкая пародия на мозг, но ведь и сам человек воспринимает лишь тени объективного мира. Каскадный, ветвистый архетип, это "паттерн" распределения объектов, свойств, процессов и всей информации в целом, внутри нашей памяти. Это биологический инструмент упрощения восприятия действительности, структурирующий модель окружающего мира. Это нам дано от Природы. Осознание собственного "природного" (т.е. бессознательного) механизма обработки информации - уровень самосознания, необходимый для использования ООП.
Рассмотрим этот неявный, биологической, "древовидный" архетип, упрощающий запоминание, обучение и восприятие, в контексте его "искуственного" применения. В ООП, мы "продуцируем" объекты инкапсулируя их описания в классах, где устанавливаем их свойства и значения. Взаимосвязи объектов отражаются в их классификации, и реализуются через наследование свойств и методов от глобальных к частным. Практически, это выглядит так: каждый частный объект - просто объект и следовательно, имеет все свойства просто объекта + свои частные свойства. Производные от него объекты будут обладать его частными свойствами как своими общими, но будут иметь свои частные свойства. Далее, цепочка может идти и ветвиться бесконечно. То же самое, с методами объектов. Метод отражает действие, взаимодействие, процесс, смену состояний. Методы объектов распределяются от общих к частным как и свойства. Если есть некий общий процесс, то каждая его дискретная форма будет обладать его свойствами и своими собственными. А это полиморфизм. То есть, в отличии от перегрузки, полиморфизм предоставляет иную частную реализацию базовой функции при сохранении ее базового механизма. Это - "функциональное" наследование.
Как мы видим, "древовидность" в ООП повсюду. Какие бы схемы не придумывали, а все равно получиться "дерево".)) Но, это и правильно, ведь мы просто копируем собственные бессознательные паттерны в работе с информацией.
Немало размышлял над концепцией ООП и вот что:
...Жесть.
Пётр, вам срочно в политику нужно идти. Тут такие таланты не востребованы - сказать много, умно и непонятно, и ни о чём.
...
Лучше понимая принцип работы нашего сознания и бессознательного, мы сможем воспроизвести механизм их работы в компьютере. Я просто отстранился от технических деталей и рассмотрел корень концепции.