Joe Armstrong: Why OO Sucks

Re:Joe Armstrong: Why OO Sucks by pacala on Sunday July 15, 2012 @12:40AM (#4246145)

Caveat. I never saw any mathematical formalization for Law of Demeter. Contrast this with the Substitution Principle, which is directly defined in terms of logical implication.

With the regard of the example presented, there is at least a trivial solution. There is a BookApi which is concerned with providing Book operations, and there are the Book/Section/Paragraph data types. List<Sentence> getAllSentences(Book) is defined by the BookApi. Changing the data types doesn't affect any client of the BookApi, only the implementation of the BookApi.

Conversely, coupling the methods to the actual data types results in inflexible designs. Should a Book know how to display itself in a gui widget? Which widget library? Should a Book also know how to save itself in a database? Which database api?

[ Parent | on HN ]

Re:Joe Armstrong: Why OO Sucks by nessus42 on Sunday July 15, 2012 @01:13AM (#4246210)

So, basically what you are saying, as far as I can tell, is that there is absolutely no difference between the OO approach using the Law of Demeter and the FP approach. (Though with an FP approach, you are perhaps more likely to make things immutable, which is a good thing.)

If so, perhaps this isn't surprising, as Demeter was layered upon Scheme.

Regarding writing to databases or to screens, decent OO programmers do not put methods to do this sort of thing into the domain objects. For i/o to a database the typical OO approach is to use a separate DAO class, and for GUI i/o the typical OO approach is to use an MVC framework, or some such.

Also, I'm not sure why anyone would want a mathematical formulation for the Law of Demeter. I think that anyone would be hard pressed to formalize every aspect of good design, as what is a good design isn't a mathematical property, but more one of cognitive psychology and the art of engineering. The Demeter system did, however, automate implementation for the Law of Demeter based on specifications you would give it, so The Law of Demeter isn't just some touchy/feely thing either.

[ Parent | on HN ]

Re:Joe Armstrong: Why OO Sucks by pacala on Sunday July 15, 2012 @01:52AM (#4246258)

Since the answer to the rhetorical questions is a resounding no, there is very little meaningful behavior to be attached to the "domain objects". "Domain objects" do not obey the "Law of Demeter" and they are nothing but the data types of OCaml or Haskell. The other side of the coin are abstract apis, which are polymorphic collections of stateless functions, aka modules. Indeed, modern OO is functional programming in disguise.

Regarding Demeter, naming an anecdotically supported observation "Law" is a bit of a stretch ;)

[ Parent | on HN ]

Re:Joe Armstrong: Why OO Sucks by nessus42 on Sunday July 15, 2012 @03:03AM (#4246382)

> naming an anecdotically supported observation "Law" is a bit of a stretch ;)

Maybe, but it's a common thing to do. C.f., the Law of Thirds.

[ Parent | on HN ]

Re:Joe Armstrong: Why OO Sucks by haldean on Sunday July 15, 2012 @03:14AM (#4246397)

Which may be why almost everyone calls it the "rule of thirds". [1]

[1]: http://www.google.com/trends/?q=%22rule+of+thirds%22,+%22law...

[ Parent | on HN ]

Re:Joe Armstrong: Why OO Sucks by IsTom on Sunday July 15, 2012 @05:00AM (#4246557)

With the FP approach you can just write "show book as a widget" function yourself, without the whole inheritance hodge-podge. In case of real libraries the change of data structure probably won't be a problem as author would probably supply a function Book -> (Title, Chapters, Sentences, Strings) which would be guaranteed not to change and discourage the use of actual constructors.

[ Parent | on HN ]