Здравствуйте, гость ( Вход | Регистрация )
wiz29 | Дата 26.2.2015, 17:53 |
Что скажете насчет такого решения? По хорошему, как было сказано вами же выше - наличие виртуального интерфейса не обязательно, особенно, если не планируется дать возможность пользователю менять поведение одиночки. Реализацию же, всегда можно "скрыть" от непосредственных пользователей. |
|
Iron Bug | Дата 26.2.2015, 11:21 |
в случае, если перекрёстные ссылки всё-таки есть (это должны быть именно ссылки, а не объекты класса), то стандартное решение состоит в использовании предварительной декларации класса:
|
|
lanz | Дата 26.2.2015, 10:06 |
Цитата Получаются перекрестные ссылки, и я не нашел решения, как их развязать. Что скажете, сможете предложить решение? или это я не понял ваших комментариев? Все нормально, нет перекрестных ссылок Раскрывающийся текст class1.h
class1.cpp
class2.h
class2.cpp
|
|
call_me_Frank | Дата 25.2.2015, 22:40 |
Постараюсь ответить по-порядку ) Iron Bug, спасибо за пояснение насчет __var. В приложениях такие имена никогда не использую, это был тест на скорую руку, что бы проверить независимость переменных с одним и тем же именем в разных классах. почему-то меня взяли сомнения на этот счет это было самое простое и быстрое решение. но теперь есть причина тем более не делать этого. да, согласен, решение с классами действительно получилось довольно странным. я его не буду использовать, но кое на чем хочу остановиться: как мне показалось, вы (и Iron Bug, и wiz29) не поняли моего вопроса насчет развязки хедеров. Дело в том, что нет возможности вынести class2 в отдельный файл - он зависит от class1, который в свою очередь использует class2 в своей функции instance(). Получаются перекрестные ссылки, и я не нашел решения, как их развязать. Что скажете, сможете предложить решение? или это я не понял ваших комментариев? Цитата не совсем понятно, зачем этот огород? Iron Bug права ) это не только поиск нужного решения, это в первую очередь необходимая практика и желание разобраться. wiz29, Цитата Пользователю вообще обычно нет дела, куда пишется, был бы интерфейс, который позволяет это делать. - именно в этом и состоит моя задача.Цитата Опять же, есть вариант при котором могут быть реализованы несколько объектов-одиночек. - мне кажется, именно он и реализован во втором предложенном мной варианте с шаблонами, нет? Что скажете насчет такого решения? |
|
wiz29 | Дата 25.2.2015, 19:25 |
именно! так я и читаю книжку по паттернам, отсюда и мысли о таких решениях приходят. по-отдельности разобрал и тот, и другой паттерн, как их совместить - пока не понимаю. Собственно, я не могу понять: все классы (LOGGER & FILE_LOGGER, DB_LOGGER, ...) должны быть реализованы как Singleton, или не все? если FILE_LOGGER, наследует LOGGER и в классе BASE я использую интерфейс класса LOGGER, значит надо прописать в нем виртуальную ф-ию log(QString), для того, что бы переопределить её в FILE_LOGGER. Но если класс LOGGER является Singlton'ом, то значит ф-ия log() должна быть static...вот какие противоречия роятся у меня в голове В этом случае перечисленные (LOGGER & FILE_LOGGER, DB_LOGGER, ...) должны быть реализациями интерфейса логгирования. Пользователю вообще обычно нет дела, куда пишется, был бы интерфейс, который позволяет это делать. Интерфейс не всегда означает присутствие виртуальных методов. В терминологии шаблонов - это просто наличие у класса определенных методов/полей. Опять же, есть вариант при котором могут быть реализованы несколько объектов-одиночек. Каждый из которых будет выполнять свою задачу, либо вариант о котором я уже говорил: наличие некоторого "абстрактного" "устройства" вывода для отправки логов (на диск, в базу, в сеть и тп). Все зависит от целей. |
|
Iron Bug | Дата 25.2.2015, 19:11 |
не совсем понятно, зачем этот огород? это просто упражнение на технику программирования. весьма полезное, кстати. |
|
wiz29 | Дата 25.2.2015, 19:11 |
не совсем понятно, зачем этот огород? qDebug() все эти вещи решает вполне прозрачно, или любой другой подобный объект. Вывод всегда можно направить в нужное место. и появился вопрос: как развязать классы по отдельным h-файлам? получается зацикленное включение хедеров обычно так решают:
|
|
Iron Bug | Дата 25.2.2015, 19:02 |
насчёт решения с классами - какое-то оно странное. честно говоря, непонятно, как это будет использоваться. подумай ещё. это полезно. и обязательно попробуй использовать свои классы, без этого ты не поймёшь потенциальных минусов своего решения. и появился вопрос: как развязать классы по отдельным h-файлам? получается зацикленное включение хедеров это стандартное решение в С/C++. каждый хэдер всегда заключён в блок препроцессорных определений:
и ещё: лучше не использовать имена переменных, начинающиеся с двух подчёркиваний ( __ ) - часто это зарезервированные имена служебных переменных и функций и можно случайно напороться на конфликт с определениями в стандартных библиотеках. |
|
call_me_Frank | Дата 25.2.2015, 18:41 |
Вот еще один вариант реализации с помощью шаблонов:
и вызов:
что скажете? |
|
call_me_Frank | Дата 25.2.2015, 17:26 |
решил!
пригодна такая реализация? сделал, порадовался...теперь засомневался и появился вопрос: как развязать классы по отдельным h-файлам? получается зацикленное включение хедеров |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 29.3.2024, 3:34 |