• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Bindings and object-pointer keys
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bindings and object-pointer keys


  • Subject: Re: Bindings and object-pointer keys
  • From: "I. Savant" <email@hidden>
  • Date: Sun, 30 Dec 2007 12:00:43 -0500


There is an array of 'Person' objects, each of whom has a name and a job. Each Job is uniquely defined by a title (i.e. two Jobs are considered equal if their title strings are equal) and has a salary. Every person who shares a job has a pointer to exactly the same job object.

This is a bad idea for several reasons. I'll touch on the most relevant: This is poor object-oriented design. There should be a separate Job class. You don't need to compare equality if you can do something like this:


(personOne.job == personTwo.job)

Your approach is needlessly complicated, difficult to maintain, and prone to huge problems if your project gains complexity. Separate and encapsulate things properly from the beginning and you'll have far fewer headaches.

Also, in business, a salary is typically not a function of a job that can have more than one position within a company. What if you have two "Computer Technicians" and one has been with the company for a few years while the other just started? If you're not giving your employees slight raises each year, they're going to quit. How do you maintain separate scales? Salary is typically assigned to the employee (your Person instances).

In general, your model seems as though it could benefit from Core Data. I strongly recommend checking it out. With proper design, Job has a to-many relationship to Person and Person has a to-one relationship to Job. Core Data takes care of this kind of thing automatically and everything beautifully fits together.

The salary column won't update until the next time the employees table becomes key.

The reason for this problem is also rather simple -- technically, the person's job property (to which the 'salary' table column is bound) doesn't change.

You need to define a dependent key. Look up - setKeys:triggerChangeNotificationsForDependentKey: in the documentation.


More generally, you need to spend some time with the documentation. Look up "Key Value Observing" and read all related material. If you don't understand this, best not to use Bindings or Core Data at all. They are prerequisite knowledge.

--
I.S.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Bindings and object-pointer keys
      • From: Seth Pellegrino <email@hidden>
References: 
 >Bindings and object-pointer keys (From: Seth Pellegrino <email@hidden>)

  • Prev by Date: Bindings and object-pointer keys
  • Next by Date: Re: cocoa bindings NSTableColumn to @allKeys?
  • Previous by thread: Bindings and object-pointer keys
  • Next by thread: Re: Bindings and object-pointer keys
  • Index(es):
    • Date
    • Thread