On 14/04/2013, at 2:08 PM, YT <y...@redwoodcontent.com> wrote: > My struggle is partially due to my lack of experience in OOP. I just have not > written enough OO code as of yet. AND I'm very new to Objective-C. Hence my > lack of experience and working knowledge of Objective-C. > > extern int gFoobar; > > I understand that solution and its working for me right now.
I understand how tempting it is to go with whatever you can get working, especially when you're new to something. But in this case I believe you should resist the temptation and try and gain a little more understanding before you get too far down this road. GLOBALS ARE BAD NEWS. That is a pretty good rule and well worth sticking to. If you can get rid of globals (and you always can) then you should avoid them. There is NO problem in application programming that requires a global to solve it. Singletons are a much safer and more predictable means of achieving something that has global scope but prevents the hidden state/parameters problem that globals bring with them. Globals tie together parts of your program in ways that are not obvious, and as a result lead to bugs that can be extremely hard to track down. Decoupling each part of your app from every other part as far as possible is a good aim - globals instantly spoil that. Note that singletons don't lead to the same problem since the singleton object itself can be self-contained, and any state associated with it is at least boxed into that object, making debugging less of a problem. About the only excuse for globals are as a shortcut, e.g. NSApp instead of +[NSApplication sharedApplication] but even there it's arguably bad style. When I started in programming globals were the only variables there were (BASIC, circa 1979) and that's one reason why this language gained such a notorious reputation. It's a pity better languages perpetuated the existence of globals - if they're there, you should use them, right? Wrong. Getting rid of globals is arguably the single best thing you can do to improve the quality of your code as you move from first steps to more ambitious projects. > I have a PreRun Class that defines the object and I instantiate in main.m > just before the line > return NSApplicationMain(argc, (const char **)argv); This sounds like a bad idea to me. First, it means you're modifying main.m which is almost never necessary (there's a reason that this file is supplied in a standard form and placed into the 'support files' group, out of harm's way). Second it means you're wasting time instantiating an object that isn't needed for a long time yet, if ever. Using a singleton is cleaner, because it will only be instantiated at its first point of use (and if never used, will never be instantiated). > runs in main.m. The object instance persists the entire program run. THEN I > simply extern the global var that holds the pointer to the object in all of > the Class files where its required to access it. > > It may be a violation of OOP theory and application, it may be considered a > kludge BUT it works right now. I am willing to move to a conventional OOP > solution if I could figure out how. Many replies have shown you how - make a class method that returns the object, instantiating it once. Using a static variable within the class method ensures that it happens only once. You should import the class header where code makes use of the singleton, rather than use an 'extern' reference. > Reading Apple Documentation is like reading UNIX Man pages - groan, beat me > with a stick but don't make me read UNIX Man Pages - sigh. Better get used to it, because apart from voluntary help via this list and others, that's how you're going to learn about classes. In fact the docs aren't as terse as man pages, and there are plenty of other guides that show you how classes are used in a broader context. --Graham P.S. Tip: don't change the subject line when replying to postings, it prevents all the replies appearing in the same thread. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
