ООП - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как вернуть ссылку в параметрах функции?
Такой код вызывает проблемы:
CMy* obj; // global bool func(CMy* obj) { ... obj = new CMy(); ... }Invalid pointer access при попытке работы потом с obj.
Попробовал добавить &.
Так работает. Возврат ссылки в параметрах функции в документации не нашел.
По аналогии в C++ нашел такую тему: http://stackoverflow.com/questions/5286453/returning-a-pointer-as-a-function-parameter
Но у вас ** не работает. *& вместо неё?
5.00.630 x64
Возврат ссылки в параметрах функции в документации не нашел.
Как вернуть ссылку в параметрах функции?
Такой код вызывает проблемы:
Invalid pointer access при попытке работы потом с obj.
Попробовал добавить &.
Так работает. Возврат ссылки в параметрах функции в документации не нашел.
По аналогии в C++ нашел такую тему: http://stackoverflow.com/questions/5286453/returning-a-pointer-as-a-function-parameter
Но у вас ** не работает. *& вместо неё?
5.00.630 x64
ИМХО (давно было)
Через аргументы указатель передать нельзя, можно создать ссылку. К ссылке нельзя привязать новый экземпляр класса. Остается такой вариант:
CMy* func() { ... CMy* obj; obj = new CMy(); return(obj); ... }Я - сторонник ООП, так как для себя понял удобство программирования снизу вверх. От интерфейсов взаимодействия объектов к реализации классов.
ИМХО (давно было)
Через аргументы указатель передать нельзя, можно создать ссылку. К ссылке нельзя привязать новый экземпляр класса. Остается такой вариант:
Я неправильно обозначил вопрос.
Передача указателя по ссылке. Меня интересует, можно ли использовать вариант с *&, не прикроют ли в следующих версиях? В C++ такая конструкция, вроде бы, законна.
Вы про это: Справочник MQL5 / Основы языка / Типы данных / Ссылки. Модификатор & и ключевое слово this ?
Хотелось бы, чтобы там была нужная информация...
В статье
https://www.mql5.com/ru/docs/basis/function/ParameterPass
тоже можно добавить информации по работе с объектами.
А разве интерфейс это не внешнее по отношению к классу?
А что это меняет для объектов? Интерфейс в данной интерпретации это тип данных, потому что его описание достаточно четко определяет свойства объектов. И, по сути, он задает внешнее поведение объектов.
В приведенных мной материалах противники ООП упоминали, что нельзя создать структуру классов сразу до конца, не реализовав алгоритм, поэтому в ООП среде так часто практикуется рефакторинг и поэтому классы тормозят разработку с их вечным переделываением. И это действительно так. Реализуя что-то новое и не понимая во что это может вылится, классы придется переделать и не раз.
Создание грамотной архитектуры классов является камнем преткновения для начинающих. По сути, смыслом ООП программирования является написание своего "языка", языка на котором удобно и быстро творить в дальнейшем. Интерфейс это суть язык который проектируется под задачи. Интерфейс, по хорошему, не нужно понимать как конструкцию "типа" класса, как контракт для класса который нужно исполнить в коде(в MQL его нет и роль интерфейса с натяжкой могут выполнять виртуальные методы).
К примеру, можно создать "язык" для создания новых экспертов, который позволит в несколько строчек собрать общую схему работы эксперта из объектов. Сигналы и условия можно использовать готовые, а можно разрабатывать от случая к случаю свои классы сигналов, по аналогии и создать свою библиотеку. Такую возможность предоставляет Мастер MQL5.
Часто, схема построения приложения уже придумана и "ООП программирование" по сути сводится к использованию существующих классов с ограниченными степенями свободы для написания своего функционала - это удобно. Поэтому так популярны фреймворки. Они избавляют от лишних проблем и головной боли при разработке архитектуры приложения. По сути, написание что-то своего, это создание класса наследника одного из классов фреймворка, и написание реализации в нем определенных колбэк методов, которые уже встроены в общую логику приложения (OnInit, OnTick тому пример).
...
Создание грамотной архитектуры классов является камнем преткновения для начинающих. По сути, смыслом ООП программирования является написание своего "языка", языка на котором удобно и быстро творить в дальнейшем. Интерфейс это суть язык который проектируется под задачи. Интерфейс, по хорошему, не нужно понимать как конструкцию "типа" класса, как контракт для класса который нужно исполнить в коде(в MQL его нет и роль интерфейса с натяжкой могут выполнять виртуальные методы).
...
Скорее смыслом ООП является написание своей архитектуры. Как только у нас появляется четкая, ясная, интуитивно понятная архитектура, все сразу встает на свои места и не сложность проекта ни его объем уже не являются здерживающими факторами. Однако что бы добиться этой самой четкой архитектуры приходится раз за разом переписывать классы постепенно приближаясь к этому вначале смутному идеалу.
Очень здравые мысли озвучиваете господа, но как бы найти эту свою желанную архитектуру?!) Вечно что то приходится менять и переделывать и кажется этому нет предела)).
Сам ООП использую относительно недавно и классы больше как отдельные части без наследования. Вот и назрели несколько вопросов по наследованию, буду благодарен за подсказку.
1. Класс потомок может пользоваться членами и методами родителя, а родитель может так же пользоваться методами своих наследников? Или нужно только явно создавать экземпляр класса наследника, чтобы получить доступ к его методам? Тогда следующий вопрос как это делать если эти классы в разных файлах, получается они должны ссылаться друг на друга.
2. Или это в принципе не правильных подход в ООП когда родителю нужно использовать методы наследников? Сейчас у меня классы не зависимы, и методы вызываются явно через экземпляры, но все равно выстраивается иерархия, опять же вопрос в эффективности такого подхода.