{"id":5217,"date":"2013-08-09T14:10:34","date_gmt":"2013-08-09T11:10:34","guid":{"rendered":"http:\/\/railsware.com\/blog\/?p=5217"},"modified":"2020-10-26T19:31:18","modified_gmt":"2020-10-26T16:31:18","slug":"using-forward-declaration-in-your-objective-c-projects","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/using-forward-declaration-in-your-objective-c-projects\/","title":{"rendered":"Using Forward Declaration In Your Objective-C Projects"},"content":{"rendered":"\"Screen<\/a>\r\n\r\nIf you’re new to Objective C and iOS development, this topic will explain some important things about Forward Declaration and will help you understand the concept behind it.\r\n\r\nSo, let’s skip the theory and jump right into a small example to see what it’s all about.\r\n\r\nWe’ll create a small project, that is quite useless, but will at the same time serve as a good example and cmake<\/code> utility.\r\n\r\nSo, here is…\r\n\r\nEmpty class Warrior<\/code>\r\n
\/\/ Warrior.h\r\n#import <Foundation\/Foundation.h>\r\n\r\n@interface Warrior : NSObject\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Warrior.m\r\n#import \"Warrior.h\"\r\n\r\n@implementation Warrior\r\n\r\n@end\r\n<\/pre>\r\nEmpty class Armor<\/code>\r\n
\/\/ Armor.h\r\n#import <Foundation\/Foundation.h>\r\n\r\n@interface Armor : NSObject\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Armor.m\r\n#import \"Armor.h\"\r\n\r\n@implementation Armor\r\n\r\n@end\r\n<\/pre>\r\nmain.m<\/code> as a driver – it just creates Warrior<\/code> object and prints it\r\n
\/\/ main.m\r\n#import <Foundation\/Foundation.h>\r\n#import \"Warrior.h\"\r\n\r\nint main() {\r\n    Warrior *w = [Warrior new];\r\n    NSLog(@\"%@\", w);\r\n    return 0;\r\n}\r\n<\/pre>\r\nAnd cmake<\/code> configuration file\r\n
\/\/ CMakeLists.txt\r\ncmake_minimum_required(VERSION 2.8)\r\n\r\nset(CMAKE_CXX_FLAGS \"${CMAKE_CXX_FLAGS} -framework Foundation\")\r\n\r\nset(SOURCES Warrior.m Armor.m main.m)\r\nadd_executable(fdecl ${SOURCES})\r\n<\/pre>\r\nSo, let’s build our simple program\r\n
$ cd directory_with_project\r\n$ cmake . # prepare makefile\r\n$ make # build\r\n<\/pre>\r\nWe see which modules are being built\r\n
Scanning dependencies of target fdecl\r\n[ 33%] Building CXX object CMakeFiles\/fdecl.dir\/Warrior.m.o\r\n[ 66%] Building CXX object CMakeFiles\/fdecl.dir\/Armor.m.o\r\n[100%] Building CXX object CMakeFiles\/fdecl.dir\/main.m.o\r\nLinking CXX executable fdecl\r\n[100%] Built target fdecl\r\n<\/pre>\r\nAnd now we’ll add an ability to wear armor\r\n
\/\/ Warrior.h\r\n@interface Warrior : NSObject\r\n\r\n- (void)wearArmor:(Armor *)armor;\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Warrior.m\r\n#import \"Warrior.h\"\r\n\r\n@implementation Warrior\r\n{\r\n    Armor *_armor;\r\n}\r\n\r\n- (void)wearArmor:(Armor *)armor\r\n{\r\n    _armor = armor;\r\n}\r\n\r\n@end\r\n<\/pre>\r\nRemember this state, we’ll get back to it later.<\/i>\r\n\r\nWe need to inform compiler about the Armor<\/code> class in order to compile these changes.\r\n\r\nThe first approach is to use #include\/#import<\/code> statements and it’s being used by a lot of developers.\r\n\r\nSo let’s do it\r\n
\/\/ Warrior.h\r\n#import \"Armor.h\"\r\n\r\n@interface Warrior : NSObject\r\n\r\n- (void)wearArmor:(Armor *)armor;\r\n\r\n@end\r\n<\/pre>\r\nand build\r\n
$ make\r\nScanning dependencies of target fdecl\r\n[ 33%] Building CXX object CMakeFiles\/fdecl.dir\/Warrior.m.o\r\n[ 66%] Building CXX object CMakeFiles\/fdecl.dir\/main.m.o\r\nLinking CXX executable fdecl\r\n[100%] Built target fdecl\r\n<\/pre>\r\nLooks good, but let’s add some property to our instance of Armor<\/code> class, e.g. ‘is it magical?’\r\n
\/\/ Armor.h\r\n#import <Foundation\/Foundation.h>\r\n\r\n@interface Armor : NSObject\r\n\r\n- (BOOL)isMagical;\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Armor.m\r\n#import \"Armor.h\"\r\n\r\n@implementation Armor \r\n\r\n- (BOOL)isMagical \r\n{\r\n    return YES;\r\n}\r\n\r\n@end\r\n<\/pre>\r\nand let’s build our program again\r\n
$ make\r\nScanning dependencies of target fdecl\r\n[ 33%] Building CXX object CMakeFiles\/fdecl.dir\/Warrior.m.o\r\n[ 66%] Building CXX object CMakeFiles\/fdecl.dir\/Armor.m.o\r\n[100%] Building CXX object CMakeFiles\/fdecl.dir\/main.m.o\r\nLinking CXX executable fdecl\r\n[100%] Built target fdecl\r\n<\/pre>\r\nGood news is that the build of main.m<\/code> was successful. There’s one thing though. Despite of the fact that the build has been successful, workflow has not been optimal – main doesn’t use Armor<\/code>, therefore, it must know nothing about this class.\r\n\r\nOk, let’s get back to the state where we’ve added wearArmor:<\/code> method, but haven’t included Armor<\/code> yet.\r\n\r\nNow we’ll go another way:\r\n\r\nUse #import<\/code> at implementation (Warrior.m<\/code>) and forward declaration (@class Armor;<\/code>) at header (Warrior.h<\/code>)\r\n
\/\/ Warrior.h\r\n@class Armor;\r\n\r\n@interface Warrior : NSObject\r\n\r\n- (void)wearArmor:(Armor *)armor;\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Warrior.m\r\n#import \"Armor.h\"\r\n\r\n@implementation Warrior\r\n{\r\n    Armor *_armor;\r\n}\r\n\r\n- (void)wearArmor:(Armor *)armor\r\n{\r\n    _armor = armor;\r\n}\r\n@end\r\n<\/pre>\r\nMake it (make sure that you’ve removed isMagical<\/code> from Armor<\/code>, we need this to get the same experience as before)\r\n
$ make\r\n<\/pre>\r\nAdd isMagical<\/code> method again\r\n
\/\/ Armor.h\r\n#import <Foundation\/Foundation.h>\r\n\r\n@interface Armor : NSObject\r\n\r\n- (BOOL)isMagical;\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Armor.m\r\n#import \"Armor.h\"\r\n\r\n@implementation Armor \r\n\r\n- (BOOL)isMagical \r\n{\r\n    return YES;\r\n}\r\n\r\n@end\r\n<\/pre>\r\nBuild and check the results\r\n
$ make\r\nScanning dependencies of target fdecl\r\n[ 33%] Building CXX object CMakeFiles\/fdecl.dir\/Warrior.m.o\r\n[ 66%] Building CXX object CMakeFiles\/fdecl.dir\/Armor.m.o\r\nLinking CXX executable fdecl\r\n[100%] Built target fdecl\r\n<\/pre>\r\nNow it looks much better. Did you notice an important difference?\r\n\r\nIn our example we have only three modules, so the benefit is barely noticeable.\r\n\r\nThings change dramatically when you’re working on a large project consisting of numerous classes and modules with lots of dependencies and complex relationships. Every time you add some small thing into the project you’ll have to wait more and more for compiler to re-build all the things. This is where you can get the full benefit from utilising FD approach.\r\n\r\nYou can experience exactly the same problems when using @protocol<\/code>s as delegates.\r\n
\/\/ Awesome.h\r\n@class Awesome;\r\n\r\n@protocol AwesomeDelegate\r\n\r\n- (void)awesome:(Awesome *)awesome didFailed:(NSError *)error;\r\n\r\n@end\r\n\r\n@interface Awesome : NSObject\r\n\r\n@property (weak, nonatomic) id delegate;\r\n\r\n@end\r\n\/\/ and then include this header into each class that want to be an awesome delegate\r\n<\/pre>\r\nSo the right way is to use different files for a delegate and a class, which use this a delegate:\r\n
\/\/ AwesomeDelegate.h\r\n@class Awesome;\r\n\r\n@protocol AwesomeDelegate\r\n\r\n- (void)awesome:(Awesome *)awesome didFailed:(NSError *)error;\r\n\r\n@end\r\n<\/pre>\r\n
\/\/ Awesome.h\r\n@protocol AwesomeDelegate;\r\n\r\n@interface Awesome : NSObject\r\n\r\n@property (weak, nonatomic) id delegate;\r\n\r\n@end\r\n<\/pre>\r\nTo summarise, keep in mind the importance of forward declaration, as it might save your time dramatically with every build you run for the project.\r\n\r\nIn short, your goal is to create as clean interface as possible, that would be readable and maintainable by others in the future. Therefore, it must contain only imports of a base class and protocols, which current class conforms to. For all the rest there’s… no, not MasterCard, forward declaration in this case.","protected":false},"excerpt":{"rendered":"
If you’re new to Objective C and iOS development, this topic will explain some important things about Forward Declaration and will help you understand the concept behind it. So, let’s skip the theory and jump right into a small example to see what it’s all about. We’ll create a small project, that is quite useless,…<\/p>\n","protected":false},"author":55,"featured_media":9471,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["AlexDenisov"],"class_list":["post-5217","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2017\/12\/Using-Forward-Declaration.png","article_background":"","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5217","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=5217"}],"version-history":[{"count":46,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5217\/revisions"}],"predecessor-version":[{"id":12828,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/5217\/revisions\/12828"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/9471"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=5217"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=5217"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=5217"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=5217"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}