How to organize classes in UIView/Subview responding chain? - objective-c

Question

I often heard, that it is not good to organize classes the way every class knows every other class.
So I try to let the classes that are as a property in other classes not know about their parents. But with UIView I can't make it happen.
The question comes from a more generic background, because the problem occurs not only on UIViews.
If I have a car as object with 4 wheels as 4 instance variables and when the left front wheel bursts. The left rear wheel should get a message. How should I design the system in a good way?
An example with UIView in Objective-C:
I have an custom UIView filling the whole screen. managing all the layout. Let's say only 2 subviews keep it simple.
#interface BackgroundView : UIControllerView {
CustomViewA *buttonA;
CustomViewB *buttonB;
}
#end
#interface CustomViewA : UIButton
#interface CustomViewB : UIButton
Now if someone presses button A, button B should do something (e.g. turn red).
There are several options I see:
Set the delegate of button A to button B, so all event of A goes to implementation file of B. Problem if not all events have to do with button B.
Create a singleton of BackgroundView and let button A get the property of button B or call a method in BackgroundView that does forward my call to button B. Problem if I want more than one Background, could create a even higher class to have the two BackgroundViews (doesn't sound nice).
Call parent implemented for UIViews and then like 2. call a method or change it directly. Problem when not using UIView, copy the functionality to other 'parent' classes ?
Is there a better way of solving such a problem? Or can I optimize one method greatly?

Answer 1

#Odrakir mentions Model-View-Controller here, and they're right -- that should be your first stop. In case it helps, here's how you might apply that pattern to your example:
You have a model class with a property color. In a document-based application, the document typically is the model. In a non-document-based application, it's common to hang the model off of the application delegate instance. For simplicity's sake, let's say we're in the latter case. You might have the following classes:
// "Model"
#interface MyModel : NSObject
#property (nonatomic, readwrite, copy) UIColor* color;
#end
// AppDelegate
#interface MyAppDelegate : UIResponder <UIApplicationDelegate>
#property (nonatomic, readonly, retain) MyModel* model;
#end
// "View"
#interface CustomViewA : UIButton
#end
#interface CustomViewB : UIButton
#end
// "Controller"
#interface MyViewController : UIViewController
#property (nonatomic, readwrite, assign) IBOutlet UIView* buttonA;
#property (nonatomic, readwrite, assign) IBOutlet UIView* buttonB;
- (IBAction)doActionA: (id)sender;
- (IBAction)doActionB: (id)sender;
#end
The basic pattern is this: Actions from the view trigger model-modifying actions by the controller (the target/action pattern). To achieve this, you would hook them up by connecting the action of button A to -doActionA: on the controller ("File's Owner" in IB) and (likewise for B). Then the action methods on the controller, when triggered, should modify the model, and invalidate any views that would need to be redrawn as a result of the model change. You might do this by plugging the views into IBOutlets on the controller and having the controller call [self.buttonA setNeedsDisplay]. Then, when your view draws, it should read, from the model, any state that it needs to draw correctly.
It's worth mentioning that on MacOS, you can eliminate the manual invalidation step by using bindings to link the view to the model. In that case, changes to the model will automatically invalidate the view. iOS/UIKit doesn't have bindings, so you have to do this invalidation by hand.

Answer 2

Probably all that logic belongs in a ViewController who knows everything about the views he controlls but the views don't know anything about the view controller or about each other.
Views should communicate with the view controller through delegation (or target-action) and is the view controller the one that should make decisions and maybe, forward messages to other views.
By the way, take a look at Stanford courses in iTunes University. I think it's the first or second class where they talk about MVC (Model View Controller). It's going to help a lot: https://itunes.apple.com/us/course/coding-together-developing/id593208016