> What probably is true however is that a lot of people should unlearn the OOP they learned in school.
Can you provide references for proper OOP?
Can you provide references for proper OOP?
Joshua Bloch's "Effective Java" is well worth a read. He outlines specific principles like "Favor composition over inheritance" (https://medium.com/@rufuszh90/effective-java-item-16-favour-...) in just a couple of pages each.
I also want to strongly recommend Martin Fowler's "Refactoring" since it covers a lot of "good" OOP design and gives practical advice on how to take bad code and make it better.
The original "gang of four" "Design Patterns" book is also pretty good, although definitely less practical than the other two.
If there was a worse example of over-engineering and crappy difficult to use API that would be Swing.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JButto...
I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.
If I have a SOLID codebase, how do I unroll the object graph to get, say, a hydrated JSON representation of that? (this is the data focus the author is talking about).
I think a person who has maintained an ORM like Hibernate or Rails and wants a simple data projection without having to use their specific tools to do so implicitly understands this pain. A data oriented approach where records are passed through to the business logic as necessary doesn't have this problem.
SOLID still has things like "cat.drivesIn(car)", and so even if the concretions are supposedly hidden behind an abstraction of that interface, the coupling is right there: "drivesIn" irrevocably binds a cat and a car together. In a data oriented, more functional approach, there is a function which happens to know something about cats and cars, and it pulls in two separate records to do its work. This is more of an a la carte approach to building relationships, whereas SOLID makes every consumer potentially need to worry about that because the coupling is in the contract.
Popularity amongst the masses of 9-5 brogrammers who code for money and have no artistic sense when it comes to programming doesn't really imply quality. All the programming languages that are truly technically great - today - have small userbases. They're not easily digestible by mediocre coders, require some upfront effort and an open mind. Since the vast majority of professional programmers today are average at best, languages like Erlang, Haskell, Ocaml, Lisp, Smalltalk will never be popular.
It follows then that when looking for quality one should actually reverse popularity.
While it's true that popularity does not equal quality, one should be careful to go full tilt in the other direction and assert that non popularity means quality.
Objective C and Smalltalk were decent languages twenty years ago, but terrible languages by today's modern standards, starting with the fact that they're both dynamically typed, which we know today, is an evolutionary dead end in PLT.