Which class is Abstract class in Objective-C, I have read some doc where NSObject is Abstract class, but we can create instance of NSObject, then how it is follow the abstract class rule.
NSObject *obj = [[NSObject alloc] init];
NSLog(#"description = %#",[obj description]);
NSLog(#"class name = %#",[obj class]);
Please advice.
And also I heard another one Abstract Class in Objective-C, what is the name of the class?
Objective-C has no compile time restraint against instantiating abstract classes. See Creating an abstract class in Objective-C
In Objective-C there is no language level concept of an abstract class. You have to read the documentation for a class to find out if it should be treated as an abstract class. There are a few such classes in Cocoa, e.g. NSObject, NSProxy and NSOperation. It's more common for behaviour to be defined in protocols rather than in abstract classes.
The Cocoa framework contains to root classes (i.e. class which do not have superclasses). NSObject is one root class and NSProxy is the other. NSProxy does not implement an init method which means an exception is raised when you attempt to create an instance.
Related
I have a class XMLUtil, that wraps some xml parsing functionality. The class has one generic parameter T. The class also acts as the NSXMLParserDelegate to the NSXMLParser delegator.
class XMLUtil<T>: NSObject, NSXMLParserDelegate{
...
...
init(){
parser = NSXMLParser(data: NSData)
parser.delegate = self
parser.parse()
}
...
...
//delegate method implementations
}
The problem:
When my XMLUtil class is a generic class, the delegate methods never get called. They do however, when I implement the XMLUtil class without generic parameters
These two questions seem to be of similar nature
Swift Generic class as delegate
NSURLConnection Delegate Methods Not Called In Generic Class
Is there anything in the documentations that would explain this behavior? Is this intended or is it a bug?
When my XMLUtil class is a generic class
But Objective-C knows nothing of generic classes. So there is no way to show your XMLUtil class to Objective-C. Thus, it cannot serve as NSXMLParser's delegate; NSXMLParser is an Objective-C class and cannot see your XMLUtil class if it is generic.
One easy way to see this is to try to mark your XMLUtil class as #objc. You will fail; the compiler will stop you. There is no way to show this class to Objective-C.
I've never worked with objective C but have a fair bit of experience with C++.
What exactly is the difference between a superclass and a protocol in objective C? I read that a protocol is essentially a pure virtual class, but is that it? Is a protocol simply a specific type of superclass?
A protocol is a contract a class is going to conform to. When a class conforms to a protocol it tells the compiler that it will implement all the methods and all the properties declared in the protocol.
In Objective-C the class additionally needs a superclass. In a lot of cases this is NSObject. The superclass implements already a lot of methods (like isEqual:). A protocol never implements any methods or defines any property.
A protocol tells which properties/operations a class must implement. A superclass implements them and you can add your own stuff on top.
A protocol defines a set of method definitions that a class or struct must implement, very much like a Java interface.
A superclass is the class from which a given class inherits its method definitions, the implementation for those methods, and the instance and class properties.
I know usually, when you want to call a method on another object, you do:
NewObject *object = [NewObject alloc]init];
[object callMethod];
But I created a class that isn't an object itself meaning it doesn't have properties or memory management. It has a couple methods that calculate some stuff.
From any other class, all I have to do is import the header for this class and do:
#import "MyClass.h"
[MyClass callMethod];
Why in this case do I not have to alloc init? It works just fine.
It sounds like you are trying to call a class method. These are methods which have been defined as:
+(void) myStaticMethod;
instead of
-(void) myMethod;
The plus sign indicates that the method does not use any fields, and thereby does not need to instantiate the object.
In your example, "object" is an instance of a class "NewObject" which has been allocated memory and initialized. Where-as your example, "MyClass" is only a class which because it has static members declared as above, does not need to be instantiated.
Class methods provide a nice way to combine a bunch of related functions into one place, rather than having them spread out in the regular namespace, as would usually be done in straight C. You can also have both class methods and instance methods in the same class, using the class ones when needed, and instantiating the class to use the instance ones when needed.
EDIT: Changed terminology to refer to class methods instead of static methods.
because you are calling a class method. You only need to alloc init objects. Classes only need to be included but not alloc inited. So you don't need to init an NSString class, say.
Edit:
Let's just have some nonsense examples:
+ (void)classMethod {
NSLog("Hi!");
}
[SomeClass classMethod]; // prints Hi!
- (void)instanceMethod { // (say it's an instance method of NSString)
NSLog(self);
}
[#"someNSString" instanceMethod]; // prints someNSString. But you need to have a string first, otherwise you cannot use this method.
There is a difference between "instance" methods (normal ones), that have to be called on an object and have access to self, and "class" methods (called static, in many programming languages), that are invoked on the class and thus do not have a self.
Class methods are similar to C++ static methods, in that they can be invoked without creating a concrete instance of the class. The usefulness of this is you can call a class's specialized factory methods to create a new instance; or, you can define a utility library under the scope of a class that may or may not provide concrete instances depending on the task.
Look at NSDate and NSNumber are good examples of this in the Foundation framework.
The following code using UIGestureRecognizer:
UIGestureRecognizer *gestureRecog = [[UIGestureRecognizer alloc]
initWithTarget:self
action:#selector(handletap:)];
[self.view addGestureRecognizer:gestureRecog];
can actually compile and run. I thought abstract class cannot be instantiated?
Abstract classes are not a language feature in Objective-C (unlike Java, for example), so it isn't something the compiler could enforce.
When a class is marked as abstract in the documentation, it is just a hint how it is intended to be used, but neither the runtime, nor the compiler will actually prevent you from instantiating it directly.
The section on abstract classes in the Objective-C Programming Language Guide actually states that NSView is an example of an abstract class that you may sometimes use without subclassing, so the concept as such is not as strict as in other languages/frameworks.
Thanks for omz's answer. This is the related excerpt from Apple's documentation:
Abstract Classes
Some classes are designed only or primarily so that other classes can
inherit from them. These abstract classes group methods and instance
variables that can be used by a number of subclasses into a common
definition. The abstract class is typically incomplete by itself, but
contains useful code that reduces the implementation burden of its
subclasses. (Because abstract classes must have subclasses to be
useful, they’re sometimes also called abstract superclasses.)
Unlike some other languages, Objective-C does not have syntax to mark
classes as abstract, nor does it prevent you from creating an instance
of an abstract class.
The NSObject class is the canonical example of an abstract class in
Cocoa. You never use instances of the NSObject class in an
application—it wouldn’t be good for anything; it would be a generic
object with the ability to do nothing in particular.
The NSView class, on the other hand, provides an example of an
abstract class, instances of which you might occasionally use
directly.
Abstract classes often contain code that helps define the structure of
an application. When you create subclasses of these classes, instances
of your new classes fit effortlessly into the application structure
and work automatically with other objects.
what is the difference between doing a class as subclass by inheritance and composition
Composition : the new class has the original class as an instance variable. The interface of the new class starts from the scratch. Only the properties and methods that the new class defines are available to the users of the class. The new class internally uses the old class object.
Subclass : the new class has all the properties and methods it's superclass defines. Any users can use the properties and methods. If the new class does not override them, the superclass implementation is automatically called. The subclass may add new properties or methods.
Usually subclassing is more helpful, but some cases composition can be helpful ( for example when working with class clusters).
http://www.artima.com/designtechniques/compoinh.html
http://www.mapleshirefarm.com/eric/CompositionVsInheritance.html
http://www.apl.jhu.edu/Notes/LMBrown/resource/Composition.pdf
and concisely...
http://www.codeproject.com/Articles/80045/Composition-VS-Inheritance.aspx