Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как сделать что бы t видел только func_2 и func_4 ?
Объявить функции, которые ты не хочешь , чтобы были доступны наследнику - в секции private. Хотя, правильность не давать доступ к функциям наследника - на мой взгляд, под вопросом. Лично я считаю, что наследнику всегда должен быть доступен весь класс - то есть, все данные и функции класса должны быть либо в секции public, либо в секции protected.
И насчет protected-наследования - вопрос также спорный.
Лично я предпочитаю наследование делать всегда public, а те вещи, которые не должны наследоваться - выносить в отдельный protected член класса (композиция, а не наследование)
И вобще, насчет области видимости - я предпочитаю интерфейсы - специальные классы с полностью виртуальными функциями (приравненными нулю).
Например, у меня есть интерфейс :
Это - переносимый платформонезависимый интерфейс.
В шаблоне советника есть функция:
CTradePositionI* GetTradePosition(symbol,magic);
Которая при вызове возвращает именно этот интерфейс. Как видишь - все функции в интерфейсе нулевые, и к реализации пользователь не имеет никакого доступа. Нужна позиция - запрашиваешь этот интерфейс, и у него можешь выяснить, сколько компонент в позции, и запросить каждую компоненту в отдельности. Причем, для МТ4 - реально это класс CMT4PositionInfo (на прошлой странице я его приводил), а для МТ5 - совсем другой класс CMT5PositionInfo. Однако, оба этих класса - поддерживают данный виртуальный интерфейс. И пользователю не надо знать, на какой платформе он работает. Функция вернет указатель на один из этих классов, в виде виртуального интерфейса, общего для них обоих.
Причем, по запросу компоненты - опять-таки, получаешь не конкретный ордер МТ4 или позицию МТ5 (реально - именно они хранятся в объекте позиции), а виртуальный интерфейс:
Тут же есть интерфейс и исторической позиции - он тоже виртуальный, есть класс истории, который возвращает компоненты позиции в истории - в виде вот этого виртуального интерфейса.
На мой взгляд, наиболее ценным в этом подходе является то, что блоки программы - полностью отделены друг от друга, взаимодействие осуществляется исключительно через виртуальные интерфейсы, при изменениях и модификациях - прочие блоки совершенно не затрагиваются. Более того, реально существует четыре различных класса - ордер МТ4, исторический ордер МТ4, позиция МТ5, историческая позиция МТ5 - которые существенно различаются по структуре (например, в позиции МТ5 есть списки ордеров и сделок, а в ордере МТ4 этого нет), но для пользователя - это совершенно один и тот же интерфейс. Собственно, я вижу в этом как раз идею ООП - инкапсуляцию.
Кроме того - все реальные классы, являющиеся наследниками CTradePosComponentI, одновременно являются и наследниками CMyObject, и CObject - как раз используется CArrayObj, чтобы сложить все ордера МТ4 или позиции МТ5 в массив, и иметь при этом сортировку, в зависимости от ключа.
И вобще, насчет области видимости - я предпочитаю интерфейсы - специальные классы с полностью виртуальными функциями (приравненными нулю).
Например, у меня есть интерфейс :
Сейчас есть интерфейсы, не помню, когда их ввели
***
Сейчас есть интерфейсы, не помню, когда их ввели
***
традиционно "немного через зад" при помощи костылей и подпорок - "интерфейс это такой сугубо виртуальный класс без полей, конструкторов и деструкторов" :-)
а по логике вещей должна быть ключевое слово implements и допустимо множественные (класс может имплементировать множество интерфейсов) и реализацию интерфейсов нельзя путать с наследованием, миксами и делегатами..
традиционно "немного через зад" при помощи костылей и подпорок - "интерфейс это такой сугубо виртуальный класс без полей, конструкторов и деструкторов" :-)
а по логике вещей должна быть ключевое слово implements и допустимо множественные (класс может имплементировать множество интерфейсов) и реализацию интерфейсов нельзя путать с наследованием, миксами и делегатами..
В этом и есть вся суть, минимум для наследования. А от делегатов а-ля C# я бы не отказался :))
Считаю класс CObject - очень даже правильным и нужным классом.
...
CObject *m_prev;
CObject *m_next;
Вот - это как раз указатели, которые используются классом CList - объекты "цепляются" один за другой, что позволяет очень просто организовать списки любых объектов, проснаследованных от CObject.
Соответственно, в классе есть public-методы получения предыдущего и следующего объекта в списке.
Имхо, это не правильная концепция. Если пользователь захочет поместить один объект одновременно в несколько списков (почему бы и нет?), то выйдет облом. Поэтому для списков нужны специальные объекты-контейнеры, в которые помещается наш указатель, и все списочные манипуляции проводятся именно с этими контейнерами. Т.е. вот в них и должны содержаться указатели *prev и *next. А тут намешали всё в кучу, и теперь каждый объект вынужден хранить 2 лишних указателя (16 байт), даже если они никогда не понадобятся.
Поэтому я лично никогда не пользуюсь этим нелепым CObject. У меня своя реализация базового объекта, там никаких указателей, но зато есть счётчик ссылок - вот это реально нужная вещь. Соответственно операции присвоения и удаления указателей делаю через специальные функции.
традиционно "немного через зад" при помощи костылей и подпорок - "интерфейс это такой сугубо виртуальный класс без полей, конструкторов и деструкторов" :-)
а по логике вещей должна быть ключевое слово implements и допустимо множественные (класс может имплементировать множество интерфейсов) и реализацию интерфейсов нельзя путать с наследованием, миксами и делегатами..
Множественное наследование почему-то не в почете. Хотя, мне лично оно кажется очень даже полезной штукой.
Никаких "костылей и подпорок" я в этом определении не вижу. Все верно - интерфейс - это сугубо виртуальный класс. Главная его задача - определить протокол взаимодействия. С чем он вполне себе справляется, на мой взгляд.
Сейчас есть интерфейсы, не помню, когда их ввели
Да, я про них знаю, все верно, интерфейс - это как раз то, что надо, но придется изменять отлаженный код - кто его знает, какие подводные камни при этом появятся. А плюсов при этом немного. Я и так использую чисто виртуальные классы как интерфейсы. Плюс - у меня есть специальное поле "идентификатор класса", чтобы при преобразовании указателя - имелась бы возможность выяснить, на какой именно реальный объект он указывает.
P.S. Ага ! Сейчас попробовал заменить один из своих виртуальных классов на интерфейс - не вышло, как раз из-за CObject'а ! Если класс наследуется от интерфейса - то в нем нет функциональности CObject'а и CMyObject'а - а мне она нужна. С интерфейсами - нужно множественное наследование, тогда их использование оправданно. А так - получается, я не могу добавить к какому-то классу реализацию некоего интерфейса.Имхо, это не правильная концепция. Если пользователь захочет поместить один объект одновременно в несколько списков (почему бы и нет?), то выйдет облом.
Согласен, для множественных списков данный класс не годится. Но, у меня пока еще ни разу не возникала необходимость один и тот же объект использовать в разных списках. Хотя, действительно, такая необходимость может возникнуть.
Поэтому я лично никогда не пользуюсь этим нелепым CObject. У меня своя реализация базового объекта, там никаких указателей, но зато есть счётчик ссылок - вот это реально нужная вещь. Соответственно операции присвоения и удаления указателей делаю через специальные функции.
Ну, он не более нелепый, чем Объект со счетчиком ссылок. И тот, и другой - вполне себе полезен в своем случае.
К смарт-поинтерам у меня неоднозначное отношение - мне кажется, их использование оправдано весьма нечасто. А вот код они усложняют очень заметно. Поэтому, я сперва было хотел себе такой класс сделать, но, идея на уровне идеи и осталась...
Множественное наследование почему-то не в почете. Хотя, мне лично оно кажется очень даже полезной штукой.
Никаких "костылей и подпорок" я в этом определении не вижу. Все верно - интерфейс - это сугубо виртуальный класс. Главная его задача - определить протокол взаимодействия. С чем он вполне себе справляется, на мой взгляд.
Для использования множественного нужны грамотные программисты, которых тут мало. Потому что можно такого наворотить..
Я не понимаю этих вещей
Как работают эти ссылки ? Зачем они ? Может кто нить на пальцах объяснить или показать пример ?