My problem description was good, the solution, is not really good. In fact the metaphore of circles does not work completely in openehr. I believe it is the other way around.
All higher level classes may use the datatypes, but datatypes may not use the higher level classes. So datatypes must be the most inner circle so that all classes around can use datatypes. This also has an inconvenience because of dvtext which has that dependency to higher level terminology. So what do we do with on terminology depending datatypes? Make them part of the terminology related software of which terminology service also will become a part? Or do we remove codephrase from terminology service so that terminology service can be an inner circle of datatypes? So codephrase will then be in the datatypes, and terminologyid should not be inherited from object_id which else causes a conflict with support, so terminologyId would be a part of terminology service. Or support should be the inner most circle, then terminology and then datatypes? Bert Op di 20 feb. 2018 21:19 schreef Bert Verhees <[email protected]>: > 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
