Quote:Original post by rollo

Quote:Original post by DevFred

Quote:Original post by UnshavenBastard
I am by no means a software engineer (actually I still suck at desgin)

But when what you have to implement "by contract"

You raise a very interesting point here (design by contract). It would be cool if one could write preconditions, postconditions and invariants in Java interfaces.

check out the Eiffel language

Require Import List.Require Import Arith.(* Defining the interface for a set *)Module Type SET.  (* 't' is the type of the set, 'item' the type of the items *)  Parameters t item : Set.  (* Define an empty set *)  Parameter empty : t.  (* An implementation must provide these two functions *)  Parameter add : t -> item -> t.  Parameter mem : t -> item -> Prop.    (* The following axioms must hold for every implementation of list *)  (* There is no element which is a member of the empty set *)  Axiom mem_empty : forall x : item, ~ mem empty x.  (* A recently added item is a member *)  Axiom mem_add : forall (x : item) (s : t), mem (add s x) x.  (* Adding a new item to a set doesn't change anything to the other items in the set *)  Axiom mem_other : forall (x y : item) (s : t), mem s y \/ x = y <-> mem (add s x) y.End SET.Module Type EQDEC.  Parameter t : Set.  Parameter eqdec : forall a b : t, {a = b} + {a <> b}.End EQDEC.Module Natural.  Definition t := nat.  Definition eqdec := eq_nat_dec.End Natural.(* An simple implementation of a set *)Module ListSet (ITEM : EQDEC) : SET with Definition item := ITEM.t.  Definition item := ITEM.t.  Definition t := list item.  Definition empty := (@nil item).  Definition add (s : t) (x : item) := x :: s.  Definition mem (s : t) (x : item) := In x s.  Theorem mem_empty : forall x : item, ~ mem empty x.  Proof.    red; intros.    inversion H.  Qed.  Theorem mem_add : forall (x : item) (s : t), mem (add s x) x.  Proof.    intros.    simpl.    left.    trivial.  Qed.      Theorem mem_other : forall (x y : item) (s : t), mem s y \/ x = y <-> mem (add s x) y.  Proof.    split; intros.    destruct H.    simpl.    right; trivial.    subst.    apply mem_add.    simpl in H.    destruct H; auto.  Qed.End ListSet.    

Quote:Original post by DevFred

Quote:Original post by UnshavenBastard
I am by no means a software engineer (actually I still suck at desgin)

But when what you have to implement "by contract"

You raise a very interesting point here (design by contract). It would be cool if one could write preconditions, postconditions and invariants in Java interfaces. Somehow along these lines maybe:

interface Set<E>{    public boolean contains(E elem);    public void add(E elem)    post (contains(elem));    public void remove(E elem)    pre (contains(elem))    post (!contains(elem));}

That would be awesome!

Quote:Original post by UnshavenBastard
I am by no means a software engineer (actually I still suck at desgin), but I sometimes came across where MI would have been nice, because the solution with deriving from a base class that's not supposed to have certain behavior that was then implemented through interfances by the deriving classes, was dull because every class had to implement quite some stuff that was "contracted" by interface again (well, copy & paste + some modification), I thought that was not very elegant, while multiple inheritance would have been a very cool thing.
Although you might be right and it could have been solved totally different... and just did not see that ^^

EDIT:
for clarification, I like interfaces when there are just a few simple methods and/or properties to be implemented.
But when what you have to implement "by contract" starts to become more than a few lines of code, I tend to dislike it :D
(could still be due to the fact that I am not good at design ;-) )