agda-stdlib has facilities for doing equational reasoning for various specific library defined relations (example). It also has a type that identifies equality relations defined here. What is the easiest way for me to get access to the same facilities for equational reason I get with propositional equality.
The kit is defined in Relation.Binary.Reasoning.Setoid.
You only need to define a proof S that your relation defines a Setoid and then you can open import Relation.Binary.Reasoning.Setoid S to get the equational reasoning combinators.
I thought import and access are types of dependency, but there was a site saying that they're not. It says that the dependency is a little it different with the import/access relationship.
What are the differences? Thanks in advance.
Dependency
A Dependency implies that the semantics of the clients are not complete without the suppliers. The presence of
Dependency relationships in a model does not have any runtime semantic implications. The semantics are all given in
terms of the NamedElements that participate in the relationship, not in terms of their instances.
PackageImport
A PackageImport is a DirectedRelationship between an importing Namespace and a Package, indicating that the
importing Namespace adds the names of the members of the Package to its own Namespace.
PackageMerge
A PackageMerge is a directed relationship between two Packages that indicates that the contents of the target
mergedPackage are combined into the source receivingPackage according to a set of rules defined below. It is very similar
to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its
own characteristics resulting in an element that combines the characteristics of both.
Dependency states that it doesn't have any runtime semantic implications; that must remain true for all subclasses (subclass cannot relax constraints). So if the PackageImport was a subclass of Dependency, then it wouldn't be able to import anything.
To oversimplify: Dependency captures an idea (e.g. this package «use»s this other package, but we don't care how), whilst PackageImport captures an action (e.g. this package «import»s this other package with these precise mechanics).
As a sidenote, they do share a common ancestor in the form of DirectedRelationship
http://tutorials.jenkov.com/ood/understanding-dependencies.html#whatis says that (emphasis mine):
Whenever a class A uses another class or interface B, then A depends on B. A cannot carry out it's work without B, and A cannot be
reused without also reusing B. In such a situation the class A is
called the "dependant" and the class or interface B is called the
"dependency". A dependant depends on its dependencies.
According to Google's definition:
a dependent or subordinate thing, especially a country or province
controlled by another.
Since A depends on B, the dependency is A and the dependant is B. This is contrary to the first quote. Or am I missing something?
Terminology is context dependent. In general, the dependency is a synonym of dependence and describes not one entity, but state. According to Cambridge dictionary:
the situation in which you need something or someone all the time, especially in order to continue existing or operating.
So it's more about a relation to something. For example:
A minor child is dependent of his/her parents. The child is in a state
of dependency. The dependency describes the relation between the child and its parents.
The google definition is only one of the available definitions (see for example the Collins dictionary), the one that is especially applicable in the context of geopolitics and real estate. For example:
Before 1776, America was a dependency of the British Empire. The
dependency America was dependent on the Empire.
He bought a farm with several dependencies
The object oriented terminology is not so different from the more general definition: a dependency is a relationship between objects or classes. Here a more formal definition from the UML 2.5 standard:
7.7.1: A Dependency signifies a supplier/client relationship between model
elements where the modification of a supplier may impact the client
model elements.
So, restating what's in the tutorial, we can say that:
If A has to use B, A depends on B. There is a relation of dependency
from A to B. A is said to be the dependent.
For practical reason and language convenience, B is often called the dependency (which is indeed the contrary of everyday's language). But in reality, it is still the relation of A to B that is the dependency.
The thing that is dependent on something is the dependency. I am dependent on H. I need H injected into me. H is a dependency of me.
for a highly modular application (implemented with OSGi) we use one module just for the domain model. The implementations of the interfaces are just simple POJOs for most flexibility (other modules which depend on the domain-module don't inherit any other dependency).
So you could see the environment like this: There are just these simple domain-objects being passed from one module to the other. So we could call them POJO-DTOs, right? The DTOs don't know anything of there data storage.
With this architecture a module has a minimal dependency to that domain-model. Modules can be easily developed independently.
One problem we are facing is that a module can implement its own internal domain using the same interfaces of the domain-module. So the two implementations need to be copied from one side to the other. This is an error-prone thing!
Has anyone a good technique/concept/library to copy/merge two implementations with the same interfaces?
Thanks!
Many articles/books/.... talk about class or package dependency, few explain what it is. I did find some definitions, but they vary and probably don't cover all cases. E.g.:
"when one class uses another concrete class within its implementation" (so there exists no dependency on an interface?)
"when a class uses another as a variable" (what about inheritance?)
"if changes to the definition of one element may cause changes to the other" (so dependency is a transitive relationship not just on packages, but also on class level?)
"the degree to which each program module relies on each one of the other modules" (but how do you define "relies"?)
Further aspects to consider are method parameters, dependency injection, aspect oriented programming, generics. Any more aspects?
So, can you give a (formal) definition for dependency amongst classes and amongst packages that is fool-proof and covers all these cases and aspects?
If you are asking for dependency in the context of inversion of control or dependency injection, well, you're probably interested in classes that interact with one another directly. That means mostly constructor parameters and properties.
In the context of a UML domain diagram, you're probably interested in "real world" dependency. A dog needs food. That's a dependency. The dog's Bark() method returns a Sound object: that's not something you're interested in, in a UML domain model. The dog doesn't depend on sounds to exist.
You could go philosophical on this also: All classes depend on each other to accomplish a common goal; a (hopefully) great software.
So, all in all, dependency or coupling is not a matter of yes or no. It really depends on the context and on a degree of coupling (weak, strong). I thinks that explains why there are some many divergent definition of dependency.
I wrote a blog post on that topic a while ago: Understanding Code: Static vs Dynamic Dependencies. Basically you need to make a difference between static dependencies, those that are resolved by the compiler at compile-time, and dynamic dependencies, those that are resolved by the runtime (JVM or CLR) at run-time.
static dependencies are typically provoked by calls to static/final methods, read/write to a field, in the definition of the class C the implementation of the interface I by C ... all these associations between code elements that can be found explicitly in the bytecode and source code.
dynamic dependencies are typically provoked by everything that abstracts a method call at compile time, like calls to abstract/virtual methods (polymorphism), variables or parameters typed with an interface (the implementation class is abstracted at compile-time), but also delegates (.NET) or pointers to function (C++).
Most of the time, when you'll read about dependencies in the literature, they are talking about static dependencies.
A static dependencies is direct (meaning not transitive). A tool like NDepend that I mention in the blog post, can also infer indirect (or call it transitive) static dependencies from the set of direct static dependencies.
The idea I defend in the blog post is that when it comes to understand and maintain a program, one needs to focus mostly on the static dependencies, the ones found in the source code.. Indeed, abstractions facilities are used to, well ... abstract, implementation for callers. This makes source code much more easy to develop and maintain. There are however situations, typically at debugging time, where one needs to know what's really behind an abstraction at run-time.
This post is about static dependency - for dynamic dependency and the difference, see
Patrick Smacchia's answer.
In an easy to understand way: an entity (class or package) A depends on an entity B when A cannot be used standalone without B.
Inheritance, aggregation, composition, all of them introduces dependency between related entities.
so there exists no dependency on an interface?
there is, but interface only serves as the glue.
what about inheritance?
see above.
so dependency is a transitive relationship not just on packages, but also on class level?
yep.
but how do you define "relies"?
see above "easy to understand" definition. also related to the 3rd definition you posted.
Update:
So if you have interface A in Package P1, and class C in Package P2 uses A as
method parameter, or
local variable woven into C via AOP, or
class C implements A, or
class C<E extends A>,
then C depends on A and P2 depends on P1.
But if interface A is implemented by class B and class C programs against the interface A and only uses B via dependency injection, then C still (statically!) only depends on A, not on B, because the point of dependency injection is that it doesn't make glued components dependent.