I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.

For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.

According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!

And thus according to this logic, the record-set should manage the drawing of the UI.

**Head Desk***

I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;

I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!

Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.

Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.

Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?