When not to use interfaces?
in [OOP]
|
From: Phlip on 3 Nov 2006 09:34 moopT wrote: > Programming to interfaces rather than objects do benefit a lot, but it > is not always a good idea to have everything implements from > interfaces, sometime we just need classes without obeying any > interfaces, such as entity (DTO, whatever), some other things. I wonder > in what siutations, we would like to use pure object without using > interfaces. Google "Dependency Inversion Principle". That's a guideline for when to inherit from an interface. BTW the Java "interface" concept isn't an OO interface, it's an "abstract base class". All things have an interface. The object 5 has an interface with + and * in it. Some languages don't let you override those! Read /Design Patterns/; it speaks of "programming to the interface". They are talking about programming to the set of methods in an object. The client of an object might not know if it accesses an abstract or concrete class. It shouldn't care. Don't write a separate abstract class for every object. (The only thing you _do_ write for every object should be unit tests, to ensure the object is always safe to change.) You program to an abstract interface when you need polymorphism, following the "Liskov Substitution Principle". Look that up, too. -- Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
From: Matt McGill on 3 Nov 2006 11:44 Phlip wrote: > moopT wrote: > > > Programming to interfaces rather than objects do benefit a lot, but it > > is not always a good idea to have everything implements from > > interfaces, sometime we just need classes without obeying any > > interfaces, such as entity (DTO, whatever), some other things. I wonder > > in what siutations, we would like to use pure object without using > > interfaces. > > Google "Dependency Inversion Principle". That's a guideline for when to > inherit from an interface. > > BTW the Java "interface" concept isn't an OO interface, it's an "abstract > base class". All things have an interface. The object 5 has an interface > with + and * in it. Some languages don't let you override those! More specifically, a Java interface is an abstract base class containing /only/ abstract methods (pure virtual functions, in C++ parlance). It exists in Java so that you can maintain type safe-ness while "programming to the interface" in the OO sense. > Read /Design Patterns/; it speaks of "programming to the interface". They > are talking about programming to the set of methods in an object. The client > of an object might not know if it accesses an abstract or concrete class. It > shouldn't care. At the time the client is actually accessing a server object, that object will naturally /always/ be concrete. The point of "programming to interfaces" is that classes should have dependencies on abstract-ness, not concrete-ness. In dynamically-typed languages, you more or less always /are/ programming to interfaces, because you don't have to specify a type at compile-time. Where it becomes particularly important to keep the principle in mind is in staticly-typed languages like Java. In statically-typed languages, you might often want to create an interface construct even if you only foresee creating one implementation because it simplifies the creation of interaction-based tests for clients of the class. If you aren't doing interaction-based unit testing, then you *still* might want an interface so you can supply stub objects in tests to eliminate dependencies on other subsystems in your code, and on external systems like databases or network interfaces. -Matt McGill
From: Mark Nicholls on 3 Nov 2006 11:55 moop? wrote: > Hi all, > Programming to interfaces rather than objects do benefit a lot, but it > is not always a good idea to have everything implements from > interfaces, sometime we just need classes without obeying any > interfaces, such as entity (DTO, whatever), some other things. I wonder > in what siutations, we would like to use pure object without using > interfaces. A typical hair split from me. classes do have interfaces....they're names just coincide with the class name in many mainstream language implementations. So the question is when are you sure that the name coincidence is not a problem? i.e. when there is only ever going to be 1 class implementing that interface. It would seem a central claim for OO, is correctness and invariance under extension, i.e. the ability to extend without having to change current implementation. So the answer in theory would seem to be NEVER, unless you have an implementation that must know it is unique....and then you have questions about versioning.....versions are subtypes (w.r.t. a usually large subset of the specification). (understandable) Laziness and the need for clarity would seem to be the only other excuses to me. I am often lazy.
From: H. S. Lahman on 3 Nov 2006 16:43 Responding to Moop?... > Programming to interfaces rather than objects do benefit a lot, but it > is not always a good idea to have everything implements from > interfaces, sometime we just need classes without obeying any > interfaces, such as entity (DTO, whatever), some other things. I wonder > in what siutations, we would like to use pure object without using > interfaces. I think the notion of an object without an interface is an oxymoron in an OO context. A cornerstone of the OO paradigm is the encapsulation and hiding of implementations. One can only do that with interfaces. At the 3GL level where type systems prevail, an object type /is/ its interface. At the OOA/D level the messages that an object will process are explicitly defined and they are its interface. (IOW, an object without an interface at the OOA/D level doesn't know or do anything useful to the problem solution because nobody can talk to it.) What you seem to be concerned about are objects that have only knowledge responsibilities without behavior responsibilities (aka dumb data holders). However, knowledge responsibilities are still accessed through the object's interface and their implementations are encapsulated and hidden by their accessors. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Daniel T. on 3 Nov 2006 22:45 "moop" <samhng(a)gmail.com> wrote: > Programming to interfaces rather than objects do benefit a lot, but > it is not always a good idea to have everything implements from > interfaces, sometime we just need classes without obeying any > interfaces, such as entity (DTO, whatever), some other things. Why do you feel this way? > I wonder in what siutations, we would like to use pure object > without using interfaces. I'm going to assume you are using the word "interface" in a Java sense for this discussion... I would say that any time you have a class that both creates and uses another solely in its implementation, you can probably get away with not having it derive from an interface. After all, adding an interface later would be a simple matter in this case. If our goal is the simplest thing that can possibly work, then interfaces would only be used if polymorphism is actually used. -- To send me email, put "sheltie" in the subject.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: MSI WindowsInstaller.Installer List of products Next: Definition of Abstract Data Type |