Hi Graham > Of course I'm simplifying when discussing MVC - I have rarely found a case > that's "pure" in the sense of just M, V and C as well, usually there are > several layers of controller and the data model is distributed among > different objects as well. I felt the game example might be advantageous > because it's a very simple game which is easily modelled, though even there I > ended up with 3 classes to do it. > > However, you may have hit the nail on the head in saying that a game is also > going to have to compromise because it's very much concerned with how the > thing is presented - the game *is* the presentation as much as anything - > there really isn't much you can do with the abstract data model in this case > except present it and interact with it. That said, my original non-animated > design was very clean in that all the on-screen stuff was restricted solely > to the view class.
This is where I prefer MVC's "little brother" MVP (Model View Presenter). Instead of having a Controller, which tends to be a mediator where Model and View are both "handled", the MVP pattern uses a Presenter, which can contain one or more Interactors. An Interactor is an object that is designed to handle "gestures" from the View. The Model is also slightly more complex, in that it contains a Command Set. A Command Set contains one or more Commands, each of which are designed to instigate one particular behaviour in the Value Object, held in the Model. The advantage of having a Value Object *inside* the Model is that the Model represents a particular scenario, in which the Value Object is a participant. Thus you can have an "Editing Model", a "Reporting Model", etc, all for the same Value Object. This further decomposition of the MVP design pattern can bring better clarity to the separation of concerns that such patterns are designed to accomplish. > I've now moved a number of "view-like" properties into the data model - > things like the background colour of the board and so forth - these were > originally conceived as properties that the view layer brought to the party; > the game logic does not need to know what colour the board is, but then > again, it's reasonable to think of this as a property of the board itself. By > doing this and letting the relevant model object create and manage the > CALayer that ultimately represents it on screen, I'm back to a clean design, > just one where the animation layers are woven into the model and controller > layers. I would definitely argue that this kind of design is not really "cleaning up" the design but, further, polluting it :-) In the Cocoa world, the Controller is a very important part of getting the non-UI code to connect to the UI elements and to respond to gestures made through those UI elements. I would venture to suggest that you are tending to think of the visual elements, put together in IB, as the View; I would rather think that you could look at creating View classes, which can hold the appearance "properties" and, to which, the UI elements should be bound to achieve their "look and feel". The MVP concept of Interactors, responding to UI gestures can be "emulated" by a Controller class, looking after the "input" side of things, whilst a "View Presentation" class would become the "output", from which UI elements get their data. I could go on further but would rather get to know if you think this makes any sense or needs further explanation. Joanna -- Joanna Carter Carter Consulting _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
