Domanda

I'm building an arithmetic app & in it there are subclasses of NSObject for Numbers and Digits.Both of these have corresponding view objects which take a Datasource (either number or digit) and a delegate, the view controller.

I have found that it is useful in getting the views & the model to work together to set the digit views as a property of their corresponding digits.

For example, the Number class has an NSMutableArray property that holds its digits.

If I want to find the size for the corresponding NumberView, I write can write code like this in the controller:

-(void) updateNumberViewFrameSize:(ACNumberView*) sender
{
    NSUInteger i;
    float width = 0, height = 0;
    for (ACDigit* digit in [sender.dataSource returnNumberViewDataSource].digitArray)
    {
        width += digit.digitView.size.width;
        height += digit.digitView.size.width;
    }
    sender.frame = CGRectMake(sender.frame.origin.x, sender.frame.origin.y, width, height);
}

The code works just fine, but I feel that it is not good practice to hold that pointer to the view from the model, even if the model isn't using it itself.

If it is bad practice, what are the potential pitfalls, and Is there a better way to achieve this type end ?

È stato utile?

Soluzione

First: You are right. This is no good design.

Second: You calculate the size of a number view inside the model. But a number view should know its size itself. It knows the number through its data source and can get the digits. So it has all information for calculating its size.

To show the problem, just imagine (even this situation is on iOS not that common), that you display the same number at two places (= with to different number views). This would break your model. Why?

Solution: Put all code related to a graphic state (drawing, size, …) into the number view and digit view. On half of the way that will be additional work. But at the end, when every code is migrated to the view layer, it is as easy as computing it inside the model.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top