85% of survey respondents use an observability tool within their organization. Join our Observability and Performance event to find out why.
Platform Engineering: Enhance the developer experience, establish secure environments, automate self-service tools, and streamline workflows
Stats
| Reputation: | 554 |
| Pageviews: | 352.2K |
| Articles: | 10 |
| Comments: | 7 |
Comments
Oct 21, 2019 · John Allen
Hmm. You said "dependencies may only flow downward" but the AddItemUseCase makes some calls to three different gateways, which are upward dependencies in this case, am I right?
A class from the use case layer have knowledge of something from an upper layer. Isn't this a situation that you said that should be avoided?
Oct 10, 2018 · Ioan Tinca
Well, the threads are actually communicating with each other in the case of a producer consumer problem, or, more generally speaking, when they use a common memory. Even, if the blocking queue is where the notify() gets called, the one that “notifies” is one of the threads. For example, if the queue is empty, when the producer thread calls blockingQueue.put(), the thread will actually “go in that method”, stores an element and after that it will notify the other sleeping threads. That’s the producer thread who notifies, even if that happens at the queue level. The calling thread will represent the execution environment. That’s the standard approach. So, if the question is that if they should talk directly with each other, the answer will be yes. That’s actually happen.
If you choose to call the notify() at the task level or at the queue level, this depends on what you want to achieve, but at some point the threads will “talk”.
Now, there are other paradigms to deal with that. For example, if you look at the actor model this works differently. The threads will not “talk” using wait/notify, but insteads they will asynchronous communicate using messages. But that’s another story :).
Oct 10, 2018 · Ioan Tinca
Hi Phil. I am not sure that I understand your question correctly. If you use the blocking queue, that's what will happen. The queue will comunicate with the producer and the consumer, and they will not talk direclty with each other.
Mar 07, 2018 · Ioan Tinca
That is why this is not a silver bullet :)
Mar 06, 2018 · Ioan Tinca
Thanks Denis! I am glad you liked it.
Dec 30, 2017 · Ioan Tinca
Hi, Yes you are right that I talked about Dependency Inversion but the Dependency Injection pattern is an application/ implementation of the Dependency Inversion principle. Dependency Inversion says that:
A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.
But the passing of a dependency or collaborator to another class, often via constructors or setters is dependency injection which is the main point in this article.
Nov 08, 2017 · Ioan Tinca
Thank you for your feedback. Yes, you're example describes better how the law should be applied and, yes, in my example the Employee and Adress objects are tightly coupled. But, in this example, Employee encapsulates the Address and you are allowed to have methods to interogate the encapsulated objects. And if the Address object is refereed just in the Employee object, this does not break the rules of coupling. Maybe this is not the best design for this situation, but what I want to show with this example was what method calls the Law of Demeter forbids. The Law is not just about behavior. It is not saying that you should not interogate the state. It is about communication between objects and about what methods you are allowed to call.