OOP is so ass, classes that extend classes that need objects, of classes that extend classes , passend to their constructor which constructs an object to be given to a constructor of a class that extends a class that implements three interfaces. And in the end it all could have been done with a single function and all of these classes get used a single time.

It is the same "using wrong tools for a given job" problem

Yes, it's the language paradigm that's broken... Not the engineer who designed it. /s

@sariel working with code others wrote it seems like a hell of a lot of oop engineers are broken then

@asgs in that case oop is like Apples special little screwdriver had to ne made to solve the Problem that was made to be solved by it

@bighead There are a lot of use cases for OOP.

@c3r38r170 > "There are a lot of use cases for OOP"

The 'dark side' of OOP is it's the drug used to feed a code addiction.

We have a dev who has his masters degree in software engineering, and OMG, the rube-goldberg machines he builds for the most basic things.

Like logging....why do you have an interface, abstract class, base implementation, then another inherited class just to LOG A MESSAGE TO THE CONSOLE?!!

Me: "Couldn't you have simply write Console.Writeline?"

Dev: "Written this way, I could log to a file, to Splunk, Elasticsearch, whatever."

Me: "Will you ever do that?"

Dev: "I might."

Me: "Seriously, once you deploy, do you think you'd ever go back and change the code just to log to a file?"

<shrugs shoulders>

Dev: "I don't know, I might."

The most important thing is to know when to use composition over inheritance. Unfortunately, most of the libraries and SDKs always pick inheritance for everything. It doesn’t help that also most of learning and training resources are based on OOP.

@bighead that's acceptable.

Blaming OOP for poor software architecture is like blaming your teeth for getting cavities because you won't brush them.

Sounds like you just work with shitty devs. Surround yourself with success and you'll be successful, surround yourself with shit and you'll be covered in shit.

@sariel I agree, oop has its benefits and functional has its own.

Personally I use both and I really like that C# is adding more functional elements.

But so far I think functional requires a lot more of the developers in large projects in order to keep it easy to use for new developers.

Could just be that the pure functional I have seen was done by bad devs.

But I have seen the same for oop or purely procedural programs to.

In the end it’s always the developers responsibility to build good code.

@bighead not just OOP. I think most devs have no idea wth they're doing. Script kiddies who got old.

@PaperTrail what about 1 interface that takes in an array of sinks and that's it...

@PaperTrail "why do you have an interface, abstract class, base implementation, then another inherited class just to LOG A MESSAGE TO THE CONSOLE?!!" - so you _literally_ don't have to care the slightest idea of the tiniest bit if at some point, you don't wanna log to the console anymore?

which actually happens quite often.

logging to console in development, logging everything to our logging server on integration, logging only important stuff to the customers logging server on production. no code change needed.

but then again, our code base is a bit bigger than 100 LoC

@Crost This is what I get to have fun with (attached image).

@PaperTrail that ain't oop

@Crost > "that ain't oop"

How's this (attached). It was how we used to cache data (in Microsoft's AppFabric). I didn't include the interfaces that access the data (the CRUD stuff) or the mappers from the cache to <whatever>

This over-engineered masterpiece was the brainchild of the department manager and his cronies because the "old way" wasn't OOP enough. Old caching way was

Key : String, Value: String;

Where the Value was the serialized data of anything. Products, customers, whatever. It would be up to the individual developer's discretion on how best to utilize the cache. This architecture worked for almost 3 years before the manager found out we put no restrictions/rules on key/data management.

Took about 3 more years to get the code migrated/changed and by that time we'd already switched to Redis with the individual teams having to implement there own interfaces. The geniuses wrote the backbone specific to AppFabric which meant a complete re-write.

@PaperTrail no idea. No relationship arrows and too blurry.

But I would say inheritance and interfaces don't make something OOP.

Caching is not an OOP problem so i feel for you xD stick it behind a thin abstraction for a key value store and job done.

@Crost > "Caching is not an OOP problem"

Exactly. What was funny (or sad?) was how much slower their solution was as compared to the old way. It was actually faster to thrash the database than it was to use the cache.

Now our caching solution is obscenely boring. Key/Value pairs of data. That's it. No drama or multi-layers of obscurity.

I suggest acquiring proficiency

@PaperTrail feelsbad.webm