Сообщение Re[5]: Порядок создания и удаления в графе (StackAllocator) от 02.01.2020 21:38
Изменено 02.01.2020 21:48 rg45
Re[5]: Порядок создания и удаления в графе (StackAllocator)
Здравствуйте, SuhanovSergey, Вы писали:
R>>Это такой дизайн, при котором не возникают странные зависимости, вроде той, что между В и C в твоем примере. Ни владение, ни знание, а не пойми что.
SS>Между В и C зависимость как раз типа "знание", без владения, например как между lock_guard и mutex.
Если В нельзя удалить, игнорируя время жизни C, то это уже не просто знание. Но и не владение. А, вот именно, не пойми что.
SS>Не могли бы вы общих чертах описать, как же всё таки делать продуманный дизайн системы с DI?
В общих чертах я уже сказал — завсимости между классами должны быть четкими, ясными и минимальными. Но без фанатизма. Иногда бывает дешевле смириться с лишней зависимостью, чем устранить ее. Это хоть с DI, хоть без. Большей конкретики, для общего случая, я дать не смогу.
R>>Это такой дизайн, при котором не возникают странные зависимости, вроде той, что между В и C в твоем примере. Ни владение, ни знание, а не пойми что.
SS>Между В и C зависимость как раз типа "знание", без владения, например как между lock_guard и mutex.
Если В нельзя удалить, игнорируя время жизни C, то это уже не просто знание. Но и не владение. А, вот именно, не пойми что.
SS>Не могли бы вы общих чертах описать, как же всё таки делать продуманный дизайн системы с DI?
В общих чертах я уже сказал — завсимости между классами должны быть четкими, ясными и минимальными. Но без фанатизма. Иногда бывает дешевле смириться с лишней зависимостью, чем устранить ее. Это хоть с DI, хоть без. Большей конкретики, для общего случая, я дать не смогу.
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, хоть без. Большей конкретики, для общего случая, я дать не смогу.