|
»
»
« Return to Thread: DbC question - duplicated contracts
Re: DbC question - duplicated contracts
by streborg
::
Rate this Message:
Thanks for your help, much appreciated :)
Yes, we've been implementing the contracts via the Java "assert"
statement, which can be turned on or off via a switch on the JVM -
so, efficiency shouldn't be an issue. Plain Java isn't anywhere near
as nice or functional as Eiffel when it comes to DbC (obviously !),
so I have to save old values if required etc, when coming into the
routines. There are some packages available which add DbC support,
but we wanted to try DbC with plain Java, without adding any
dependencies, and see how we go with it.
Actually, in terms of turning the contracts off in production, I've
usually taken the position that it's like most other optimisation
issue - ie, optimise when and if it becomes a problem. So, I'm
inclined to leave them on, even in production, if there is no
efficiency problems.
(I've just downloaded EiffelStudio 6.1 to play around with at
home...pity not enough places take quality seriously enough to use
Eiffel (or DbC at least !))
--- In eiffel_software@..., "colinlema" <clemahieu@...>
wrote:
>
> It also might help to point out that contracts will not be in the
> system once finalized. Their purpose is for development for the
> reasons stated before. When the system is finalized the trust is
> established that the low levels will do their jobs correctly, not
> during development.
>
> --- In eiffel_software@..., "streborg" <streborg@>
wrote:
> >
> > Hi, I am trying to introduce DbC to our developers (albeit using
> > Java...one step at a time ! ;) ) ...and am finding that there is
> > resistance at a certain level, that applying it in what I think
is a
> > rigorous manner is seen as needless, and going too far.
> >
> > A typical situation is when a function calls a "lower level"
function
> > which does the "real work". It is thought that we are just
> > duplicating contracts needlessly.
> >
> > For example, we have various layers in our software - domain,
> > application, UI, data. At the application level, say, we have
> > a "store" function (which stores some kind of object to the
> > database). To achieve its goal, it calls a corresponding data
> > layer "store" function. The application layer store function
> > basically does some transforming of the object to an appropriate
> > format (from a DTO do a domain object), and then calls the datalayer
> > store function.
> >
> > So, to my way of thinking, the contracts (just concentrating on
> > postconditions here) are quite straightforward. The application
layer
> > store method will guarantee that the object gets stored. The data
> > layer store method pretty much also guarantees the same thing.
(There
> > will be various differences too, as well as in the preconditions,
eg,
> > dealing with the different formats).
> >
> > So, if we have similar postconditions at these 2 levels, it is
seen
> > as pointlessly duplicating them.
> >
> > However, the way I see it is that is is perfectly ok to do this.
> > After all, they do in fact do similar things. Also, contracts are
for
> > specifying WHAT is done, not HOW. So, for writing contracts, we
> > should be oblivious to how the function is fulfilling its
> > postconditions (in this case by calling the lower level store
> > function) and simply concentrate on WHAT should be true after the
> > function has done its job.
> >
> > Also, "duplicating" the postconditions is building up internal
> > consistency within the application.
> >
> > Colleagues are arguing that we should look at what the functionis
> > doing, ie calling the lower level store function, and because it
has
> > the postcondition that it will store the object, then we
> > should "trust" it to do its job, and not bother duplicating the
> > postcondition at the application layer.
> >
> > To me this totally goes against the idea that the contracts are
> > stating WHAT should be done, not HOW. We might think that it's
all ok
> > now, because we can see that our current implementation calls the
> > lower level function, but if that changed (perhaps accidently)
then
> > we would never know that the higher level function is not
fulfilling
> > its contract, because we have totally left this out of its
contract.
> >
> > I hope this makes some sense ?
> > Sorry to have rambled on a bit !
> >
> > So, can anyone advise me at to how we really should be setting up
our
> > contracts in this kind of situation ?
> > duplicate, or not ?
> >
> > thanks very much ! :)
> >
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...
<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Yes, we've been implementing the contracts via the Java "assert"
statement, which can be turned on or off via a switch on the JVM -
so, efficiency shouldn't be an issue. Plain Java isn't anywhere near
as nice or functional as Eiffel when it comes to DbC (obviously !),
so I have to save old values if required etc, when coming into the
routines. There are some packages available which add DbC support,
but we wanted to try DbC with plain Java, without adding any
dependencies, and see how we go with it.
Actually, in terms of turning the contracts off in production, I've
usually taken the position that it's like most other optimisation
issue - ie, optimise when and if it becomes a problem. So, I'm
inclined to leave them on, even in production, if there is no
efficiency problems.
(I've just downloaded EiffelStudio 6.1 to play around with at
home...pity not enough places take quality seriously enough to use
Eiffel (or DbC at least !))
--- In eiffel_software@..., "colinlema" <clemahieu@...>
wrote:
>
> It also might help to point out that contracts will not be in the
> system once finalized. Their purpose is for development for the
> reasons stated before. When the system is finalized the trust is
> established that the low levels will do their jobs correctly, not
> during development.
>
> --- In eiffel_software@..., "streborg" <streborg@>
wrote:
> >
> > Hi, I am trying to introduce DbC to our developers (albeit using
> > Java...one step at a time ! ;) ) ...and am finding that there is
> > resistance at a certain level, that applying it in what I think
is a
> > rigorous manner is seen as needless, and going too far.
> >
> > A typical situation is when a function calls a "lower level"
function
> > which does the "real work". It is thought that we are just
> > duplicating contracts needlessly.
> >
> > For example, we have various layers in our software - domain,
> > application, UI, data. At the application level, say, we have
> > a "store" function (which stores some kind of object to the
> > database). To achieve its goal, it calls a corresponding data
> > layer "store" function. The application layer store function
> > basically does some transforming of the object to an appropriate
> > format (from a DTO do a domain object), and then calls the data
> > store function.
> >
> > So, to my way of thinking, the contracts (just concentrating on
> > postconditions here) are quite straightforward. The application
layer
> > store method will guarantee that the object gets stored. The data
> > layer store method pretty much also guarantees the same thing.
(There
> > will be various differences too, as well as in the preconditions,
eg,
> > dealing with the different formats).
> >
> > So, if we have similar postconditions at these 2 levels, it is
seen
> > as pointlessly duplicating them.
> >
> > However, the way I see it is that is is perfectly ok to do this.
> > After all, they do in fact do similar things. Also, contracts are
for
> > specifying WHAT is done, not HOW. So, for writing contracts, we
> > should be oblivious to how the function is fulfilling its
> > postconditions (in this case by calling the lower level store
> > function) and simply concentrate on WHAT should be true after the
> > function has done its job.
> >
> > Also, "duplicating" the postconditions is building up internal
> > consistency within the application.
> >
> > Colleagues are arguing that we should look at what the function
> > doing, ie calling the lower level store function, and because it
has
> > the postcondition that it will store the object, then we
> > should "trust" it to do its job, and not bother duplicating the
> > postcondition at the application layer.
> >
> > To me this totally goes against the idea that the contracts are
> > stating WHAT should be done, not HOW. We might think that it's
all ok
> > now, because we can see that our current implementation calls the
> > lower level function, but if that changed (perhaps accidently)
then
> > we would never know that the higher level function is not
fulfilling
> > its contract, because we have totally left this out of its
contract.
> >
> > I hope this makes some sense ?
> > Sorry to have rambled on a bit !
> >
> > So, can anyone advise me at to how we really should be setting up
our
> > contracts in this kind of situation ?
> > duplicate, or not ?
> >
> > thanks very much ! :)
> >
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/eiffel_software/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/eiffel_software/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:eiffel_software-digest@...
mailto:eiffel_software-fullfeatured@...
<*> To unsubscribe from this group, send an email to:
eiffel_software-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
« Return to Thread: DbC question - duplicated contracts
| Free Forum Powered by Nabble | Forum Help |