Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
This should definitely be paired with Factory Pattern to create proper IUploader implementation, which as mentioned should be hidden inside the Upload() function.
It could as well be handled by IoT DI container by injecting the proper IUpload implementation into AvatarUploader class constructor given the fact we read storage provider config at application startup and register its implementation with the DI.
I believe what I implemented is already a Factory pattern. Essentially, I have a method that instantiates a proper IUploader implementation. This is a factory pattern. I just don't name it "Factory".
As a polyglot developer, I can assure you that not every ecosystem name this Factory. For example, in the Ruby ecosystem, they prefer to use the term for. As in rubyblog.pro/2016/10/factory-metho...
I intentionally refrain from using the term Factory because I want the reader to think beyond factory = design pattern = good architecture. I saw many developers moved from C# or Java to another language and start complaining about the lack of design patterns and good OOP practice, which is false. It is just that patterns are named differently.
Also, I don't see why do we need DI container here. I know that it is pretty popular and de facto standard for C# to have DI container inject every configuration into a bunch of classes at startup time and select proper implementation, but is it applicable to this application?
Maybe yes. Maybe no. I would like to hear an argument about it.
The main message here is I want our ecosystem to refrain from blindly following standard practices just because everyone said so or just because everyone is doing it.
Instead of doing Polymorphism just because it is a pillar of OOP and if you are OOP developer it is wrong not to use it, I assert that I do Polymorphism because I want my code to precisely reflect how stakeholders think about our system. The benefit is that it makes communication between developers and stakeholders way easier. It is a tangible benefit.
I am happy to hear your argument toward DI container. But as your comment, I don't see any argument yet. Let's talk about the benefit of using a DI container here, or we can talk about which circumstance we should use a DI container.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
thank you for your feedback. I didn't want to be too critical. What I see as one weak point is (and it has already been mentioned in previous post) that now you tightly coupled everything together.
Now your factory pattern is strictly part of User class and User is not based on any Interface thus it is not replaceable by any mock/stub implementation for testing.
More test friendly solution (the same applies and also answers your question about DI / IoT) would be to base it on an Interface. This way your method can be safely called from production code and at the same time from a test routine by injecting production code or test stub - to be able to test domain specific behavior without uploading an avatar image to production servers.
I know in the end this makes a lot of boilerplate but if your project ever grows to size when changing one thing might have any impact on other parts of code, especially in a team of multiple developers, you'd rather have tests ready to discover it before deployment.
I hope you find this argument reasonable.
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.
This should definitely be paired with Factory Pattern to create proper
IUploaderimplementation, which as mentioned should be hidden inside theUpload()function.It could as well be handled by IoT DI container by injecting the proper
IUploadimplementation intoAvatarUploaderclass constructor given the fact we read storage provider config at application startup and register its implementation with the DI.I believe what I implemented is already a Factory pattern. Essentially, I have a method that instantiates a proper
IUploaderimplementation. This is a factory pattern. I just don't name it "Factory".As a polyglot developer, I can assure you that not every ecosystem name this
Factory. For example, in the Ruby ecosystem, they prefer to use the termfor. As in rubyblog.pro/2016/10/factory-metho...I intentionally refrain from using the term Factory because I want the reader to think beyond factory = design pattern = good architecture. I saw many developers moved from C# or Java to another language and start complaining about the lack of design patterns and good OOP practice, which is false. It is just that patterns are named differently.
Also, I don't see why do we need DI container here. I know that it is pretty popular and de facto standard for C# to have DI container inject every configuration into a bunch of classes at startup time and select proper implementation, but is it applicable to this application?
Maybe yes. Maybe no. I would like to hear an argument about it.
The main message here is I want our ecosystem to refrain from blindly following standard practices just because everyone said so or just because everyone is doing it.
Instead of doing Polymorphism just because it is a pillar of OOP and if you are OOP developer it is wrong not to use it, I assert that I do Polymorphism because I want my code to precisely reflect how stakeholders think about our system. The benefit is that it makes communication between developers and stakeholders way easier. It is a tangible benefit.
I am happy to hear your argument toward DI container. But as your comment, I don't see any argument yet. Let's talk about the benefit of using a DI container here, or we can talk about which circumstance we should use a DI container.
Hi,
thank you for your feedback. I didn't want to be too critical. What I see as one weak point is (and it has already been mentioned in previous post) that now you tightly coupled everything together.
Now your factory pattern is strictly part of User class and User is not based on any Interface thus it is not replaceable by any mock/stub implementation for testing.
More test friendly solution (the same applies and also answers your question about DI / IoT) would be to base it on an Interface. This way your method can be safely called from production code and at the same time from a test routine by injecting production code or test stub - to be able to test domain specific behavior without uploading an avatar image to production servers.
I know in the end this makes a lot of boilerplate but if your project ever grows to size when changing one thing might have any impact on other parts of code, especially in a team of multiple developers, you'd rather have tests ready to discover it before deployment.
I hope you find this argument reasonable.