I have a Object-Orientation question, related to the Model-View-Controller (MVC) pattern. I suspect it will have a simple “here is the idiom everyone uses for this situation” type answer, but I haven’t found it. Here’s a fictional piece of software that demonstrates my problem.<\/p>\n
Suppose I am writing a program to solve, once and for all, all those school-boy questions about “Who would win a fight between a giraffe and a kangaroo?”<\/p>\n
I am writing it in Python, which gives a fair bit (too much?) of flexibility in its Object Model, but I am happy to hear how the problem is solved in other (more strict?) languages.<\/p>\n
I am using a nice Model-View-Controller (MVC) pattern. <\/p>\n
My model includes a database of animals. It has a nice class hierarchy – everything inherits from the Animal class.<\/p>\n
In version 1, my view includes a visual display of photographs of each of the animals. In version 2, I hope to add a separate view which contains cartoon representations of the losing animals’ carcass (with markings highlighting where the animal was injured) and another view which plays appropriate animal noises.<\/p>\n
So that means (a) each animal class may have a corresponding view class that knows how to display it, and (b) each animal class may have more than one<\/em> corresponding view class, depending on the purpose of the view.<\/p>\n So far, so good. I think I am describing an ordinary use of the MVC.<\/p>\n Now, I have decided to display the first 20 animals on the screen, so I pass a collection of animals to the code responsible for creating the view instances.<\/p>\n Here’s the dilemma. That code knows only that each instance it is some sort of animal. How can it create the correct corresponding view?<\/p>\n I have a number of potential solutions.<\/p>\n Each animal class could contain a factory for the view class. For example, I could ask the Zebra instance to create a ZebraPhotoView for me.<\/p>\n This is an ugly reversal of the dependencies. I don’t mind the model being aware that there exist view classes (e.g. that might subscribe to changes) but I don’t like the idea that every time a new view is added, all of the model objects need to change.<\/p>\n Each animal class could contain a “id” method, that simply returns a static value. Some separate factory code could ask the object for its id, and then contain a giant switch statement that creates a corresponding view depending on the value of that id.<\/p>\n Every time I see a switch statement, I think “Why didn’t the object model successfully hide this in some good clean polymorphism?”<\/p>\n Note also that the switch statement, in this case, is very fragile to changes in the model class hierarchy.<\/p>\n Python (and several other modern languages) offer access to meta-data about the class. In particular, Python offers the ability to check if a variable is an instance of a specified class.<\/p>\n I could hard-code a static list of animal class, view class pairs – e.g. Then for each object, iterate down the list, checking if it is an instance of that class, and, if so, create an instance of the corresponding view.<\/p>\n Iterate through a list looking for a match? Sounds inefficient. Yes, a dictionary would be faster if there were many different animal types, but I would lose one of the benefits: you can still take advantage of the inheritance hierarchy this way. For example, one of the entries could be So, this has a very slight improvement in “Object-Orientedness” over the switch statement, but it still requires careful maintenance to make sure the hard-coded list matches the rest of the code.<\/p>\n Also, while I appreciate the utility of features such as Registration has the right feel to me, but I can’t quite get the mechanics.<\/p>\n The idea is that the ZebraView class<\/em>, when it is first “elaborated” (to use an Ada term – this is after start up, but prior to the first instance being created), could call a class<\/em> method on the Zebra class and say “Hey, if anyone comes around here asking for a “photograph” of you, send them to me.”<\/p>\n The Zebra class would have to know that view classes exist, to be able to store references to them in a dictionary, and to be able to return a reference to one when asked, but there would be no hard-coded knowledge of what they are, or even what “photograph” means, beyond being a cookie.<\/p>\n The trouble here is I am looking for inheritance behaviour on class (static) methods, and it doesn’t work that way. I can’t write a The Problem<\/h4>\n
Solutions?<\/h4>\n
Model knows about the Views<\/h5>\n
Switch Statement<\/h5>\n
Reflection<\/h5>\n
[(Aardvark, AardvarkView), (Aardwolf, AardwolfView), <\/code>…]<\/p>\n(Bird, BirdView)<\/code>, which could display a generic picture for all the birds that I don’t have photographs for. I could make the list a little less fragile to additional animals being added.<\/p>\nisinstance<\/code> for debuggers, instrumentors, object browsers and other “meta-programs”, using reflection (e.g. isinstance()<\/code>) in my regular code adds a rather pungent code smell to me.<\/p>\nRegistration<\/h5>\n
registerView<\/code> static method on the Animal class, and call it on the Zebra class, let alone have it access the Zebra class’s static data member representing only the views registered on the Zebra class. <\/p>\n