Re: Visualizing Cocoa
Re: Visualizing Cocoa
- Subject: Re: Visualizing Cocoa
- From: Scott <email@hidden>
- Date: Sat, 09 Jun 2001 02:20:07 -0700
First off, Jeff, what's UML??
On to Visualizing Cocoa...
This is actually meant for anyone learning Cocoa/OOP.
OOP is to procedural programming what a guitar is to a piano.
In visualizing all of this, keep in mind there's more than one "thing"
you're visualizing.
That is, on the grand level, there's the class hierarchies of Cocoa, with
NSObject at the top and all other objects spilling off of it.
Then, there's (what I call) the control hierarchies of Cocoa, with
NSApplication at the top and all other objects spilling off of it. It's a
completely different picture drawn on a completely different page.
In trying to visualize how your app is working, as in if you were to step
through it line by line (overall flow of the application), you're dealing
with the control hierarchies. That is to say that you can somewhat forget
about the class hierarchies for a bit.
It's the idea of "who reigns supreme? Who's in charge here?" and the answer
(in Cocoa) is ultimately NSApplication. I tend to only think about class
hierarchies when I'm designing the objects for my app and then never think
about them again because it has so little to do with the flow of the
application.
Another way I look at it is: NSApplication is an object of the type
NSApplication. I.E. even though it inherits some of the same functionality
of, say, NSObject, it's no more an NSObject that it is an NSTextView. This
was an abstraction that took me some time to grasp, but it cuts down on the
amount of things you need to remember about NSApplication, for example.
Inheritance is cool, but it gets in the way. Another example, when you tell
your NSApplication to "becomeFirstResponder" (a method it inherits from
NSResponder) it doesn't pass control to an NSResponder object. That
NSApplication object itself handles the call.
It's easy to let extra dimensions of complexity confuse the issues, but when
it all comes down to it all programs simplify into processor commands in
serial procession. All any programmer ever does is twiddle bits, or push
them from one place to another. Any "style" of programming is only an
abstraction.
In procedural programming, there was the whole top-down approach. I'm
thinking of BASIC interpreters with primitive GOTO and GOSUB statements for
branching *within the same block of code*.
Then, "they" added procedures and functions to help break up large problems
into smaller chunks, but the top-down approach still applied. When this
happened, "they" said not to use GOTOs and GOSUBs, rather to make a new
function or procedure call.
In OOP, the top-down thingy is used exponentially. But, that doesn't mean
it makes the code for an app more complex. In fact, it makes it simpler
since problems are not only divided into even smaller chunks, but the idea
of responsibility is introduced. "What object (who) is responsible for
performing this action?"
One of the key points of OOP (which helps here) is in being able to separate
aspects of a program into individual distinct chunks. In a properly
designed app, you should be able to think of the objects as black boxes,
each doing what they do independent of each other. Objects are nouns,
methods are verbs.
When dealing with a new framework, or paradigm, it does take a little more
effort. In Cocoa, for example, there seems to be some Cocoa mojo going on
since things seem to magically happen. I guess that's part of the downside
for people new to Cocoa/OOP -- that Cocoa "offers so many things for free."
But even though there are mysteries, every program must obey the same basic
laws of computer processors -- namely "one operation at a time, please"
(even threads).
So, if you want to draw a whole cocoa app on paper, keep in mind that the
idea behind OOP (and procedural programming for that matter) is that you
shouldn't have to draw the whole thing -- at least on a code level. You
could draw a picture of the top-level which would be basic object
responsibilities. If you wanted to go as deep as code level branches and
conditionals, then you'd have to concentrate on individual objects instead
of the whole application.
Incidentally, a 3-d flyby of a cocoa app would be cool, but is probably not
feasible for anyone to do since it would be different for every app.
Personally, I would love to see the 'ole THINK Reference for Cocoa. "THINK
Cocoa." It was invaluable for "old" toolbox coding.
Sorry for the length, but I was hoping if I rambled a bit and said things
enough ways, something would click for someone.
Scott
------
"...there's no such thing as a plain name..."
http://www.domainjane.com
On 6/8/01 4:17 PM, "email@hidden" <email@hidden> wrote:
>
I think one of my big problems with trying to get a grip on Cocoa is
>
visualization--or rather the lack thereof! A simple procedural program
>
is essentially linear, it seems to me, which is to say one dimensional.
>
A more complex procedural program, one with conditionals or loops, is
>
two dimensional. In both cases it is child's play to diagram the
>
program on a sheet of paper. And therefor easy to Grok at a glance
>
what's going on. If I understand Cocoa right--a big IF since I feel
>
like I'm still waiting for the FIRST shoe to drop--the construct here is
>
three dimensional. It is exceedingly difficult to lay out a Cocoa
>
program on a sheet of paper. Bits and pieces, yes, but not an entire
>
app with all the objects and their outlets, delegates, protocols,
>
categories, et cetera. All interconnected in myriad ways! If this view
>
is correct, then I am fighting an uphill battle because I have _never_
>
been able to internally visualize three dimensions. Probably explains
>
why I took up photography. It would also explain why I was able to nail
>
Fortran and am still thrashing around with Cocoa. I "get" the basics:
>
polymorphism, encapsulation, dynamic binding, inheritance, the MVC
>
paradigm; but I can't visualize how all of these things hook up to solve
>
a problem.
>
>
I stand by my assessment that Apple's documentation leaves a lot to be
>
desired, and I have seen enough other people articulate this better than
>
I to know I'm right; however, given my visualization problem, it might
>
NOT be quite as bad as I first thought. So, does any of this ring a
>
bell with anyone; if you had, or have, this visualization problem how
>
did you get past it? What I really need is an application that will
>
display Cocoa in three dimensions, with or without red and blue glasses!
>
Animate the sucker and use it as a debugging/stepping tool, and who
>
knows what other wondrous things. Apple, Pixar, and Omni? Group
>
effort? Thoughts?
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev