Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

refactoring to fit MVC

 
Randall Twede
Ranch Hand
Posts: 4481
3
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
for an exercize, i am going to refactor a project i did at community college to fit the MVC framework we used later at university. i didnt notice when i first learned it, but that professors framework was fundamentally different from the way i did things before. now that i notice, i want to know why. ill post some code from both.
from the class i am going to refactor:


from the MVC framework:


my first question is why he made JFrame an instance variable instead of extending JFrame? it kind of reminds me of what i read about Spring using Plain Old Java Objects that dont extend or implement anything.

my second is about why he made MainPanel class instead of just adding straght to the ContextPane like i used to do. my guess is its more object oriented and easier to read.

any insight or comments appreciated
 
Ryan McGuire
Ranch Hand
Posts: 1078
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Of course I can't look into your professor's brain and know exactly why he did anything in a particular way. However I can think of one or two possibilities:

...why he made JFrame an instance variable instead of extending JFrame?


IMO, the "View" is an container concept that encompasses all the interface objects. It's true that one of interface objects, such as the JFrame, could be "promoted" to be the boss, but it's better (purer?) to have all the concrete object be children of the View class/object. It's a cleaner design at the cost of one additional object. Also, if you ever have to change out the object that is currently a JFrame for an object of a different class, you'll be changing out one of the children of the View instead of reworking the View itself.

...why he made MainPanel class instead of just adding straght to the ContextPane


It depends on what behavior is included in the MainPanel class and what's in the View class. It would make sense to me if the MainPanel class acts as a wrapper around all the lower level interface objects that are on the panel, while the View handles higher level functionality that doesn't depend on details. For instance, I could see the Controller sending the View a message (a.k.a. call a View method) in response to "update the interface elements". The View might then tell the MainPanel to display the current options. The MainPanel would then tell CheckBoxA to be unchecked and RadioButtonB to become checked. In this scenario, the View knows that the MainPanel is responsible for displaying the current set of options, but the MainPanel knows that details of what types of interface elements (checkboxes, text areas, etc.) that are actually used.

But those are just guesses.
 
Randall Twede
Ranch Hand
Posts: 4481
3
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for the opinion. i think i like the way he did it, and he made that nice framework for me so i will follow his example when using MVC pattern for desktop apps.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic