MVP: just another word for Polymorphism?

 
Feb 11, 2012
 
I'm a newby to MVP. Would I be wrong in saying that MVP is just another word for polymorphism?

As a 63 year old who started programming in 1965 on mainframes, then minis, then 4004/8008 etc etc I have gottten used to each successive generation renaming objects to their own buzzwords(bit like dogs having to piss on lamp posts?).

To give you an example I have seen things that used to be called "indicators" then called "switches", "booleans", "flags" etc - you get the picture - when all the time they're the same object. I am wondering therefore if this is just another case where somebody has decided to make a science out of something that wasn't necessary in order to put their generational stamp on?
 2 comments
 
MVP (Model-View-Presenter) is a specific design pattern that may take advantage of polymorphism. It's not the same thing though. --- David Snider  Feb 12, 2012
 
Many thanks indeed David - in that case I'd better start learning pdq! --- vigorniensis worcester  Feb 13, 2012



1,354   100.0
Feb 16, 2012
Just my thoughts on this....
I understand what you are thinking, atleast I guess.  Yes nowadays most of the technology seems to be buzzword around something very basic.  But sometimes this buzzword is required for having a common understanding across teams and different stakeholders.  If you consider any aspect of OOP with respect to reuse, then most of them may be achieved using some kind of polymorphic behaviour.

The thing to understand and remember is that MVP is an architectural pattern (another buzzword here), which definitely has its own role to play, much more than the simple term of polymorphism.  Its an amalgamation of various other buzzwords, which when bundled together may help you create better applications which is resilent (another buzzword here) to future changes.

Yes you can definitely create applications without using MVC, MVP, but then if its an enterprise applications where various teams are working together, it will be very difficult to communicate design and ideas across consistently though not impossible (but how many people would like to do this) without using a common vocabulary. 

A new member joining the team may find a hell lot difficult to browse through the code if there is not a common vocabulary.

So, definitely some times, some buzzwords are necessary, if applied in right context.