I’m not sure what you mean? Doing composition over inheritance is considered good practice across the board, regardless of whether it’s frontend or backend.
True but due to the framework in use it’s more or less applicable and I can’t think of a single commonly used backend stack that’s relying on composition whereas I know a bunch of frontend stacks. I guess composition is handy for widget trees so that’s why you see it more often in frontend apps.
If you’ve used Dependency Injection before, you’ve used the principle of composition over inheritance. So, if you’ve ever used .Net (C#), Spring Boot (Java) or Laravel (PHP), you’ve likely used it. Modern C++ also has the DI pattern.
Rust and Go force you to use composition and don’t support inheritance at all, so if you’ve used either of those languages, you’ve followed the practice, though Go doesn’t support DI out of the box. Functional languages like Haskell also use composition over inheritance.
I think you’re confusing composition with aggregation. DI can’t be composition because the injected object is shared/borrowed, strong composition on the other hand requires the object to be owned. A composed child does not exist without its parent.
Only if you’re going by the strict UML definition of composition, which doesn’t really apply here, since the industry has moved on a bit since UML was king.
Either way, you can use DI to do composition in the strictest UML way, provided every single dependency is transient and creates a new instance every single time. Even then though, when most devs talk about composition, they aren’t referring to the strict UML definition.
Works in frontend I guess but backend is a whole different story.
I’m not sure what you mean? Doing composition over inheritance is considered good practice across the board, regardless of whether it’s frontend or backend.
True but due to the framework in use it’s more or less applicable and I can’t think of a single commonly used backend stack that’s relying on composition whereas I know a bunch of frontend stacks. I guess composition is handy for widget trees so that’s why you see it more often in frontend apps.
If you’ve used Dependency Injection before, you’ve used the principle of composition over inheritance. So, if you’ve ever used .Net (C#), Spring Boot (Java) or Laravel (PHP), you’ve likely used it. Modern C++ also has the DI pattern.
Rust and Go force you to use composition and don’t support inheritance at all, so if you’ve used either of those languages, you’ve followed the practice, though Go doesn’t support DI out of the box. Functional languages like Haskell also use composition over inheritance.
I think you’re confusing composition with aggregation. DI can’t be composition because the injected object is shared/borrowed, strong composition on the other hand requires the object to be owned. A composed child does not exist without its parent.
Only if you’re going by the strict UML definition of composition, which doesn’t really apply here, since the industry has moved on a bit since UML was king.
Either way, you can use DI to do composition in the strictest UML way, provided every single dependency is transient and creates a new instance every single time. Even then though, when most devs talk about composition, they aren’t referring to the strict UML definition.