Existence of objects

  • Not sure how to ask this question.

    In some thread an object is created with a set of methods.
    Lets call this object objA.

    Later in time another objected is created perhaps in another thread (not sure if this note is relevant).
    Lets call this object objB.

    Now objB needs to call a method in objA.

    Since objB came into being after objA how does objB detect that objA exists before attempting to call one of its methods?

    YT
  • On May 5, 2013, at 21:43 , YT <yt...> wrote:

    > In some thread an object is created with a set of methods.
    > Lets call this object objA.
    >
    > Later in time another objected is created perhaps in another thread (not sure if this note is relevant).
    > Lets call this object objB.
    >
    > Now objB needs to call a method in objA.
    >
    > Since objB came into being after objA how does objB detect that objA exists before attempting to call one of its methods?

    There's no magic here. If objB is to be aware of the existence of objA, there must be a reference to objA stored somewhere. (In fact, normally, there has to be a [strong] reference to objA store somewhere in order for objA to continue to exist. Otherwise, it's leaked or deallocated, depending on how you're handling memory management.)

    Usually, the reference to objA is held by some other object, whose existence is known to B. For example, most applications have an application delegate object that exists for the lifetime of the app, so this object could be designed to hold a reference to objA.

    If necessary, you can create a global variable to hold the reference to objA, but this would normally be done only if there were no context (that is, object graph) to which objA naturally belongs.
  • Regarding "there must be a reference to objA stored somewhere" I kinda figured as much - BUT - was hoping there might be another way especially since there are those OO purists that condemn the use of any sort of "globalness".

    What I have is a view within the main window that is a Quartz 2D graphical "thing" and I want to have a set of UI elements that a user interacts with to change the graphical presentation.
    Well the UI elements are in the Delegate and the Graphical thing is in the view.  The UI elements need to call methods in the view to change the graphical thing.

    So from what I think I read in your post I have to "store" objA's ID in a common ancestor.
    I'll have to ponder how to achieve that.

    YT

    On May 5, 2013, at 9:49 PM, Quincey Morris <quinceymorris...> wrote:

    > On May 5, 2013, at 21:43 , YT <yt...> wrote:
    >
    >> In some thread an object is created with a set of methods.
    >> Lets call this object objA.
    >>
    >> Later in time another objected is created perhaps in another thread (not sure if this note is relevant).
    >> Lets call this object objB.
    >>
    >> Now objB needs to call a method in objA.
    >>
    >> Since objB came into being after objA how does objB detect that objA exists before attempting to call one of its methods?
    >
    > There's no magic here. If objB is to be aware of the existence of objA, there must be a reference to objA stored somewhere. (In fact, normally, there has to be a [strong] reference to objA store somewhere in order for objA to continue to exist. Otherwise, it's leaked or deallocated, depending on how you're handling memory management.)
    >
    > Usually, the reference to objA is held by some other object, whose existence is known to B. For example, most applications have an application delegate object that exists for the lifetime of the app, so this object could be designed to hold a reference to objA.
    >
    > If necessary, you can create a global variable to hold the reference to objA, but this would normally be done only if there were no context (that is, object graph) to which objA naturally belongs.
    >
  • On May 5, 2013, at 22:24 , YT <yt...> wrote:

    > What I have is a view within the main window that is a Quartz 2D graphical "thing" and I want to have a set of UI elements that a user interacts with to change the graphical presentation.
    > Well the UI elements are in the Delegate and the Graphical thing is in the view.  The UI elements need to call methods in the view to change the graphical thing.

    What you've got is a MVC (model-view-contoller) pattern, which is very typical for Cocoa apps.

    The view is everything in the window, including the graphical thing and any controls (radio buttons, check boxes, etc) that the user interacts with to change the presentation of the graphical thing.

    The model is the information in the app delegate, the information that the graphical thing presents.

    What you need to add now is the controller. Typically, this is a NSWindowController subclass. This controller is responsible for holding references that allow the view elements to locate the model, and perhaps each other.

    The controller obtains a reference to the model from the app delegate, and has outlets (references) to any views it needs to access directly. The views find the controller via the nib's "File's Owner", or via outlets of their own. The model shouldn't contain any direct references to views or other objects in the nib.

    Note that the settings controlling the graphical presentation *could* be in the app delegate, or they *could* be in the window controller. Often, the window controller is the best place for them.

    (Ask yourself this question: If I was ever to allow a *second* window onto the same data, and the user was to change the UI elements controlling the presentation, what should happen? Should the presentation change in both windows, or just in the one where they were changed? If the answer is "both windows", you should keep the settings in the app delegate. If the answer is "only the window where they were changed", you should keep those settings in the window controller.)
  • Oh yeah - da-  the MVC

    This past week I've been totally focused on learning how to write code that uses the Quartz 2D library and so totally forgot the MVC design pattern.  Plus I've read about the MVC pattern it in the docs but have not configured one myself in Cocoa.

    That was a good pointer, thanks.

    YT

    On May 5, 2013, at 10:38 PM, Quincey Morris <quinceymorris...> wrote:

    > On May 5, 2013, at 22:24 , YT <yt...> wrote:
    >
    >> What I have is a view within the main window that is a Quartz 2D graphical "thing" and I want to have a set of UI elements that a user interacts with to change the graphical presentation.
    >> Well the UI elements are in the Delegate and the Graphical thing is in the view.  The UI elements need to call methods in the view to change the graphical thing.
    >
    >
    > What you've got is a MVC (model-view-contoller) pattern, which is very typical for Cocoa apps.
    >
    > The view is everything in the window, including the graphical thing and any controls (radio buttons, check boxes, etc) that the user interacts with to change the presentation of the graphical thing.
    >
    > The model is the information in the app delegate, the information that the graphical thing presents.
    >
    > What you need to add now is the controller. Typically, this is a NSWindowController subclass. This controller is responsible for holding references that allow the view elements to locate the model, and perhaps each other.
    >
    > The controller obtains a reference to the model from the app delegate, and has outlets (references) to any views it needs to access directly. The views find the controller via the nib's "File's Owner", or via outlets of their own. The model shouldn't contain any direct references to views or other objects in the nib.
    >
    > Note that the settings controlling the graphical presentation *could* be in the app delegate, or they *could* be in the window controller. Often, the window controller is the best place for them.
    >
    > (Ask yourself this question: If I was ever to allow a *second* window onto the same data, and the user was to change the UI elements controlling the presentation, what should happen? Should the presentation change in both windows, or just in the one where they were changed? If the answer is "both windows", you should keep the settings in the app delegate. If the answer is "only the window where they were changed", you should keep those settings in the window controller.)
    >
  • On May 5, 2013, at 11:33 PM, YT <yt...> wrote:

    > This past week I've been totally focused on learning how to write code that uses the Quartz 2D library and so totally forgot the MVC design pattern.  Plus I've read about the MVC pattern it in the docs but have not configured one myself in Cocoa.

    It takes a bit of practice to get into the MVC mindset: sometimes it can feel like creating unnecessary levels of abstraction, but it's worth it. One good way to think about it is as if you were splitting yourself into a whole team of engineers. Put yourself in the shoes of the guy/gal who doesn't know anything about graphics or UI programming but needs to implement the core "thing" your app is about, and design the API s/he would implement, that the UI programmer(s) can then use as a black box and build the interface to.

    And as always, I highly recommend the book "Design Patterns" by Gamma et al, which is a recipe book of these sorts of techniques — MVC is one of the best-known ones, but there are dozens of them.

    —Jens
  • If you would benefit from looser coupling between objects, consider NSNotification and friends.

    Kirk Kerekes
    (iPhone)
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today