Say class A implements interface B; what can we call class A in relation to interface B? Is it the case that class A is a 'subclass' of interface B (as if B was a class), or is there a special term for implementing an interface, or is there none?
Thanks in advance
Edit: Would accept Alex's response if it was an answer
I believe that the correct term is Concrete class.
http://www.careerride.com/Java-concrete-class-abstract-class-interface.aspx
The "interface implementation" is typically what I have heard it called. I'm quite confident that most developers would understand what you mean when you say that.
You could say: A is an implementation of B.
"Interface implementation" is generalised while in android we usually call it "Interface Listener class".In your case if A implements interface B then it will also implement its methods.
I don't know if this gives you a satisfactory answer, but let me give a try!
Any class that inherits a parent class, or implements an interface is a "Polymorph" of the parent class / interface. i.e., wherever you need an interface instance, your polymorphic version (or polymorph) can fit in well.
For exammple, if a class "FileLogger" implements "ILogger" interface, the "FileLogger" class is a polymorph of the type "ILogger".
You don't call classes that implement an interface anything, at least I don't know of any specific term, they're just implementing a certain set of property specifications and methods without necessarily having anything to do with it in OO terms. People seem to often denote "interface implementation" as "interface inheritance", the latter is wrong and should be used in its right meaning (which is actually when interfaces are inheriting other interfaces, obviously) to avoid confusion.
TL;DR I believe there's no term for it.
I've heard of it being called and "Interface Implementation", and a "Concretion".
Related
It happens quite often that I have an abstract class that is pretty much an interface, save for a few trivial methods (say an average(array) method).
In these cases, does it make sense to create an interface, so that the abstract class implements it?
You don't need an interface for everything. An abstract class is fine. In some languages you can "implement" several classes and "extend" only one. So only if you have a case where you want to use multiple inheritance, then go ahead and make an interface for it. Otherwise, don't bother and just keep things simple.
If you use languages like C++, then there is no difference between an interface and an abstract class, so you can see that it doesn't really matter.
Note that there is also a question about it here:
Interface or an Abstract Class: which one to use?
This is the situation. I've been a C++ programmer for ages. I like abstract classes and "interfaces" so I would likt to do the same using objc.
I use a protocol for my interfaces, but the problem is that when my abstract class inherits from the protocol (I don't want to implement it here) I get warnings like:
warning: method definition for 'XXXXX' not found and 'XXXXX' class does not fully implement the 'XXXXXX' protocol.
Is there anyway to supress this? I hope child classes of this ones will throw "correct warnings" if base class did not implemented the protocol.
Another option is to inherit from the protocol just when needed, but I like to force this in the base class to make sure inherited implementes the interface.
Any tip?,
Thanks in advance.
When you implement a protocol in an Objective-C class, you have to implement all the methods. However, you can provide stub implementations. This mailing list post describes how to use doesNotRecognizeSelector: in "abstract" classes.
I don't think there is a solution in a way you are looking for. You must define all methods declared in the protocol, at least implement them as an empty methods.
I understand that you are looking for a C++ like code, but Obj-C is different and we must live with it. Also, gcc supports c++/obj-c mix, so you can write some part of the project in pure C++ what is great when you need some low-level code or want something easy to port.
I have seen many answers on stackoverflow, but I didn't find an answer that is matching mine.
Apart from all those difference, Does it make sense if we say an abstract class abstracts the implementation of behaviour while an interface abstracts the type which implements the behaviour.
An abstract class can (and normally does) provide some implementation.
And interface cannot provide any implementation.
The main differences from design point of view are that:
you can declare a contract on constructor of the implementing classes, by creating a protected constructor in the base abstract class.
you can provide implementations of methods usable by base classes
you can make a wrapper around the contract (e.g. validate method arguments)
you can provide a "calling scheme" when you create non-abstract methods that call abstract methods of the type, implemented by derived classes. This can be useful for implementing abstraction of an algorithm in derived classes, while the base class implements all the handling logic - prepares and validates data, and lets the actual processing algorithm to be implemented by derived classes.
So I would say you are correct in the statement that "an abstract class abstracts the implementation of behaviour while an interface abstracts the type which implements the behaviour"
Abstract class: provides requirement to implement some methods (you override methods of the abstract class)
Interface: defines only a contract. Indicates that a class that implements the interface has methods of the interface (you implement an interface)
For example:
by implementing an interface on an existing class, you just declare adding the interface methods to the contract of the class. The class may already implement all the methods of the interface and you do not need to change anything in the existing class.
by changing the base type to an abstract class, you are required to override all the methods, even if methods with the same names as abstract methods of the base class already exist on the type.
Not really no, because an abstract class doesn't need to implement any behaviour. It probably should, because otherwise you may argue the usefulness of it, but it doesn't have to.
Commonly, an abstract class implements some behavior, but leaves some specialized behavior unimplemented.
For example, you might write a class that implements a network application server, but does not implement the process function, instead leaving that to the inherited class to implement.
class MyServer(Networkserver):
// process() is called whenever a client has sent a request
function process(data):
...
By making the class abstract and therefore unable to be instantiated, there does not have to be some proper "default" behavior for the specialization functions.
Interface = pure abstract class (abstract class with no implementation)
Purely from a design point of view, and being language agnostic, an interface is a contract between your class and the client, promising what it does, not how it does it. This is the usage implied in the "program to an interface" mantra.
Since languages such as C++ don't have interfaces, an abstract class is the only way to represent it. For languages in which interface is a first class construct, either way is acceptable and there are trade-offs in the choice. There are, of course, other technical differences in implementation between languages, but I don't believe you asked about those.
There is an interview with Erich Gamma, in which he discusses some of the differences.
To answer your question, I think it makes sense from a theoretical point of view. From a practical point of view, it probably depends which language you are programming in :)
Both have specific uses as per the language design- abstract class are designed to be a base class and cannot be instantiated. wheras when u need to define just a contract (NO implementation) which each implementing class must follow in thrie own way, then u must use interfaces.Also -
Can be a base class for Inheritance
abstract class - yes Interface - no
Can have impelementation
abstract class - Yes Interface -No
I have a few questions for you wise people involving OO design with Interfaces and abstract base classes. Consider the following scenario:
I have an abstract bass class "DataObjectBase" and a derived class "UserDataObject." I also have an interface "IDataObject." The interface of course exposes all of the public methods and properties that my Data Objects must expose, and you can probably guess that the abstract base implements the methods and properties common to all Data Objects.
My question is, if the abstract bass class DataObjectBase implements everything specified in the interface IDataObject, should the interface be declared on the base class, or on the derived classes(s)?
In C# interfaces declared on the base class are implicity applied to the derived classes, but is this the best practice? It seems to me that implementing the interface on the base class makes it less obvious that the derived class implements the interface, but then again requires the Interface to be specified for each derived class.
Additionally, if the base class was NOT abstract, would the reccomendation change?
A second sub-question: If the base class implements all of the methods/properties of the IDataObject interface, is the interface even needed? The base class typename can simply be used in place of the interface name, ie:
private DataObjectBase _dataObject;
private IDataObject _dataObject;
In the above example (where again the base implements everything exposed by the interface) both can be assigned the same derived types. Personally I always use the interface in these situations, but I am intrested in hearing peoples thoughts.
Thanks in advance.
My way of thinking about such problems is to consider the different people reading the code, the "roles" if you like. Also consider the overall maintainability of the system.
First there is some code expecting to use the Interface. It's written in terms of the interface, the author has (should have) no interest in the implementation. That's why we provide the Interface class. From that perspective the Abstract Base Class is just one of many possible implementation hierarchies. Don't tell this role about implementation details. Keep the Interface.
Then we have the role who is designing an implementation. They come up with one possible approach and discover some variations, so they want to pull common code together. Abstract Base Class - fill in the common stuff here, let detailed implementers fill in the gaps. Help them by providing abstract methods saying "your code goes here". Note that these methods need not only be the ones in the Interface. Also note that this Abstract Base Class might even implement more that one Interface! (eg. It's CleverThingWorker but also a IntermediateWorkPersister.)
Then we have the role who actually do the fine detailed implementation. Fill in the gaps here. Dead easy to understand. In this case you don't even need to consider the Interface as such. Your job is to make that abstract class concrete.
Bottom line ... I use both Interfaces and Base classes. You put the Interface on the Base Class. We don't add value by adding it to the implementation class.
If your user classes will always inherit from one base class, then you don't need the interface. If there is a possibility that you will have classes that match the interface but are not derived from the base class, then use the interface.
As for the interface being hidden in the base class and hence not immediately visible in the user class, this is normal and can be dealt withg by the compiler. This is also where good naming conventions come in - your UserDataObject has a name that matches IDataObject, as does DataObjectBase. You could add a comment to the class file that says it inherits from IDataObject, but it will be visible that it inherits from DataObjectBase, which in turn looks like it inherits from IDataObject by its name.
The other thing that needs to be mentioned is that the use of interfaces makes it easier to implement automated tests.
Say, for example, that one of the methods of the interface is supposed to throw a exception - such as 'DatabaseConnectionLostException' - and you want to test client code to check that it behaves correctly in such a situation.
It is a simple matter to provide an implementation of the interface that throws the exception, allowing the test to be written.
If you used the abstract base class instead of the interface, this operation would be quite a bit trickier (OK, you can use Mocks, but the interface solution is much cleaner)
This question already has answers here:
Closed 13 years ago.
Duplicate:
When to use an interface instead of an abstract class and vice versa?
Probably one of the most famous software developer job interview questions.
What would be your answer?
EDIT: I'm trying to find out how you would answer this in a real-life situation. Please try to formulate your answer as you would on a real job interview (be complete, but don't be too long, post no links of course).
An interface only describes the actual signature of its methods etc. Any class implementing that interface must then provide an explicit implementation.
An abstract class can contain a partial implementation of its methods etc.
An abstract class can have member variables, an interface cannot (or, in C++, should not).
In Java, an "Interface" is a well-defined syntactical element, while in C++ it's merely a design pattern.
Interfaces provide definitions of methods that must be implemented by a class. The purpose of interfaces is to allow you to generalise specific functionality regardless of implementation. You may have an IDatabase interface that has an Open/Close method. The class that implements that interface may be connecting to a MySQL database or MS Access database. Irrespective of how it accomplishes this task, the goal is still the same...Open database, close database.
Abstract classes are base classes that contain some abstract methods. They cannot be instantiated they are to be derived from. The purpose of an Abstract class is to allow you to define some generic functionality and sub-class to implement more specific functionality where appropriate.
So in summary, you should use interfaces when the implementation of each class differs completely. Use abstract classes when you have some similar behaviour but need to implement parts differently.
Hope that helps.
I would say that the difference is language dependent, but that in C++ at least, abstract classes are the means by which interfaces are implemented.
As far as job interviews are concerned, I've always heard that the key point is that an interface is a contract; an interface, while not implementing it itself, guarantees functionality.