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

 
Igor Makanu:

сама концепция ООП подразумевает как раз и не писать - Вы не должны знать реализацию метода (в Вашем примере return(SymbolSelect(m_name,select)))

представьте, что вместо этой строчки:

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

Пусть Ваша задача как раз и сводится всего к использованию одного метода уже готового решения в виде класса - Вы создаете экземпляр класса (обьект) и используете готовый метод Select(const bool select)

Если дальше не предполагается выполнять еще такие операции, освободим память = уничтожим обьект

Пусть Ваша задача сводится к отображению кнопки по нажатию которой Вы включаете / отключаете символ в обзоре рынка ---> создаете свой класс и инкапсулируете в него уже готовый класс кнопка и готовый класс CSymbolInfo - все задача решена

Парадигме ООП дает лишь общие сведения что можно делать с классом - не хотите инкапсулировать CSymbolInfo - ну возьмите наследуйте от него свой класс

Верю, не понимаю и не принимаю. Вот когда будет конкретная задача что без всех этих наворотов не обойтись, тогда придёт "просветление в уму" и понимание. А так, пока с моей точки зрения просто модные навороты не всегда оправданные. Не всегда не означает, что никогда. Я с удовольствием пользуюсь классом Ctrade но такими как указал выше не принимаю. Если описание функции SymbolSelect в документации найти не составляет труда, то в СБ найти описание для меня уже определённые трудности.

Igor Makanu:

ЗЫ: если "на пальцах", то суть ООП - это быстрое решение поставленной задачи без знания реализации

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

Ну можно понять если в одном проекте нужно иметь несколько экземпляров объекта. Но ведь пока я не встречал таких реализаций, за исключением упомянутой ранее демонстрации Артёма. В том случае понятно, что так лучше, легче, проще, но до полного понимания я не дошёл именно по причине ненадобности, отсутствия задачи. Ради единичного использования функции языка mql5 наворачивать объект не имеет смысла. Вот так я рассуждаю.

 
Alexey Viktorov:

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

искать в документации, все что выкладывают публично - сопровождают мануалами, так сказать этика

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

 
Igor Makanu:

суть ООП - это быстрое решение поставленной задачи без знания реализации

Можно вызвать некую функцию, передав в неё структуру с данными, и получить столь же быстрое решение без знания реализации этой функции.
 
Alexey Navoykov:
Можно вызвать некую функцию, передав в неё структуру с данными, и получить столь же быстрое решение без знания реализации этой функции.

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

ЗЫ: ну и сама логика разворачивания обьекта через конструкторы довольно удобная штука

 
Реter Konow:

Класс - это описание объекта. Хорошо. Содержит свойства объекта и его функционал. Ок. Все это упорядочено, открыто или защищено.

Тогда САМ ОБЪЕКТ - за кадром. Он в контексте класса. В контексте его названия и описания. То есть в ООП, Объект, - именнованный комплекс атрибутов (не только свойств, но и функциональных элементов - методов), но более упорядоченный и инкапсулированный, чем у меня. (Так мне понятнее).

Петр, погуглите наконец про классы, что они из себя представляют в контексте выделения памяти, вызова методов, то есть, во что это все компилятор преобразует. Большая часть вопросов сама по себе испарится после этого.
 
Petros Shatakhtsyan:

Чтобы всё было понятно, надо читать книги. Хотя бы VC++ за 21 день.

Советую на первое время использовать MFC, создавать windows приложение на основе CDialog, создавая всякие объекты и посмотреть как легко они управляются.

После этого будете выбросить вашу затею. К сожалению.

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

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

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

Но, ООП мне очень интересен. Буду от него учится.))
 
Vladimir Simakov:
Петр, погуглите наконец про классы, что они из себя представляют в контексте выделения памяти, вызова методов, то есть, во что это все компилятор преобразует. Большая часть вопросов сама по себе испарится после этого.
Хорошо. Обязательно погуглю.
 

Немало размышлял над концепцией ООП и вот что:

Абстрагируемся от синтаксиса и технических терминов, оставив понятия  "Класс", "Объект", "Свойство", "Инкапсуляция", "Полиморфизм", "Наследование". Опишу философский "корень" концепции.

Действительность воспринимается сознанием через призмы "Пространства", "Времени" и "Материи" (так работают органы чувств), а  "Объект" - это дискретный результат их непрерывного взаимодействия.

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

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

Как мы видим, "древовидность" в ООП повсюду. Какие бы схемы не придумывали, а все равно получиться "дерево".)) Но, это и правильно, ведь мы просто копируем собственные бессознательные паттерны в работе с информацией.

 
Реter Konow:

Немало размышлял над концепцией ООП и вот что:

...

Жесть.

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

 
Artyom Trishkin:

...

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


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

Причина обращения: