I am just starting to learn Objective-C (I've been programming in C+
+ for about 15 years).
My first "project" in Objective-C is to port something I wrote
entirely in C++.
What I am finding is that my "OO" C++ implementation does not map
very well to Objective-C.
For example, in C++ I have an abstract class that contains methods
(some with a default implementation and some without) as well as
data members. In Obj-C this is a total no-no from what I can
gather (a formal protocol can only contain method declarations).
So what is stopping you from implementing an abstract base class in
your ObjC implementation? Is your C++ implementation using multiple
inheritance for something other than protocol declaration?
It's true that there's no "pure virtual" declaration for abstract
classes in ObjC. In fact, the ObjC language doesn't have any special
support for abstract classes at all... They're simply a convention.
(Similarly C++ doesn't have any special support for protocols at
all... They're implemented using multiple inheritance by convention.)
I guess I could create a "base" class that implements the protocol
and then have all of my "concrete" base classes inherit from that
base. ??
Yes, that's a perfectly fine approach. Is this undesirable for some
reason?
You could also add a category to some base class (i.e. NSObject) to
provide "default" implementations of any method you'd care to invent.
This is acceptable for applications, but is frowned upon for
frameworks (because it further "pollutes" the [already quite busy]
NSObject namespace).
I won't argue that much of the "OO" in C++ is syntactic sugar, but
unfortunately I've been thinking that way so long that it is
difficult to think about an object hierarchy without having true
abstract classes.
I'm not following what you're saying is missing here... The only
abstract class support that C++ has and ObjC lacks, AFAIK, is a
compile-time warning if you try to instantiate one. Oh, and compile-
time warnings if a concrete subclass fails to implement a "subclass
responsibility" method. Those are fine features, but I would hardly
say their absence makes abstract classes untenable in ObjC...
Now, if what you're meaning is that it's multiple inheritance you're
having trouble "kicking", that's a horse of a different color...
I wonder if many people just implement their model classes in C++
then write their view/controller classes in Obj-C?
Only masochists... ;-)
But seriously, ObjC++ (which is the most straightforward way to
accomplish the above) exists out of expedience, not because there's
any particular synergy in the hybrid. Consider that if you use C++
for your model classes you are excluding the possibility of using
Cocoa's nifty controller classes, which depend on Key-Value
Observation (KVO).
Any suggestions/advice/clarifications would be greatly appreciated!
As when transitioning between any two languages, it pays to be
prepared to learn and adopt some new idioms along with the new
syntax. Yes both C++ and ObjC are Turing-complete, implying therefore
that anything you can do in one *can* be done in the other... But the
whole reason these two descendants of C have evolved in such
different directions is to better support idioms / design patterns /
techniques that their respective communities felt were important.
I would suggest that your *first* project in ObjC be more along the
lines of a tutorial -- say building a simple Cocoa GUI application
that uses bindings... and perhaps even Core Data. *Then* hopefully
you will have a better sense of how to leverage the things ObjC helps
you do, and have a better picture of how your application would be
most naturally expressed using ObjC and its many frameworks. And then
perhaps the many differences between ObjC and C++ will seem less
annoyingly arbitrary... But that's just my 2 cents... ;-)
HTH,
-- Kaelin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
