Hi all,
I’m been reading The Pragmatic Programmer and have come across the
concept
of ‘Design by Contract’
(Design by contract - Wikipedia),
which is a concept I haven’t come across before.
It seems like quite a useful technique, so I was wondering what all of
your
thoughts were on the technique in general, and also the benefits,
drawbacks
and alternatives to it’s application in Ruby programming specifically.
Adam
On Jul 22, 2014, at 0:12, Adam W. [email protected] wrote:
Hi all,
I’m been reading The Pragmatic Programmer and have come across the concept of
‘Design by Contract’ (Design by contract - Wikipedia), which is a
concept I haven’t come across before.It seems like quite a useful technique, so I was wondering what all of your
thoughts were on the technique in general, and also the benefits, drawbacks and
alternatives to it’s application in Ruby programming specifically.
I played with it back in the day when I was evaluating eiffel (DBC was
first popularized by Bertrand Meyer, designer of the eiffel language). I
know there was at least one library back in the day for DBC in ruby, but
I’ve never used any of them. You might want to check this one out:
It’s old, but I doubt that matters for this topic.
There is also a newer one:
https://rubygems.org/gems/contracts
http://egonschiele.github.io/contracts.ruby/
Thanks Daniel. Same questions to you 
Thanks Ryan. So it seems old, and not particularly widespread these
days.
Is the technique still relevant? Or just a stepping stone on the way to
better TDD and BDD tools and techniques? The Wikipedia page says that
it’s
there to augment unit and integration testing, but is it really
necessary
in creating robust software? Does it fill a niche that actually needs to
be
filled?
I think that D also has something like DBC as part of the language.
On 07/22/2014 12:12 AM, Adam W. wrote:
I’m been reading The Pragmatic Programmer and have come across the
concept of ‘Design by Contract’
(Design by contract - Wikipedia), which is a concept
I haven’t come across before.
It is good to learn Design By Contract (DBC). Thinking about
invariants, pre-conditions and post-conditions helps in making classes
which work well and are easy to use. You might profit from using DBC as
a learning exercise.
I do not favor the addition of DBC conditions for most production code,
primarily because unit tests provide most of the same value that
conditions provide, but without bloating the code.
Wayne C.
On 07/22/2014 06:38 AM, Brian K. wrote:
In general, with stronger guarantees around input and output, you have
to write fewer tests.
I think that’s true. Another way to look at it is that you’ve moved
some checks from the formal test into the code-under-test. You can also
view static type checking the same way: It moves some checks into the
code (but not just that: static type notations also aids in reading the
code). Not coincidentally, one of the DBC gems in this thread seems to
be used primarily to add type checking.
Wayne C.
I got into Design By Contract with Obvious
(http://obvious.retromocha.com)
in Ruby and ended up writing my own concept of contracts in Ruby. I find
them to be useful simply because they give you runtime type guarantees
that
you don’t get normally with Ruby. Without a stronger notion of
interfaces
in Ruby, you have to lean harder on your unit tests to provide some kind
of
guarantees about certain behaviors. With contracts, you actually write a
lot fewer tests because your contract specifies and ensures more correct
input and output.
Obvious contracts were really simple, but I think the idea could be
taken
further to handle things like validation.
In general, with stronger guarantees around input and output, you have
to
write fewer tests.
-Brian
Thanks all, I was on the fence but I think I’ll check out DBC after all.
Has anyone seen a tool that generates ERR diagrams and relationship
lines, from a MySQL db that doesn’t have foreign keys? Im using MySQL
and the standard ActiveRecord table naming conventions. This link is
close, but doesn’t quite work for the AR table name conventions:
http://planet.mysql.com/entry/?id=26363
-Greg
On Tue, Jul 22, 2014 at 9:09 PM, Ryan D. [email protected]
wrote:
I’ve written (and subsequently thrown away) a couple. It’s not hard.
Me too, e.g.: http://pivotallabs.com/dot-rake/ – passed on more for
inspiration and the comment thread than as an actual recommendation. I
have no idea if it still works.
On Jul 22, 2014, at 16:43, Bert Gregory M. [email protected]
wrote:
Has anyone seen a tool that generates ERR diagrams and relationship lines, from
a MySQL db that doesn’t have foreign keys? Im using MySQL and the standard
ActiveRecord table naming conventions. This link is close, but doesn’t quite work
for the AR table name conventions:http://planet.mysql.com/entry/?id=26363
I’ve written (and subsequently thrown away) a couple. It’s not hard. Use
the graph gem + some simple file/text processing ruby to generate the
structure.
On Wed, Jul 23, 2014 at 5:10 PM, Ryan D. [email protected]
wrote:
Damn. You should look at the graph gem. It is a LOT friendlier than that code
and you might like it better.
OH yes. You did notice the date on that blog post, right? 
I think
that was before I even knew what an eigenclass was…
On Jul 23, 2014, at 12:29, Alex C. [email protected] wrote:
On Tue, Jul 22, 2014 at 9:09 PM, Ryan D. [email protected] wrote:
I’ve written (and subsequently thrown away) a couple. It’s not hard.
Me too, e.g.: http://pivotallabs.com/dot-rake/ – passed on more for
inspiration and the comment thread than as an actual recommendation. I
have no idea if it still works.
Damn. You should look at the graph gem. It is a LOT friendlier than that
code and you might like it better.
You could also take a look at:
and
(Last commit Jan 2013. But it seems it still works)
Abinoam Jr.
On Tue, Jul 22, 2014 at 3:38 PM, Brian K. [email protected]
wrote:
I got into Design By Contract with Obvious (http://obvious.retromocha.com)
in Ruby and ended up writing my own concept of contracts in Ruby. I find
them to be useful simply because they give you runtime type guarantees that
you don’t get normally with Ruby.
Adding DBC to Ruby is quite a fundamental change. I’d say, if you feel
you need to retrofit DBC functionality to Ruby which does not even
feature static typing then you’re using the wrong language; then you
are probably better off with Eiffel.
That does not mean DBC concepts cannot be used in Ruby. You can use
them for reasoning about code and even include them, e.g. as method
comments. Knowing the concept helps understand how methods interact
with each other and what are the critical things to reason about and
to define.
Without a stronger notion of interfaces in
Ruby, you have to lean harder on your unit tests to provide some kind of
guarantees about certain behaviors. With contracts, you actually write a lot
fewer tests because your contract specifies and ensures more correct input
and output.
I am not so sure whether that statement is actually true. You might
rid off some unit tests but “a lot” seems too optimistic to me.
Depending on the contract there may still be a lot of legal and
illegal variants of behavior that need verifying.
In general, with stronger guarantees around input and output, you have to
write fewer tests.
If you put it that way I agree.
Kind regards
robert
Thanks for all the input guys. I ended up approaching this from a
different angle. I used this gem to create foreign keys
GitHub - jenseng/immigrant: Foreign key migration generator for Rails from our tablename_id fields, then
the MySQL workbench Diagram generator was able to draw all my
relationships. I dropped all the unneeded keys after this was done.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs