oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Wagner,

On Mon, 2010-11-22 at 11:37 -0200, Wagner Francisco wrote:
> Hello,
> 
> In some classes like DvText and TermMapping we need the Terminology
> Service to enforce some invariants of the class. I didn't see in the
> specifications if there is a standard way to access the Terminology
> Service. I think each implementation can choose the best way, right?

This is true. It is interesting that just yesterday I was reviewing this
in relation to building CCDs.  I have started filing bug reports on the
specs and a couple of them will deal with deprecating DV_TEXT.mappings
and possibly even the TERM_MAPPING class.  

> 
> So far I'm receiving a Terminology Service instance in the initializer
> of the class, like this:
> 
> class DvText(...):
>    def __init__(self, value, ..., terminologyService)
>    
> I decided to use the initializer because it's easy to change the
> Terminology Service (if necessary) and because it's easy to test, I
> can create a dummy Terminology Service to simulate the behaviour I
> need. But maybe there are better approaches to do this. What do you
> think? 

I think that this is a good approach.  Considering that we do need
'something' for this version.  But there is a good chance that this will
go away in MLHIM/OSHIP 2.x 

All in all, it seems to me to be bad practice to rely on an external
service as part of a class invariant anyway.  :-)

Cheers,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part