Сообщение Re[5]: Порядок создания и удаления в графе (StackAllocator) от 02.01.2020 21:38
Изменено 02.01.2020 22:06 rg45
Re[5]: Порядок создания и удаления в графе (StackAllocator)
Здравствуйте, SuhanovSergey, Вы писали:
R>>Это такой дизайн, при котором не возникают странные зависимости, вроде той, что между В и C в твоем примере. Ни владение, ни знание, а не пойми что.
SS>Между В и C зависимость как раз типа "знание", без владения, например как между lock_guard и mutex.
Если В нельзя удалить, игнорируя время жизни C, то это уже не просто знание. Но и не владение. А, вот именно, не пойми что. Для таких случаев есть weak_ptr и aware_ptr. Но когда их в объекной модели слишком много, это уже само по себе симптоматично. Своего рода индикаторы паразитных зависимостей.
SS>Не могли бы вы общих чертах описать, как же всё таки делать продуманный дизайн системы с DI?
В общих чертах я уже сказал — завсимости между классами должны быть четкими, ясными и минимальными. Но без фанатизма. Иногда бывает дешевле смириться с лишней зависимостью, чем устранить ее. Это хоть с DI, хоть без. Большей конкретики, для общего случая, я дать не смогу.
R>>Это такой дизайн, при котором не возникают странные зависимости, вроде той, что между В и C в твоем примере. Ни владение, ни знание, а не пойми что.
SS>Между В и C зависимость как раз типа "знание", без владения, например как между lock_guard и mutex.
Если В нельзя удалить, игнорируя время жизни C, то это уже не просто знание. Но и не владение. А, вот именно, не пойми что. Для таких случаев есть weak_ptr и aware_ptr. Но когда их в объекной модели слишком много, это уже само по себе симптоматично. Своего рода индикаторы паразитных зависимостей.
SS>Не могли бы вы общих чертах описать, как же всё таки делать продуманный дизайн системы с DI?
В общих чертах я уже сказал — завсимости между классами должны быть четкими, ясными и минимальными. Но без фанатизма. Иногда бывает дешевле смириться с лишней зависимостью, чем устранить ее. Это хоть с DI, хоть без. Большей конкретики, для общего случая, я дать не смогу.
Re[5]: Порядок создания и удаления в графе (StackAllocator)
Здравствуйте, SuhanovSergey, Вы писали:
R>>Это такой дизайн, при котором не возникают странные зависимости, вроде той, что между В и C в твоем примере. Ни владение, ни знание, а не пойми что.
SS>Между В и C зависимость как раз типа "знание", без владения, например как между lock_guard и mutex.
Если В нельзя удалить, игнорируя время жизни C, то это уже не просто знание. Но и не владение. А, вот именно, не пойми что. Для таких случаев есть weak_ptr и aware_ptr. Но когда их в объекной модели слишком много, это уже само по себе симптоматично. Своего рода индикаторы паразитных зависимостей.
SS>Не могли бы вы общих чертах описать, как же всё таки делать продуманный дизайн системы с DI?
В общих чертах я уже сказал — завсимости между классами должны быть четкими, ясными и минимальными. Но без фанатизма. Иногда бывает дешевле смириться с лишней зависимостью, чем устранить ее. Это хоть с DI, хоть без. Большей конкретики, для общего случая, я дать не смогу.
P.S. Часто при проектировании сложных систем оказывается востребованной инверсия зависимостей (тоже DI, только inversion). Спосбов имплементации в современном C++ вагон и маленькая тележка — это и классические абстракиные интерфейсы, и сигналы, и коллбеки, теперь вот и лямбды еще. Умелое сочетание динамического полиморфизма со статическим также способно дать выигрыш.
R>>Это такой дизайн, при котором не возникают странные зависимости, вроде той, что между В и C в твоем примере. Ни владение, ни знание, а не пойми что.
SS>Между В и C зависимость как раз типа "знание", без владения, например как между lock_guard и mutex.
Если В нельзя удалить, игнорируя время жизни C, то это уже не просто знание. Но и не владение. А, вот именно, не пойми что. Для таких случаев есть weak_ptr и aware_ptr. Но когда их в объекной модели слишком много, это уже само по себе симптоматично. Своего рода индикаторы паразитных зависимостей.
SS>Не могли бы вы общих чертах описать, как же всё таки делать продуманный дизайн системы с DI?
В общих чертах я уже сказал — завсимости между классами должны быть четкими, ясными и минимальными. Но без фанатизма. Иногда бывает дешевле смириться с лишней зависимостью, чем устранить ее. Это хоть с DI, хоть без. Большей конкретики, для общего случая, я дать не смогу.
P.S. Часто при проектировании сложных систем оказывается востребованной инверсия зависимостей (тоже DI, только inversion). Спосбов имплементации в современном C++ вагон и маленькая тележка — это и классические абстракиные интерфейсы, и сигналы, и коллбеки, теперь вот и лямбды еще. Умелое сочетание динамического полиморфизма со статическим также способно дать выигрыш.