When it comes to object classes and inheritance Android and iOS are extremely similar, as can be seen in the two quotations below. The one on the left describing Android and the one on right describing iOS.
When it comes to instantiation we don't create an instance of Ragtop in iOS (as we would do in Android), we instead create an instance of Car but make sure that where it is instantiated the controller has imported "Ragtop_Car.h" in addition to "Car.h".
Note: If we wanted to create an instance of a class named Ragtop, then we'd need to subclass Car rather than extend it. This would enable us to override its methods in the way Android is able to do through extension.
It should also be noted that Apple does not particularly encourage class extensions.
See the first part in this series of blogposts here: Android through the eyes of iOS: Classes and Methods (Part 1).
| “The Java class Object—java.lang.Object—is the root ancestor of every class. Every Java object is an Object. If the definition of a class does not explicitly specify a superclass, it is a direct subclass of Object. The Object class defines the default implementations for several key behaviors that are common to every object. Unless they are overridden by the subclass, the behaviors are inherited directly from Object.” Programming Android | "NSObject is the root class of most Objective-C class hierarchies. Through NSObject, objects inherit a basic interface to the runtime system and the ability to behave as Objective-C objects." iOS Developer Library (Apple) |
Object equality
Objects also have similar ways of providing information about themselves despite being written with a different syntax. These include the following.| The toString() function available to every Object as a way to describe its location on the heap. This Mednieks et al. tell us can be overridden to provide useful debug information. | toString() is an eqivalent to the Objective-C method description. |
| equals and hash methods for measuring exact equality of objects, i.e. the same instance at the same location. | iOS has a range of methods available in the NSObject Protocol for measuring equality, e.g. isEqual:, it also has a hash method like Android. |
Class extension
Classes can be extended in Android and iOS, but this happens in slightly different ways and for slightly different purposes. This can be seen in my iOS translation of Mednieks et al.'s extension example from Programming Android.| public class Car { public void drive() { System.out.println("Going down the road!"); } } public class Ragtop extends Car { // override the parent's definition. public void drive() { System.out.println("Top down!"); // optionally use a superclass method super.drive(); System.out.println("Got the radio on!"); } } | Car.h
#import <Foundation/Foundation.h> @interface Car : NSObject // make public the drive method in the main class -(void)drive @end Car_Ragtop.h #import "Car.h" @interface Car () // We declare the method here to make it public but it must be written out in the Car.m file, since there is no Car_Ragtop.m file automatically created, and we shouldn't try to create one. This means we cannot have a second drive method and must call it something unique -(void)ragtopDrive; @end Car.m #import "Car.h" @implementation Car -(void)drive { NSLog(@"Going down the road!); } -(void)ragtopDrive { NSLog(@"Top down!); [self drive]; NSLog(@"Got the radio on!); } @end |
When it comes to instantiation we don't create an instance of Ragtop in iOS (as we would do in Android), we instead create an instance of Car but make sure that where it is instantiated the controller has imported "Ragtop_Car.h" in addition to "Car.h".
Note: If we wanted to create an instance of a class named Ragtop, then we'd need to subclass Car rather than extend it. This would enable us to override its methods in the way Android is able to do through extension.
It should also be noted that Apple does not particularly encourage class extensions.
Bibliography
Programming Android: Java Programming for the New Generation of Mobile Devices by Zigurd Mednieks, Laird Dornin, G. Blake Meike and Masumi Nakamura.See the first part in this series of blogposts here: Android through the eyes of iOS: Classes and Methods (Part 1).
Comments
Post a Comment