Hi Guys n Gals,
I have recently started looking at my code in terms of design patterns and improvements to make my code more extensible. Obviously the long term goal is to improve the overall cleanliness, maintainability and extensibility.
With that in mind, I am trying to write a piece of login code. I have attached the files and it is a fairly simple piece of code in itself. It is against a public API, so I do not control the API at all.
In my attached example file, I have done two sets of workups. The first is the "easy" way, where I simply create the objects inside the returnlogin function. It's very quick, very easy, not thought out and most importantly (for this example anyway) relies on concrete classes.
So you can see that in the first class "Login1" that I rely on:
MyAPI.CallAPI myCall = new CallAPI(); and;
When I am Deserializing - MyAPI.Responses.LogonRespo
nse logonResponse = JsonConvert.DeserializeObj
In the second workup, the Response is now an interface, and the dependency is injected through the constructor.
The API Call itself has now also itself been injected into the Method via an ICallAPI interface.
And herein my question lies.
The Deserialize method looks like this JsonConvert.DeserializeObj
ing). In the first example it is simple, because I am using the concrete classes. However now I am trying to not use the concrete classes. So I have got around this by using <T> and passing its type into the CallAPI Method. This way the method itself doesn't "truly" rely on the concrete class as it is passed through as an agrugment : T thisT
So putting it out there to all the EE pro's - what would be the best way to achieve the deserializing WITHOUT relying on any concerete implementations?
This question is not only about finding the right solution to this particular question, but also a question (for me personally) regarding the best practices involved here. Is the second proposed solution too convoluted, too stupid a solution? Is it simply impractical in real world terms? Any thoughts and suggestions would be much appreciated.