Всем привет.
Такой вопрос.
Есть приложение которое реализовано как набор синглтонов.
В нем каждый класс синглтон дергает функции другого класса синглтона.
Вопрос — как правильно заменить это на "нормальную" объектную модель.
В частности если делать класс-фабрику — то тут возникает ситуация когда при инициализации одного класса мы должны передать ему в конструкторе вагон поинтеров на другие классы.
Ну или делать "сторедж" интерфейсов который будет возвращать поинтер на интерфейс по имени или по типу.
Здравствуйте, Dez, Вы писали:
Dez>Всем привет. Dez>Такой вопрос. Dez>Есть приложение которое реализовано как набор синглтонов. Dez>В нем каждый класс синглтон дергает функции другого класса синглтона.
Dez>Вопрос — как правильно заменить это на "нормальную" объектную модель.
Dez>В частности если делать класс-фабрику — то тут возникает ситуация когда при инициализации одного класса мы должны передать ему в конструкторе вагон поинтеров на другие классы. Dez>Ну или делать "сторедж" интерфейсов который будет возвращать поинтер на интерфейс по имени или по типу.
Dez>Может есть что-то более красивое и адекватное ?
Здравствуйте, Dez, Вы писали:
Dez>В частности если делать класс-фабрику — то тут возникает ситуация когда при инициализации одного класса мы должны передать ему в конструкторе вагон поинтеров на другие классы.
1) Для разруливания зависимостей есть IoC Фреймворки
2) А что у класса много зависимостей, это надо рефакторить код. Может такой класс много чего делает?
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, Dez, Вы писали:
Dez>>Может есть что-то более красивое и адекватное ?
M>Dependency Injection
На вид то что нужно.
Следующий вопрос — как сохранять указатели на интерфейсы ?
Т.е. внутри класса хранить шаред/вик поинтер на внешний интерфейс ? — дабы гарантировать что мы не обратимся к удаленному объекту при закрытии апликейшина.
Или есть более красивый вариант ?
Здравствуйте, Dez, Вы писали:
Dez>Здравствуйте, Miroff, Вы писали:
M>>Здравствуйте, Dez, Вы писали:
Dez>>>Может есть что-то более красивое и адекватное ?
M>>Dependency Injection
Dez>На вид то что нужно. Dez>Следующий вопрос — как сохранять указатели на интерфейсы ? Dez>Т.е. внутри класса хранить шаред/вик поинтер на внешний интерфейс ? — дабы гарантировать что мы не обратимся к удаленному объекту при закрытии апликейшина. Dez>Или есть более красивый вариант ?
Пока единственное что приходит в голову — так это удаление объектов в обратном порядке их создания.
Здравствуйте, Dez, Вы писали: Dez>Всем привет. Dez>Такой вопрос. Dez>Есть приложение которое реализовано как набор синглтонов. Dez>В нем каждый класс синглтон дергает функции другого класса синглтона.
можно заменить вагон синглтонов на один синглтон, который будет содержать ссылки на эксземпляры остальных классов. конечно, ф-ть кроме создания-разрушения пихать в этот синглот не нужно
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, Miroff, Вы писали: Dez>>>Может есть что-то более красивое и адекватное ? M>>Dependency Injection
Р>Хрен редьки не слаще.
А что слаще?
Не ради флуда а реально интересно. Может я отстал от последних веяний.
А уж если я правильно понял, что ТС интересуют именно С++ решения, то особенно интересно.
Здравствуйте, Dez, Вы писали:
Dez>Всем привет. Dez>Такой вопрос. Dez>Есть приложение которое реализовано как набор синглтонов. Dez>В нем каждый класс синглтон дергает функции другого класса синглтона.
Это называется "процедурное программирование". То, что оно реализовано с использованием объектных конструкций языка, сути не меняет.
Если это действительно стиль, который подходит этому приложению, то можно разве что заменить всё на статические методы. Но это — вряд ли.
В первую очередь, сформулируйте, зачем вы хотите что-то менятью
Нужно в первую очередь выделить из всего этого объекты, то есть совокупность свойств и поведения. А уж дальше решать, что с ними делать.
Например, если появятся классы "обработчики" без состояния и потенциально заменяемые — используйте IoC как тут уже писали. Это и будет "сторедж интерфейсов".
Для классов — обрабатываемых данных ничего делать не надо, они не будут синглетонами.
Для остальных классов — решать индивидуально.
В общем, нужно просто попробовать спроектировать приложение заново (не переписать), а потом искать принципиальную разницу между новой и старой архитектурой.
Dez>Вопрос — как правильно заменить это на "нормальную" объектную модель.
Вы уверены, что именно этого хотите?
