Обсуждение статьи "Графика в библиотеке DoEasy (Часть 83): Класс абстрактного стандартного графического объекта"
Добрый день,
- Примеры можно дубликатов, чтобы ответить конкретнее?
- Структура и концепция построения объектов библиотеки не совсем стыкуется с концепцией стандартной библиотеки. Но если вы могли заметить, то библиотека построена на стандартном CObject и CArrayObj.
В любом случае я с удовольствием отвечу на вопросы, приму критику и предложения.
Спасибо за интерес.
- Примеры можно дубликатов, чтобы ответить конкретнее?
- Структура и концепция построения объектов библиотеки не совсем стыкуется с концепцией стандартной библиотеки. Но если вы могли заметить, то библиотека построена на стандартном CObject и CArrayObj.
В любом случае я с удовольствием отвечу на вопросы, приму критику и предложения.
Спасибо за интерес.
1. Если конкретно я имел ввиду про участок от куда начинается код "Далее по коду класса впишем методы для упрощённого доступа установки и возврата свойств объекта: ".
Как я понимаю это описание функций в базовом классе, т.е. они получаются исчерпывающими для всех объектов и имеют уровень доступа public, если будет создан наследник он увидит все эти функции, но не каждый объект имеет свойства для управления и вывода текста например и т.п... и чтобы использовать этот объект он всегда будет тянуть за собой базовый класс, а не собственный прямой от CObject, конечно возможно в этом есть смысл, что получить все фишки базового класса, вывод лога и т.п. но тогда при создании наследников необходимо все функции которые нельзя применить к классу наследнику виртуализировать и скрывать в уровне доступа private
Возможно в этом и есть фишка вашей реализации, если это так тогда СУПЕР!)))
Кстати возможно уровень protected для некоторых функций будет уместнее, чем public, но тут вам виднее конечно смотря какой в это вкладывается смысл.
2. Да, ещё раз пересмотрел ваш код, ваша концепция построения библиотеки иная, согласен, главное когда будете создавать верхние уровни классов, создавайте public функции виртуальными, чтобы другие разработчики смогли использовать ваше решение без прямого редактирования библиотек.
3. Заметил также, что вы используете объединение строк с помощью +, в некоторых версиях терминала при больших объединениях и при продолжительной работе терминала получались непредсказуемые ситуации в такой реализации))
Использую функции StringFormat и StringAdd, надежность работы повысилась, а также визуально код становится читабельней
4. Ещё хотел предупредить на счет ограничения длины создаваемых объектов при рендринге, имейте это ввиду, лучше генерировать хэш из имени и на его основе создавать объект, ограничение имеет стандартная функция, точно не помню, но возможно ResourceCreate...
1. Если конкретно я имел ввиду про участок от куда начинается код "Далее по коду класса впишем методы для упрощённого доступа установки и возврата свойств объекта: ".
Как я понимаю это описание функций в базовом классе, т.е. они получаются исчерпывающими для всех объектов и имеют уровень доступа public, если будет создан наследник он увидит все эти функции, но не каждый объект имеет свойства для управления и вывода текста например и т.п... и чтобы использовать этот объект он всегда будет тянуть за собой базовый класс, а не собственный прямой от CObject, конечно возможно в этом есть смысл, что получить все фишки базового класса, вывод лога и т.п. но тогда при создании наследников необходимо все функции которые нельзя применить к классу наследнику виртуализировать и скрывать в уровне доступа private
Возможно в этом и есть фишка вашей реализации, если это так тогда СУПЕР!)))
Кстати возможно уровень protected для некоторых функций будет уместнее, чем public, но тут вам виднее конечно смотря какой в это вкладывается смысл.
2. Да, ещё раз пересмотрел ваш код, ваша концепция построения библиотеки иная, согласен, главное когда будете создавать верхние уровни классов, создавайте public функции виртуальными, чтобы другие разработчики смогли использовать ваше решение без прямого редактирования библиотек.
3. Заметил также, что вы используете объединение строк с помощью +, в некоторых версиях терминала при больших объединениях и при продолжительной работе терминала получались непредсказуемые ситуации в такой реализации))
Использую функции StringFormat и StringAdd, надежность работы повысилась, а также визуально код становится читабельней
4. Ещё хотел предупредить на счет ограничения длины создаваемых объектов при рендринге, имейте это ввиду, лучше генерировать кэш из имени и на его основе создавать объект, ограничение имеет стандартная функция, точно не помню, но возможно ResourceCreate...
1. Публичность методов и их избыточность - издержки желания сделать множество различных способов доступа к одним и тем же свойствам. Но некоторые методы действительно будут либо виртуальными, либо прописаны только в наследниках. Но это опять-таки касается только объектов самой библиотеки. При наследовании от них, увы, все публичные методы унаследуются.
2. Подумаю. Но вообще-то верхним уронем доступа будет ещё одна точка входа в библиотеки, и это будут пользовательские функции, опять же, повторяющие уже реализованные возможности библиотеки, но будут более понятны рядовому пользователю - просто использовать функцию для получения результата, а не придумывать логику и обработчики - всё это будет делаться внутри библиотеки, а на выходе - usercase-функции для простого получения нужной информации.
3. Ничего не оптимизировал (кроме заранее обдумываемой логики) и не профилировал. Это на самый последний момент.
4. Проверял по-моему. Там длинное имя объекта возможно. Но, спасибо, буду учитывать и приглядываться.
1. Публичность методов и их избыточность - издержки желания сделать множество различных способов доступа к одним и тем же свойствам. Но некоторые методы действительно будут либо виртуальными, либо прописаны только в наследниках. Но это опять-таки касается только объектов самой библиотеки. При наследовании от них, увы, все публичные методы унаследуются.
2. Подумаю. Но вообще-то верхним уронем доступа будет ещё одна точка входа в библиотеки, и это будут пользовательские функции, опять же, повторяющие уже реализованные возможности библиотеки, но будут более понятны рядовому пользователю - просто использовать функцию для получения результата, а не придумывать логику и обработчики - всё это будет делаться внутри библиотеки, а на выходе - usercase-функции для простого получения нужной информации.
3. Ничего не оптимизировал (кроме заранее обдумываемой логики) и не профилировал. Это на самый последний момент.
4. Проверял по-моему. Там длинное имя объекта возможно. Но, спасибо, буду учитывать и приглядываться.
4. Возможно эту ошибку устранили, но не факт..функция как будто бы работает, но объект не создается, вот такое поведение при большой длине
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Графика в библиотеке DoEasy (Часть 83): Класс абстрактного стандартного графического объекта:
В статье создадим класс абстрактного графического объекта. Этот объект будет основой для создания классов стандартных графических объектов. Свойств у графических объектов много, и сегодня, прежде чем создать класс абстрактного графического объекта, нам необходимо будет сделать объёмную подготовительную работу — прописать эти свойства в перечислениях библиотеки.
Ещё раз скомпилируем советник и запустим его.
На график будем добавлять разные графические объекты, а в журнал будут выводиться сообщения о добавлении нового объекта и его краткое описание:
Как видим, всё работает, как и предполагалось.
Автор: Artyom Trishkin