I have different take on OOP

It's beautiful thing that managed to enable milions of people to express more or less complex reality inside computers.

Sure it has it's quirks, something could be done better in $language, but that was decision/vision of $language design team how do they interprete object oriented programming.

The bad thing is that it is incredibly hard.

OOP and SOLID are kinda "basics of programming", yet those are incredibly difficult.

You need to have a lot of hands-on experience with creating software, modeling systems in order to make it good (maintainable, sane, easy to understand, consistent, testable, yada yada)

Simon Peyton Jones (Known for Glasgow Haskell Compiler) - Haskell is useless https://www.youtube.com/watch?v=iSmkqocn0oQ

>Why is mutable state such a big problem? The human brain is the most powerful machine in the known universe. However, our brains are really bad at working with state since we can only hold about 5 items at a time in our working memory. It is much easier to reason about a piece of code if you only think about what the code does, not what variables it changes around the codebase.

Isn't this part more about code "branches" instead of mutating state?

>Yes, one can pass immutable objects to methods in Java/C#, but this is rarely done since most of the developers default to data mutation.

Maybe because language designers didn't provide them right tool that'd enable their OOP vision to be more handy?

It's seems like there work being done that want to make this better in C# world.

>You, as a person, don’t have a “write” method either — you make the decision to write some text based on outside events or your internal thoughts

Why you don't have "write" "skill"/"ability"/"method"?

>Some people say that private methods shouldn’t be tested… I tend to disagree, unit testing is called “unit” for a reason — test small units of code in isolation. Yet testing of private methods in OOP is nearly impossible. We shouldn’t be making private methodsinternal just for the sake of testability.

"test small units of code in isolation"

everything is about how you define "unit"

"nearly impossible"

I bet that even C# and Java provide "hacks" to OOP to test private methods.

>public class InputValidatorFactory {
public IInputValidator CreateInputValidator() => new InputValidator();
}

You don't need factory, so in smaller version you added 6 lines of code (interface and impl) which allowed your code to be more flexible, I'd say that this is reasonable trade-off, but what if instead of interface, then you used function? like Func<T, bool> as argument, but maybe not to btnAddClick, cuz it's bad method anyway, but to some validate method.

Func<string, bool> predicate = str => str.Length > 5;

myFunction(predicate);

So maybe OOP could be ""fixed"" by just introducting a few FP features? e.g C# - LINQ (not mutating state) and stuff like delegates, records, discriminated unions?

>TransactionAwarePersistenceManagerFactoryProxy or RequestProcessorFactor

>https://www.reddit.com/r/ProgrammerHumor/comments/418x95/the...

>Further reading: FizzBuzzEnterpriseEdition

Of course you can make OOP look dumb if you'll use example
that were created with that purpose in mind.

OOP itself doesn't force you to use things like TransactionAwarePersistenceManagerFactoryProxy that people meme about it being common within Java world, but I personally don't think I've witnessed stuff as hardcore as this in C# more than once, twice or thrice.