4 ms·

> 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?

by bvrmn 8y ago

hoorayimhelping 8y ago
https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID 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.
- bvrmn 8y ago
  I saw many SOLID code bases hard to grasp and maintain because implementation hides data flow. The most evil workers are [D]-purists.
  - deleted 8y ago
    [deleted]
- abernard1 8y ago
  SOLID still doesn't accomplish what the author is criticizing in my opinion. 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.
- justaaron 8y ago
  The I in solid sounds like a major issue WRT a cross-cutting concern like security, in which hermetically sealed should mean airtight, not a piecemeal approach, etc.
itronitron 8y ago
The Java Swing API is a good example of OOP done well.
- coldtea 8y ago
  Huh? If there was a worse example of over-engineering and crappy difficult to use API that would be Swing.
  - itronitron 8y ago
    Swing can't be the worst example, it has no JButtonFactory.
- tonyedgecombe 8y ago
  I'm not sure about that, how many methods does the JButton class have? https://docs.oracle.com/javase/7/docs/api/javax/swing/JButton.html#method_summary https://docs.oracle.com/javase/7/docs/api/javax/swing/JButto...
  - itronitron 8y ago
    only a few more than the classes it inherits from :)
alasdair_ 8y ago
>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-composition-over-inheritance-ed82e482fd1a 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.
timbit42 8y ago
Smalltalk does "OOP" properly because it focuses on message passing, the real benefit of "OOP". Any OOPL that isn't based on message passing is degenerate.
- hota_mazi 8y ago
  Right. Because Objective C and Smalltalk are such resounding successes, uh?
  - armitron 8y ago
    Going by what you write here, we should all praise PHP and Javascript. 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.
    - hota_mazi 8y ago
      You do not sound condescending at all! 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.

> 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?

by bvrmn 8y ago

> 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?

hoorayimhelping 8y ago

https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID 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.

bvrmn 8y ago
I saw many SOLID code bases hard to grasp and maintain because implementation hides data flow. The most evil workers are [D]-purists.
- deleted 8y ago
  [deleted]
abernard1 8y ago
SOLID still doesn't accomplish what the author is criticizing in my opinion. 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.
justaaron 8y ago
The I in solid sounds like a major issue WRT a cross-cutting concern like security, in which hermetically sealed should mean airtight, not a piecemeal approach, etc.

itronitron 8y ago

The Java Swing API is a good example of OOP done well.

coldtea 8y ago
Huh? If there was a worse example of over-engineering and crappy difficult to use API that would be Swing.
- itronitron 8y ago
  Swing can't be the worst example, it has no JButtonFactory.
tonyedgecombe 8y ago
I'm not sure about that, how many methods does the JButton class have? https://docs.oracle.com/javase/7/docs/api/javax/swing/JButton.html#method_summary https://docs.oracle.com/javase/7/docs/api/javax/swing/JButto...
- itronitron 8y ago
  only a few more than the classes it inherits from :)

alasdair_ 8y ago

>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-composition-over-inheritance-ed82e482fd1a 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.

timbit42 8y ago

Smalltalk does "OOP" properly because it focuses on message passing, the real benefit of "OOP". Any OOPL that isn't based on message passing is degenerate.

hota_mazi 8y ago
Right. Because Objective C and Smalltalk are such resounding successes, uh?
- armitron 8y ago
  Going by what you write here, we should all praise PHP and Javascript. 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.
  - hota_mazi 8y ago
    You do not sound condescending at all! 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.