Thanks for the reply. I appreciate that you took the time to read my post and respond.
What I'm trying to argue for is a form of dependency injection pattern, to my understanding this is different to the Dependency Inversion Principle from the SOLID principles. Both are important to me.
This dependency injection pattern sees dependency resolution done in one place so that the rest of the application is able to act on dependencies passed in rather than doing it's dependency resolution directly.
This helps to implement the Open Closed Principle because the files that are using the dependencies can rely on interfaces rather than concretes. The way I have seen this used is to pass in different implementations that vastly change the behaviour depending on run time data. In particular using local file system in place of S3 when running locally, or calling out to a different data store when building a multi-tenant application. Because the dependency was passed in the logic doesn't need to be aware of the underlying mechanism for working with data. These files are then open for extension, by passing in a different implementation based on run time information, but closed for modification, in that they don't need to be changed or copied to change the applications functionality.
As for the Single Responsibility Principle, if you take it as a class/file/function should have one reason to change not just should do one thing then I think the above example is reasonable as well.
I love talking about this stuff so if you'd like to discuss this further I'm happy to. I'm still learning so there is always a good chance I'll find out that my opinions aren't right.
Thanks again for the comment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the reply. I appreciate that you took the time to read my post and respond.
What I'm trying to argue for is a form of dependency injection pattern, to my understanding this is different to the Dependency Inversion Principle from the SOLID principles. Both are important to me.
This dependency injection pattern sees dependency resolution done in one place so that the rest of the application is able to act on dependencies passed in rather than doing it's dependency resolution directly.
This helps to implement the Open Closed Principle because the files that are using the dependencies can rely on interfaces rather than concretes. The way I have seen this used is to pass in different implementations that vastly change the behaviour depending on run time data. In particular using local file system in place of S3 when running locally, or calling out to a different data store when building a multi-tenant application. Because the dependency was passed in the logic doesn't need to be aware of the underlying mechanism for working with data. These files are then open for extension, by passing in a different implementation based on run time information, but closed for modification, in that they don't need to be changed or copied to change the applications functionality.
As for the Single Responsibility Principle, if you take it as a class/file/function should have one reason to change not just should do one thing then I think the above example is reasonable as well.
I love talking about this stuff so if you'd like to discuss this further I'm happy to. I'm still learning so there is always a good chance I'll find out that my opinions aren't right.
Thanks again for the comment.