crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

2 страниц V  < 1 2  
Ответить в данную темуНачать новую тему
> подклассы Singlton
wiz29
  опции профиля:
сообщение 25.2.2015, 19:25
Сообщение #11


Старейший участник
****

Группа: Участник
Сообщений: 600
Регистрация: 7.7.2010
Из: Санкт-Петербург
Пользователь №: 1866

Спасибо сказали: 94 раз(а)




Репутация:   12  


Цитата(call_me_Frank @ 25.2.2015, 16:17) *
именно!

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

Собственно, я не могу понять: все классы (LOGGER & FILE_LOGGER, DB_LOGGER, ...) должны быть реализованы как Singleton, или не все? если FILE_LOGGER, наследует LOGGER и в классе BASE я использую интерфейс класса LOGGER, значит надо прописать в нем виртуальную ф-ию log(QString), для того, что бы переопределить её в FILE_LOGGER. Но если класс LOGGER является Singlton'ом, то значит ф-ия log() должна быть static...вот какие противоречия роятся у меня в голове :blink:


В этом случае перечисленные (LOGGER & FILE_LOGGER, DB_LOGGER, ...) должны быть реализациями интерфейса логгирования. Пользователю вообще обычно нет дела, куда пишется, был бы интерфейс, который позволяет это делать.
Интерфейс не всегда означает присутствие виртуальных методов. В терминологии шаблонов - это просто наличие у класса определенных методов/полей.

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

Сообщение отредактировал wiz29 - 25.2.2015, 19:31
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
call_me_Frank
  опции профиля:
сообщение 25.2.2015, 22:40
Сообщение #12


Студент
*

Группа: Участник
Сообщений: 73
Регистрация: 20.10.2010
Пользователь №: 2129

Спасибо сказали: 0 раз(а)




Репутация:   0  


Постараюсь ответить по-порядку )

Iron Bug, спасибо за пояснение насчет __var. В приложениях такие имена никогда не использую, это был тест на скорую руку, что бы проверить независимость переменных с одним и тем же именем в разных классах. почему-то меня взяли сомнения на этот счет :lol: это было самое простое и быстрое решение. но теперь есть причина тем более не делать этого.

да, согласен, решение с классами действительно получилось довольно странным. я его не буду использовать, но кое на чем хочу остановиться: как мне показалось, вы (и Iron Bug, и wiz29) не поняли моего вопроса насчет развязки хедеров. Дело в том, что нет возможности вынести class2 в отдельный файл - он зависит от class1, который в свою очередь использует class2 в своей функции instance(). Получаются перекрестные ссылки, и я не нашел решения, как их развязать. Что скажете, сможете предложить решение? или это я не понял ваших комментариев?

Цитата
не совсем понятно, зачем этот огород?

Iron Bug права ) это не только поиск нужного решения, это в первую очередь необходимая практика и желание разобраться.

wiz29,
Цитата
Пользователю вообще обычно нет дела, куда пишется, был бы интерфейс, который позволяет это делать.
- именно в этом и состоит моя задача.

Цитата
Опять же, есть вариант при котором могут быть реализованы несколько объектов-одиночек.
- мне кажется, именно он и реализован во втором предложенном мной варианте с шаблонами, нет? Что скажете насчет такого решения?
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
lanz
  опции профиля:
сообщение 26.2.2015, 10:06
Сообщение #13


Старейший участник
****

Группа: Участник
Сообщений: 690
Регистрация: 28.12.2012
Пользователь №: 3660

Спасибо сказали: 113 раз(а)




Репутация:   8  


Цитата
Получаются перекрестные ссылки, и я не нашел решения, как их развязать. Что скажете, сможете предложить решение? или это я не понял ваших комментариев?

Все нормально, нет перекрестных ссылок :lol:
Раскрывающийся текст
class1.h
class Class1 {
Class1 * instance();
...
}

class1.cpp
#include "class1.h"
#include "class2.h"
Class1 * Class1::instance() {
  ...
}

class2.h
#include "class1.h"
class Class2 : public Class1 { ...}

class2.cpp
#include "class2.h"
...
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Iron Bug
  опции профиля:
сообщение 26.2.2015, 11:21
Сообщение #14


Профессионал
*****

Группа: Модератор
Сообщений: 1574
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 218 раз(а)




Репутация:   12  


в случае, если перекрёстные ссылки всё-таки есть (это должны быть именно ссылки, а не объекты класса), то стандартное решение состоит в использовании предварительной декларации класса:
class ClassB;  // предварительная декларация класса ClassB

class ClassA {
     ClassB *ptrB;
};

class ClassB {
    ClassA *ptrA;
    ClassA A;  // после полного определения класса мы можем использовать не только указатели, но и объекты класса
};
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
wiz29
  опции профиля:
сообщение 26.2.2015, 17:53
Сообщение #15


Старейший участник
****

Группа: Участник
Сообщений: 600
Регистрация: 7.7.2010
Из: Санкт-Петербург
Пользователь №: 1866

Спасибо сказали: 94 раз(а)




Репутация:   12  


Цитата(call_me_Frank @ 25.2.2015, 22:40) *
Что скажете насчет такого решения?


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

Сообщение отредактировал wiz29 - 26.2.2015, 17:54
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

2 страниц V  < 1 2
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 24.9.2018, 22:40