Proper Object Oriented application set up

Question

I am trying to learn my first programming language. Unfortunately I picked the Iphone to start. Thought it would be easy... ooops. Anyway 4 weeks later I've actually got a couple of working apps! kind of...

One of my apps that had a couple of text boxes and a couple of labels. Each person has a has button that starts a timer that decrements a label's text for a countdown.

Since I'm a retard, I have 2 separate timers that fire two separate methods that increment variables, play a song, update some labels etc, relative to each person. Not war and piece on the amount of code, but enough not to want to have to change both sets every time I figure out how to do something new.

What is a better way to set this up so that I can work with just one set of code per person? I get the whole "person" as an object idea and that it should be it's own class and that I should be probably sub classing it from all the reading I've done. I just don't know how to practically apply it with actual code.

Answer 1

We could talk for object oriented design for hours maybe months and years. Design principles exist by they are best learned and mastered through experience and a lot of practice.

If you need 2 timers each one calling 1 method that plays a unique role then you are probably stuck with the 2 timers. If there are common tasks/responsibilities in your two timers you could create an abstract timer that implements these common tasks and extend it for more specific behavior (method implementation).

I have found role based design helpful in many situations, but as i said you will have to practice and of course know the basics of object orientation and inheritance.

Answer 2

I think the first place to start is to realize that timers are (almost always) part of the interface and not part of the data model. Unless you have a very strange set of requirements, the timers shouldn't be related to your person data objects at all.

You want to maintain strict seperation between data and the interface. This is the key idea behind the badly misnamed Model-View-Controller pattern. It should be called Model-Controller-View to reflect that the controller mediates between the model and the view.

In your case, it sounds like you have a person object that is your data model. Ideally, that model will work without any direct links to any particular interface. A good data model will work with standard views, a web view or even a text based command line interface. It shouldn't matter to your model because it is only concerned with storing or manipulating data without regard to how it will be displayed or used.

Timers that update the interface belong in the controller because they have nothing to do with the data. The same data displayed in different interfaces would need different timers. You probably only need one timer that simply calls a method in the controller that updates all the interface elements as needed. In that method, the controller then fetches the data it needs to display from the appropriate objects in the data model (Instances of the person class in your case).

For example, suppose you have multiple person objects each with it's own countdown number. You would have the countdown value stored in the person object as a property. A single timer in the controller would fire once per second and call a method in the controller. That method would then ask each person object for its countdown value. Upon being asked for the value, the person object would automatically decrement the countdown value.

With this design, you could handle an arbitrarily large number of person objects, each with its own countdown attribute, with just a single timer and one method in the controller.