Page 3 of 3

Re: Abstract classes and Interfaces

Posted: Tue Feb 16, 2010 4:37 pm
by Christopher
PHPHorizons wrote:I've never heard of a specific/trademarked "design by contract"... Can't say I care too much what that is either lol.
The main thing I don't like about it is that it takes a set of very good ideas a little to far -- in order to make them a marketable commodity. But the general ideas of teams agreeing on interfaces, what environment code should expect when it is run, what it should change, what is should not change and what side-effects and errors/exceptions can occur is not exactly a brilliant new insight. It is exactly what teams should do. PHP interfaces help do some of that.
PHPHorizons wrote:What I do know is that when I learned about interfaces, and I read that an interface is like a contract... etc., etc., I read "contract" as "contract".

If the author of whichever tutorial I picked that up from meant something else, then they should have said that.

Contract still seems appropriate to me.
I understand your point, but I guess I still disagree because I know the broader meaning of the term.

Re: Abstract classes and Interfaces

Posted: Tue Feb 16, 2010 8:10 pm
by alex.barylski
Perhaps I'm beating a dead horse, but the only clear thing about 'contract' is that it's definition (or rather interpretation) will vary from one developer to the next.

Personally 'interface contract' means just the technical interface of a method (ie: function name, signature, return value) not it's behavior. Whether one understands a contract to include that or not, I don't know, is it really important? I suppose what is important, is that when working on a team, you decide on a definition and make everything as explicit as possible.

An interface to me, has always meant the point at which something communicates with an implementation. Regardless of the behavioral contracts, etc. So long as two or more components understand an interface or can adapt, they can communicate, regardless of how or what is done at implementation.

Cheers,
Alex

Re: Abstract classes and Interfaces

Posted: Wed Feb 17, 2010 12:34 am
by Christopher
PCSpectra wrote:Perhaps I'm beating a dead horse, but the only clear thing about 'contract' is that it's definition (or rather interpretation) will vary from one developer to the next.
I feel like I am becoming quite disagreeable. ;) I think the dead horse is that very few programmers use the term 'contract' and in my experience either they use it in the sense of 'design by contract' or they are just making things up. Honestly, there is nothing legally binding when programmers agree to an interface or behavior. The word is marketing-speak from some company. Words like specification or even the word interface itself are better. The word interface implies an agreement.
PCSpectra wrote:Personally 'interface contract' means just the technical interface of a method (ie: function name, signature, return value) not it's behavior. Whether one understands a contract to include that or not, I don't know, is it really important? I suppose what is important, is that when working on a team, you decide on a definition and make everything as explicit as possible.
Again, 'interface contract' is just silly. An interface specifies and requires exactly what it says it does -- the point where two things meet.
PCSpectra wrote:An interface to me, has always meant the point at which something communicates with an implementation. Regardless of the behavioral contracts, etc. So long as two or more components understand an interface or can adapt, they can communicate, regardless of how or what is done at implementation.
Agreed. But an interface is only part of a specification. If you have a method called save() that doesn't save then it may have the proper interface, but who cares at that point. Honestly, interfaces are the simplest part of the spec to enforce. When they are wrong it is usually pretty clear even without error messages. And once they are right they usually stay right. PHP interfaces help a little in catching these trivial errors.

Re: Abstract classes and Interfaces

Posted: Wed Feb 17, 2010 6:46 pm
by alex.barylski
I feel like I am becoming quite disagreeable. I think the dead horse is that very few programmers use the term 'contract' and in my experience either they use it in the sense of 'design by contract' or they are just making things up. Honestly, there is nothing legally binding when programmers agree to an interface or behavior. The word is marketing-speak from some company. Words like specification or even the word interface itself are better. The word interface implies an agreement.
I don't not agree. :P That is, I agree.
Again, 'interface contract' is just silly. An interface specifies and requires exactly what it says it does -- the point where two things meet
It does sound redundant, so one or the other would suffice whereas both might cause confusion, yes.
Agreed. But an interface is only part of a specification. If you have a method called save() that doesn't save then it may have the proper interface, but who cares at that point. Honestly, interfaces are the simplest part of the spec to enforce. When they are wrong it is usually pretty clear even without error messages. And once they are right they usually stay right. PHP interfaces help a little in catching these trivial errors.
An interface, in the most generic sense, I would consider the most important part (and difficult to get right) of software development. A PHP interface, which is what I think we are discussing, is relatively moot in importance, yes. I find it rare where I need an interface, and an ABC would do what I need.

I think they are relics of a complied era, when products would ship with a library file or DLL and the authors would distribute C/C++ header files or interfaces to allow extension developers to build new plugin modules while enforcing compatibility in method sigature, etc.

At the very least I suppose, what an interface does do, is offer a minor documentation to extension developers ho wish to replace parts of your system, if it is build extensible in the first place. When a class that implements an interface does so to the point where the compiler stops b*tching you have complied with the interface, which is half the battle. Now how or whether you implement the behavior is another battle.

Cheers,
Alex

Re: Abstract classes and Interfaces

Posted: Wed Feb 17, 2010 7:37 pm
by josh
PCSpectra wrote: I suppose, what an interface does do, is offer a minor documentation to extension developers ho wish to replace parts of your system
Ding ding ding. But not just extension developers though. The process of documenting (not documentation itself) provides value. It also provides documentation value for yourself.

- If you have methods that are highly cohesive and cross cutting an interface is a way of documenting duplication that you decided to live with. (and assists you in removing that duplication later when you change your mind)
- It also documents which methods out of a large class that a particular sub-routine is "interested in"