I must have missed new developments, I am still working with RM 1.0.3
which, I was thinking, is the production version
My remarks were for that version, and for my idea, there were some
inconveniences in it.
But I will study the new RM, and if I find some similar inconveniences,
I report them.
This is a bit another subject, but I explain it anyway, because last
weekend, I was not satisfied about my emails
Please let me explain why it is an important problem to me.
Maven (Java dependency tool) gets grumpy about circular library
references, and the Golang compiler does accept circular package
references and restricts using circular struct references.
C++ does not accept circular class references, but can be worked around
in a tricky way.
Circular references
The Dependency Rule says that source code dependencies can only point
inwards. Nothing in an inner circle can know anything at all about
something in an outer circle. In particular, the name of something
declared in an outer circle must not be mentioned by the code in an
inner circle. That includes, functions, classes. variables, or any other
named software entity. As you move inwards the level of abstraction
increases. The outermost circle is low level concrete detail. As you
move inwards the software grows more abstract, and encapsulates higher
level policies.
Robert C Martin.
Terminologyservice needs codephrase, and codeprase is part of the
datatypes, dvtext (also datatype) needs terminologyservice (in
constructor). (circular reference)
Other datatypes, for example, dvtext also need a ready compiled
terminologyservice and codephrase for checking the charset and language
in the constructor
This situation makes it impossible to separate the terminologyservice
from the datatypes, although they have no similar abstraction level
In OpenEhr this is solved by using an interface of terminologyService
inside the support-part, and that would be a good solution if the
interface did not have the codephrase also in its declarations.
So it did not solve it the violation of the dependency rule, but it
makes it compilable.
So it is a problem, and causes dirty code to solve. The solution is
simple. Make CodePhrase a part of TerminologyService and remove it from
datatypes. Then all classes which need code-phrase have to link in
terminologyservice, but terminology can be compiled independently from
other classes
The most inner circle of the dependencies should be a group
libraries/classes which do not need each other by the route of an outer
circle. The most inner group should be AOM, TerminologyService, EHR-RM,
around that should be the Support, and around that should be the
datatypes. Then there would be no problem, the datatypes can be linked
against every library and will never cause a circular reference.
Best regards
Bert
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
