.Net's HttpClient is a hot smoking pile of garbage
Since OOP didn't want to be murdered, I figured I'd go for the kill, by illustrating its inferiority, by using a real world example of where it sux - I am talking about HttpClient of course
Join the DZone community and get the full member experience.Join For Free
HttpClient is probably one of the most popular C# classes ever created. Most noobs looks at it to justify their faith in OOP, and howls over each other in joy, while screaming out loud "it's async", or something similar, to justify their newfound belief in OO as a construct. Now for the record, implementing an HttpClient type of thing async, is a major improvement over the previous crapware Microsoft released in this space - However, HttpClient is fundamentally broken, and the only "fix" that exists for it, is to give focus to the folder where its code resides, then hold down your SHIFT key on your computer, while simultaneously clicking the DELETE button.
Above is the initial design documents for HttpClient
First of all, HttpClient implement IDisposable, yet you're never supposed to invoke it. This is such a clear violation of the LSP principle, implying Liskov Substitution Principle, that it hurts to look at. 90% of every single tutorial I have ever seen online that shows how to use HttpClient, is wrapping the instantiation of it inside of a using statement - Ouch! A disaster waiting to happen ... :/
As if that wasn't enough, the freakin' thing mutates. Microsoft tried at some point to fix HttpClient, by creating IHttpClientFactory, which of course only added to the insult. Simply put, because IHttpClientFactory might return a shared instance, and HttpClient mutates, due to that it has these idiotic methods allowing you to set the "default HTTP headers" it should use, if none are explicitly given on a per request basis. Hence, some random method, 54 layers deep inside of any one of your modules, possibly indirectly consumed through 15 layers of NuGet packages - Might in theory break your app, and it might very well work every day of the week, except Thursdays for that matter.
To illustrate the above problem, imagine having a perfectly functioning application. Then adding a NuGet package, wiring up its dependency injection as its documentation dictates, and all of a sudden all existing invocations to HTTP GET in all other parts of your app all of a sudden stops functioning!
If spaghetti on a plate is bad, imagine putting dynamite into your spaghetti, then to leave the plate on the village square, detonate the dynamite, and watch spaghetti fly all over your local village, putting sauce on every single building in a 3 mile radius. Sure, you've solved the spaghetti problem, but then again you've created a gazillion new problems in the process. The previous analogy just explained the IHttpClientFactory problem in case you were wondering. Now if HttpClient had only been created in a functional programming language ...
I rest my case, OOP is dead! Long live FP! ;)
Opinions expressed by DZone contributors are their own.