Assuming the following code:
requiredIssue.get().isDone()
where requiredIssue is an Optional and it has been verified that requiredIssue.isPresent(). Does this code break the Law of Demeter? Technically there is a tight coupling here between my class and Optional now, because isDone() now relies on get() working properly.
But is it not reasonable to assume for the standard library to work consistently?
In practical terms, the Law of Demeter means that if you have a class or function that depends on the value of isDone(), you should not pass requiredIssue to that class or function. You should simply pass the value of isDone(). If you find that following this principle leads to a proliferation of fields or parameters, you're probably violating the Single Responsibility Principle.
First,
requiredIssue.get().isDone()
does violate the Law of Demeter, which clearly enumerates the objects you can call methods on. Whatever object get() returns is not in that list. For more detail on the Law itself, see this article.
Second, the concrete example with Optional. Calling get() of an Optional has many problems and should be avoided. The Law of Demeter (which is a sort-of canary in a coalmine for bad code) correctly indicates that this construct is flawed. Problems range from temporal coupling with the isPresent() call, technical leak of having to call isPresent() in the first place, to copying the "isPresent()" logic allover the place. Most of the time if you feel the need to use get() you are already doing it wrong.
Third, the more general question of whether standard classes should be basically exempt from the Law of Demeter. They should not be exempt, if you are trying to do object-oriented programming. You have to keep in mind that some of the JDK, and most of the JEE are not actually meant to be used in an object-oriented environment. Sure, they use Java, which is a semi-object-oriented language, but they are expected to be used in a "mixed-paradigm" context, in which procedural designs are allowed. Just think of "Service" classes, pure "Data" objects (like Beans), layering, etc. These come from our procedural past, which some argue is still relevant and useful today.
Regardless where you stand on that debate, some of the standard classes/libraries/specifications are just not compatible with the Law of Demeter, or object-orientation in general. If you are willing to compromise on object-oriented principles (like most projects) that is not a problem. If you are actually not willing to compromise on a good design, but are forced to do so by libraries or standard classes, the solution is not to discuss the Law of Demeter away, but to recognize (and accept) that you are making an conscious decision to violate it.
So, is it reasonable to assume the standard library works? Sure! That does not mean they are exempt from good design principles, like the Law of Demeter, if you really want to stick with object-orientation.
Law of Demeter only applies weakly, and at system boundaries (almost never the object level, sometimes at the module level).
It's only a problem when you are forced to make 'public' a class in your module/system that would not otherwisely have to be public. IMHO Making this mistake is and/or should be rare, and avoid it it common sense, even for med-level devs.
As you can see, the standard classes (or .Net:framework/core) are NOT a violation, because often times the objects you see in their double-dots are meant to be public, anyway.
Think about the design. If you are following GRASP principles (and DDD) when choosing what kinds of objects to make, LOD will go away and lead to increased coupling.
It's nuanced, LOD is not complete crap, it's just not helpful and better to ignore, while solving the obscure problems it's meant to solve using solutions (GRASP,DDD) that address the root cause instead of just outlawing the symptoms.
More reading from people on the internet who also agree with me (which must mean I've right, huh?)
https://www.tedinski.com/2018/12/18/the-law-of-demeter.html
https://naildrivin5.com/blog/2020/01/22/law-of-demeter-creates-more-problems-than-it-solves.html
https://wiki.c2.com/?LawOfDemeterIsInvalid
Related
Somewhere I saw some personal notes from someone who was on the ANSI committee. I thought it was Kent Pitman, but a search of his site doesn't turn up anything. Neither does Google.
I'm interested in the background of the decision not to integrate the condition system with CLOS. CLtL2 speaks of it as a fait accompli, and I'm curious as to why it didn't happen.
The condition system was not integrated with CLOS because there were implementations with existing condition systems which were not CLOS-based (they were, in at least one case, flavors-based), because CLOS did not exist at all until pretty late in the standardisation process. Since a condition system has really deep roots in any implementation, requiring those implementations to rip out a great part of their guts in and replace them with some CLOS-based guts would have placed them – the very implementations which had gone out of their way to make sophisticated condition handling possible in the first place – at a huge disadvantage. Doing that would have been both stupid and would have derailed the standardisation process, since the representatives of those implementations would have been considerably antagonised by a decision like that. So the right decision was made.
It was also unclear at the time that CLOS could be made really performant on stock hardware (perhaps this is still unclear, but stock hardware is now so fast and we all happily live with implementations of other languages which are hugely slower than a good CLOS implementation can be so the problem no longer matters). CL was also considered really big (hard to remember when my fully-fledged hairy CL IDE containing the entire hyperspect and all its own documentation is 2/3 the size of my web browser), so people thought about subset implementations which might not contain CLOS but really needed to contain the condition system.
In particular it is worth looking at the CLHS issue (not part of the spec) CLOS-CONDITIONS-AGAIN, from which comes the following text:
The condition system should not be too tightly integrated into CLOS, for two reasons: Some implementations already have a native condition system that is not based on CLOS, and it should be possible to integrate the native conditions and the ANSI CL conditions. Some people would like to define an ANSI Common Lisp subset that does not contain CLOS but does contain conditions.
The problem areas are the use of DEFCLASS, MAKE-INSTANCE, and DEFMETHOD to define and create conditions, rather than using more abstract macros that conceal the implementation of conditions in terms of CLOS, and exposure of the implementation of condition slots as CLOS slots. If user code was written in a more abstract way, it could run in a subset language that did not contain CLOS.
This is not normative text but you can see what people were thinking.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've noticed that there are certain core concepts that a lot of functional programming fanatics cling to:
Avoiding state
Avoiding mutable data
Minimizing side effects
etc...
I'm not just wondering what other things make functional programming, but why these core ideas are good? Why is it good to avoid state, and the rest?
The simple answer is that if you don't have extra state to worry about, your code is simpler to reason about. Simpler code is easier to maintain. You don't need to worry about things outside a particular piece of code (like a function) to modify it. This has really useful ramifications for things like testing. If your code does not depend on some state, it becomes much easier to create automated tests for that code, since you do not need to worry about initializing some state.
Having stateless code makes it simpler to create threaded programs as well, since you don't need to worry about two threads of execution modifying/reading a shared piece of data at the same time. Your threads can run independent code, and this can save loads of development time.
Essentially, avoiding state creates simpler programs. In a way, there's less "moving parts" (i.e., ways lines of code can interact), so this will generally mean that the code is more reliable and contains less faults. Basically, the simpler the code, the less can go wrong. To me this is the essence of writing state-less code.
There are plenty of other reasons to create stateless, "functional" code, but they all boil down to simplicity for me.
In addition to what #Oleksi said, there is another important thing: referential transparency and transactional data structures. Of course, you do not need a functional programming language to do so, but it's a bit easier with them.
Purely functional data structures are guaranteed to remain the same - if one function returned a tree, it will always be the same tree, and all the further transforms would create new copies of it. It's much easier to backtrack to any previous version of a data structure this way, which is important for many essential algorithms.
Very generally, functional programming means:
encouraging the use of (first-class) functions
discouraging the use of (mutable) state
Why is mutation a problem? Think about it: mutation is to data structures what goto is to control flow. I.e., it allows you to arbitrarily "jump" to something completely different in a rather unstructured manner. Consequently, it is occasionally useful, but most of the time rather harmful to readability, testability, and compositionality.
One typical functional feature is "no subtyping". While it sounds a little bit odd to call this a feature, it is, for two (somehow related) reasons:
Subtyping relationships lead to a bunch of not-so-obvious problems. If you don't limit yourself to single or mixin inheritance, you end up with the diamond problem. More important is that you have to deal with variance (covariance, contravariance, invariance), which quickly becomes a nightmare, especially for type parameters (a.k.a. generics). There are several more reasons, and even in OO languages you hear statements like "prefer composition over inheritance".
On the other hand, if you simply leave out subtyping, you can reason much more detailled about your type system, which leads to the possibility to have (almost) full type inference, usually implemented using extensions of Hindley Milner type inference.
Of course sometimes you'll miss subtyping, but languages like Haskell have found a good answer to that problem: Type classes, which allow to define a kind of common "interface" (or "set of common operations") for several otherwise unrelated types. The difference to OO languages is that type classes can be defined "afterwards", without touching the original type definitions. It turns out that you can do almost everything with type classes that you can do with subtyping, but in a much more flexible way (and without preventing type inference). That's why other languages start to employ similar mechnisms (e.g. implicit conversions in Scala or extension methods in C# and Java 8)
I have been looking at monads a lot over the past few months (functors and applicative functors as well). I have been attempting to figure out when monads are useful in a general sense. If I am looking at a piece of code I ask, should I employ a specific monad or a stack via transformers? In my efforts I think I have found an answer but I want others input in case I have missed something. It appears to me that monads are useful for abstracting away specific plumbing to increase readabilty/the declaritive nature of a piece of code which can have a side affect of increasing productivity by requiring less code to write. The only exception I can find is the IO monad which attempts to keep a pure function pure in the face of IO. It doesn't appear that a given monad provides a solution to a problem that can't be acheived via other means. Am I missing something?
Does any feature beyond mere Turing-completeness provide a solution to a problem that can't be achieved via other means? Nope. All Turing-equivalent languages are different ways of expressing the same basic things. Since monads are built out of more fundamental building blocks, obviously that set of building blocks is able to do anything a monad can. When we talk about a language or feature "allowing" us to do something, we mean it allows us to express that thing naturally, in a way that's easy to understand.
I'm looking for non-trivial resources on concepts of asychronous programming, preferably books but also substantial articles or papers. This is not about the simple examples like passing a callback to an event listener in GUI programming, or having producer-consumer decoupled over a queue, or writing an onload handler for your HTML (although all those are valid). It's about the kind of problems the lighttpd developers might be concerned with, or someone doing substantial business logic in JavaScript that runs in a browser or on node.js. It's about situations where you need to pass a callback to a callback to a callback ... about complex asynchronous control-flows, and staying sane at the same time. I'm looking for concepts that allow you to do this systematically, to reason about this kind of control-flows, to seriously manage a significant amount of logic distributed in deeply nested callbacks, with all its ensuing issues of timing, synchronization, binding of values, passing of contexts, etc.
I wouldn't shrink away from some abstract explorations like continuation-passing-style, linear logic or temporal reasoning. Posts like this seem to go into the right direction, but discuss specific issues rather than a complete theory (E.g. the post mentions the "reactor" pattern, which seems relevant, without describing it).
Thanks.
EDIT:
To give more details about the aspects I'm interested in. I'm interested in a disciplined approach to asynchronous programming, a theory if you will, maybe just a set of specific patterns that I can pass to fellow programmers and say "This is the way we do asynchronous programming" in non-trivial scenarios. I need a theory to disentangle layers of callbacks that randomly fail to work, or produce spurious results. I want an approach which allows me to say "If we do it this way, we can be sure that ...". - Does this make things clearer?
EDIT 2:
As feedback indicates a dependency on the programming language: This will be JavaScript, but maybe it's enough to assume a language that allows higher-order functions.
EDIT 3:
Changed the title to be more specific (although I think design patterns are only one way to look at it; but at least it gives a better direction).
When doing layered callbacks currying is a useful technique.
For more on this you can look at http://en.wikibooks.org/wiki/Haskell/Higher-order_functions_and_Currying and for javascript you can look at http://www.svendtofte.com/code/curried_javascript/.
Basically, if you have multiple layers of callbacks, rather than having one massive parameter list, you can build it up incrementally, so that when you are in a loop calling your function, the various callback functions have already been defined, and passed.
This isn't meant as a complete answer to the question, but I was asked to put this part into an answer, so I did.
After a quick search here is a blog where he shows using currying with callbacks:
http://bjouhier.wordpress.com/2011/04/04/currying-the-callback-or-the-essence-of-futures/
UPDATE:
After reading the edit to the original question, to see design patterns for asynchronous programming, this may be a good diagram:
http://www1.cse.wustl.edu/~schmidt/patterns-ace.html, but there is much more to good asynchronous design, as first-order functions will enable this to be simplified, but, if you are using the MPI library and Fortran then you will have different implementations.
How you approach the design is affected heavily by the language and the technologies involved, that any answer will fall short of being complete.
What should be the measures that should be used to identify that code is over abstracted and very hard to understand and what should be done to reduce over abstraction?
"Simplicity over complexity, complexity over complicatedness"
So - there's a benefit to abstract something only if You are "de-leveling" complicatedness to complexity. Reasons to do that can vary: better modularity, better encapsulation etc.
Identifying over abstraction is a chicken and egg problem. In order to reduce over abstraction You need to understand actual reason behind code lines. That includes understanding idea of particular abstraction itself (in contrast to calling it over abstracted cause of lack of understanding). And that's not enough - You need to know a better, simpler solution to prove that it's over abstracted.
If You are looking for tool that could do it in Your place - look no more, only mind can reliably judge that.
I will give an answer that will get a LOT of down votes!
If the code is written in an OO language .. it is necessarily heavily over-abstracted. The purer the language the worse the problem.
Abstraction should be used with great caution. If in doubt always use concrete data structures. (You can always abstract later, this is easier than de-abstraction :)
You must be very certain you have the right abstraction in your current context, and you must be very sure that concept will stand the test of change. Abstraction has a high price in performance of both the code and the coder.
Some weak tests for over-abstraction: if the data structure is a product type (struct in C) and the programmer has written get and set method for each field, they have utterly failed to provide any real abstraction, disabled operators like C increment, for no purpose, and simply not understood that the struct field names are already the abstract representation of a product. Duplicating and laming up the interface is not a good idea.
A good test for the product case is whether there exist any data invariants to maintain. For example a pair of integers representing a rational number is almost sufficient, there's little need for any abstraction because all pairs are valid except when the denominator is zero. However for performance reasons one may choose to maintain an invariant, typically the denominator is required to be greater than zero, and the numerator and denominator are relatively prime. To ensure the invariant, the product representation is encapsulated: the initial value protected by a constructor and methods constrained to maintain the invariant.
To fix code I recommend these steps:
Document the representation invariants the abstraction is maintaining
Remove the abstraction (methods) if you can't find strong invariants
Rewrite code using the method to access the data directly.
This procedure only works for low level abstraction, i.e. abstraction of small values by classes.
Over abstraction at a higher level is much harder to deal with. Ideally you'd refactor the code repeatedly, checking to see after each step it continues to work. However this will be hard, and sometimes a major rewrite is required, rather than a refinement. It's probably not worth it unless the abstraction is so far off base it is not tenable to continue to maintain it.
Download Magento and have a look at the code, read some documents on it and have a look at their ERD: http://www.magentocommerce.com/wiki/_media/doc/magento---sample_database_diagram.png?cache=cache
I'm not joking, this is over-abstraction.. trying to please everyone and cover every base is a terrible idea and makes life extremely difficult for everyone.
Personally I would say that "What is the ideal level of abstraction?" is a subjective question.
I don't like code that uses a new line for every atomic operation, but I also don't like 10 nested operations within one line.
I like the use of recursive functions, but I don't appreciate recursion for the sole sake of recursion.
I like generics, but I don't like (nested) generic functions that e.g. use different code for each specific type that's expected...
It is a matter of personal opinion as well as common sense. Does this answer your question?
I completely agree with what #ArnisLapsa wrote:
"Simplicity over complexity, complexity over complicatedness"
And that
an abstraction is used to "de-level" those, from complicated to complex
(and from complex to simpler)
Also, as stated by #MartinHemmings a good abstraction is quite subjective because we don't all think the same way. And actually our way of thinking change with time. So Something that someone find simple might looks complex to others, and even become simpler with more experiences. Eg. A monadic operation is something trivial for functional programmer, but can be seriously confusing for others. Similarly, a design with mutable object communicating with each other can be natural for some and feel un-trackable for others.
That being said, I would like to add a couple of indicators. Note that this applies to abstractions used in code-base, not "paradigm abstraction" such as everything-is-a-function, or everything-is-designed-as-objects. So:
To the people it concerns, the abstraction should be conceptually simpler than other alternatives, without looking at the implementation. If you find that thinking of all possible cases is simpler that reasoning using the abstraction, then this abstraction is not suitable (for you)
Its implementation should reason only about the abstraction, not the specific cases that it will be used for. As soon as the abstraction implementation has parts made for specific cases, it indicates an "unfit" abstraction. And increasing generalization to cope with each new case, is going the wrong way (and tends to fall to the next issue).
A very common indicator of over-abstraction I have found (and actually fell for) are abstractions that represent more than what is needed, now. As much as possible, they should allow to do exactly what is required, but nothing more. For example, say you're thinking of, or already have, a "2d point" abstraction for which you can define many operators you need. Then you have another need that could really be a "4d point" similar to the 2d. Don't start to use a "Ndimensionnal point" abstraction, especially thinking that you might later need it. Maybe you'll never have anything else than 2 and 4d (because it stays as "a good idea" in the backlog forever) but instead some requirements pops to convert 4d points into pairs of 2d points. That's going to be hard to generalize to n-dimensions. So, each abstraction can be checked to cover and only cover the actual needs. In my point example, the complexity "n-dimensional" is actually only used to cope with the 2 and 4d cases (and the 4d might not even be used that much).
Finally, in a more global point of view, a code-base that has many not related abstractions, is an indicator that the dev team tends to abstract every little issues. So probably many of them are or became over-abstracted.