On Wed, Oct 07, 2009 at 09:09:29PM +0100, David Otton wrote: > 2009/10/7 Eric Bauman <baum...@livejournal.dk>: > > > > On 7/10/2009 7:25 PM, David Otton wrote: > >> > >> 2009/10/7 Eric Bauman<baum...@livejournal.dk>: > >> > >>> Any thoughts would be much appreciated! > >> > >> One observation. "Model" isn't a synonym for "Database Table" - models > >> can be anything that encapsulates business logic. Requiring all your > >> models to inherit from Model is probably a bad idea. > > > > Thank-you for responding. > > > > Out of curiosity, why is this a bad idea? Is it also bad for views & > > controllers? > > Well, the way MVC has traditionally been approached is that the VC bit > is a thin interface skin, concerned with I/O, while the M is the bulk > of the program - the bit that does the heavy lifting. (You'll often > hear this called "Fat Model, Skinny Controller"). So you could have a > lot of models, that do a lot of disparate stuff - not just database > tables. > > To give you an example, imagine an application that texts people when > a new book by their favourite author is coming out. > > It's going to have models to represent database tables, the Amazon API > and an SMS API. > > If all your controllers assume that all your models inherit from > Model, then your code is monolithic and none of it can be reused. > > http://c2.com/cgi/wiki?InheritanceBreaksEncapsulation
I think this is a bit extreme. It really depends on what's in your parent model class. It could be something really simple, but something you don't want to have to rewrite in every model you code. Thinking that a model must stand on its own without inheriting from a parent model class because of some ideal notion of encapsulation is silly. Actually, in all deference to the eggheads of OOP, I believe there are really only four reasons to use classes: 1. It keeps me from having to rewrite the same code over and over (inheritance). 2. It keeps the namespace cleaner, since methods are unknown outside the context of their containing class. 3. It allows me to change details of function implementation without breaking things. This is a weak claim, though, because I can do the same thing with straight functions; just change the guts of the function, while still providing the same inputs and outputs. 4. It keeps the stack cleaner. I don't have to pass the same crap to every related function. I can keep the data inside my class and have all the methods share it. The notion that OOP was going to save the world billions of hours of programming time because of re-use is bunk. It hasn't, doesn't and won't. </rant> Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
