This question already has answers here:
Creating an abstract class in Objective-C
(21 answers)
Closed 7 years ago.
I've realized there's no abstract classes in Objective-C. Is there any way to achieve the same functionality in some other way (a class that can't be instantiated, or methods that MUST be overridden by their subclass)?
It depends exactly what you want. If you would just use the class as an interface with no implementation then using a protocol instead is best. If you need some base or default implementation then you either document that the class shouldn't be instantiate do directly (common nowadays I think) or you implement the class to throw exceptions if it is instantiated directly (uncommon nowadays). Also throw exceptions in any methods that should be implemented by a subclass and are called on the superclass.
Unless you're creating a framework that will be delivered to other developers it's generally not worth the effort to implement, just document.
Related
This question already has answers here:
Can I extend a class using more than 1 class in PHP?
(18 answers)
Closed 2 years ago.
We know that PHP5 or later allow OOP but not support multiple inheritance like C++
Does PHP7 supported Multiple Inheritance?
From the manual:
A class can inherit the methods and properties of another class by
using the keyword extends in the class declaration. It is not possible
to extend multiple classes; a class can only inherit from one base
class.
I believe traits are a compromise to do things you'd usually do via multiple inheritance.
Traits are a mechanism for code reuse in single inheritance languages
such as PHP. A Trait is intended to reduce some limitations of single
inheritance by enabling a developer to reuse sets of methods freely in
several independent classes living in different class hierarchies. The
semantics of the combination of Traits and classes is defined in a way
which reduces complexity, and avoids the typical problems associated
with multiple inheritance and Mixins.
http://php.net/manual/en/language.oop5.traits.php
Or in a less nicer way, one class can keep extending another class which implements what you want Class B extends A {}, Class C extends B {}, etc
This question already has answers here:
Why Java needs Serializable interface?
(13 answers)
Closed 9 years ago.
It was marked duplicate and i am expanding my question.
My question is how JDK internally serializing objects. How ObjectxxxStreams class serializing when the class implements that interface.?
I was looking into the serialization topic and deeply dived into the JDK Source code.
This was the source code of serialization Interface in JDK.
package java.io;
public interface Serializable {
}
There is nothing in this interface. What is the use of implementing this interface. I know that, to serialize a object we should implement this. I know what serialization is and how to work with that. But how serialization happens internally using ObjectInputStream and ObjectOutputStream. These classes are how related to serialization. Alternatively let us keep that those two classes are doing their duty. All my question is why we need to implement this empty interface to serialize and deserialize objects and how it works internally? Please explain in detail about this.
why we need to implement this empty interface ??
Its a design pattern
The marker interface pattern is a design pattern in computer science, used with languages that provide run-time type information about objects. It provides a means to associate metadata with a class where the language does not have explicit support for such metadata.
Serializable is marker interface
java.io.Serializable marker interface. It doesnot has any members defined it it. When a java class is to be serialized, you should intimate the java compiler in some way that there is a possibility of serializing this java class. In this scenario, marker interfaces are used.
Refer javadoc and Requirement of the serializable interface
Serializable is marker interface and marker interface does not have any methods but significance of it in method signature so that JVM can identify it.
java.io.Serializable it's what is called a marker interface. It doesn't declare any functionality, it just flags to other entities handling the implementing class that it's serialisable. For a good discussion about these subjects have a look at:
marker interface in java
Why Java needs Serializable interface?
we can't say that an interface which doesn't have any method is a marker interface. because the word "Marker" itself signifies the meaning that " marking something". so i say, the interface(whatever may be it's contents) by implementing which if a class gains some extra or specialized behavior like allow object to store into a persistence storage(Serializable) OR allow an object to make it's duplicate or raplica(Cloneable) OR allow a user to implement only one method(like run()) instead of implementing nearly 4 t0 5 methods in a subclass in thread programming(Runnable) .
these are the specialized behavior which can be gained by an object when it implements those interfaces which are nothing but called as MARKER INTERFACE.
CONCLUSION
Marker interface may or may not contain methods...
it can also be called as tagged interface,dummy interface,empty interface....
You can also refer which I found itself from SO:
Why Java needs Serializable interface?
This question already has answers here:
#interface and #protocol explanation?
(3 answers)
Class vs. Interface
(10 answers)
Closed 9 years ago.
I think that, except for the name, the protocols are much better suited to work as "interfaces" between classes. They do all that the #interfaces do (exposing properties and methods) and on top of that different classes can implement the same protocol which is a huge advantage in tandem with the dynamical nature of Objective-C. So why do we still use #interfaces? What advantages do they bring comparing with protocols? (I hope to get more out of this question than a "they are explicit in what they do" or "closed as not constructive".)
A delegate protocol needs to be defined as such
#protocol
//methods
#end
it can be put in any .h class, you just need to import i t whenever you are going to use it.
A protocol is not like a java interface, a protocol is an adapter that allows two classes to works together. Basically it says, if you want class A to send you messages about its state and actions these are the methods it will call on its delegate that you must implement. Its not like an interface because an interface says if you want to subclass this class you must implement these methods, the protocol says if you want to interact with this class you must implement these methods, so its somewhat different.
Objective C interfaces, delegates, and protocols
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Understanding #Protocols in Objective-C
Objective C protocols usage
I just started learning objective C and I do not seem to get my head around protocols very well. My understanding of Protocols in objective-C is that, you specify some method definition without actually writing the code for it. What that means is that, whoever decides to inherit my class must implement all my required methods.
My question here is that, Isn't protocols creating an extra over-head which is not really needed. If I need a method in my new class I can just implement it. Why do I need to inherit from a protocol?
Why cant I just ignore using protocols and just create methods as I need them.
Among other things, protocols are a way of letting the compiler help you avoid common errors. In this case, you can specify that one class will be calling specific methods on another class (often a delegate). The compiler will then check to make sure the other class (delegate) actually implements those methods and, if not, give you a warning message. Getting a message at compile time is preferable to crashing at runtime due to an undefined selector (method).
My question here is that, Isn't protocols creating an extra over-head which is not really needed.
there is no added overhead.
If I need a method in my new class I can just implement it. Why do I need to inherit from a protocol?
well, you can certainly declare a subclass for your common implementation, if that is an ideal path for your needs. if you try this, you will likely run into the issues i outline below.
protocols are often used because they are not actual physical types. it is an interface of methods and/or other protocols. usually, they are small and specialized. since objc does not offer multiple inheritance, protocols come in really handy for short extensions.
look at types which are complex subclasses and inherit one or more protocols; take NSString <NSCoding, NSCopying, NSMutableCopying, NSObject> as an example. knowing that objc uses single inheritance, consider how you would implement this class and 'inherit' from all those protocols - then consider the effect it would have on clients when passing those types after you have implemented this for all Foundation types. the class hierarchy and interfaces get very messy. the number of variations in many classes would explode to accommodate all those types as parameters. most people would stop before that point, and just drop type safety -- also a very bad idea. with a protocol, you can have "implements this interface" and type safety all in a simple language feature (multiple inheritance gets quite ugly quite quickly).
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.