30 ms·

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 a

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.

pacala 14y ago
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 ;)
- nessus42 14y ago
  > 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.
  - haldean 14y ago
    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+of+thirds%22 http://www.google.com/trends/?q=%22rule+of+thirds%22,+%22law...
IsTom 14y ago
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.

pacala 14y ago

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 ;)

nessus42 14y ago
> 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.
- haldean 14y ago
  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+of+thirds%22 http://www.google.com/trends/?q=%22rule+of+thirds%22,+%22law...

IsTom 14y ago

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.