Building a calculator using MVC

Question

I've been programming in Java for about 6 months, and I thought a good and challenging test of my skills would be to build a GUI calculator. I have very recently heard about this MVC idea, and I thought (perhaps foolishly) that it would be a good fit for this pet project. But I'm running into trouble during the design, and I'm not sure how to proceed.

So I have a Model, View, and Controller class. The Model is responsible for all the actual calculation; the View draws the calculator and the display; and the Controller:

1. passes button clicks to View
2. gets the display value from Model and passes it to View

Ah, but the buttons! I want to have a Button interface, where a Button instance has:

• (unique) ID number;
• Name;
• function.

Then I would have my Controller build up a collection of Buttons, and [not sure how to do this] let both the View and Model use those buttons: View for drawing, Model for calculating. Thus I have the revised list for Controller:

1. pass clicks to View
2. return Button ID to Model
3. get display value from Model and pass it to View

But the more I work on this, the more I can't figure out how this would all come together. So I have several related questions:

1. Should View really be responsible for sorting out which Button a click corresponds to? Should that be done in Controller?
2. Should I have more than one type of Button? Is it necessary to distinguish between numbers, operators, equals, etc.? Which of the three MVC classes needs to know the difference?
3. Is MVC even the right way to go here? Is there a more fundamental, accepted way of building an OOP calculator?
4. If MVC is indeed appropriate, what am I doing wrong? I think adding in the Buttons has really thrown me off.

Answer 1

Instead of having a single class for the model, the view and the controller I would make them 3 different folders/packages full of multiple classes/views/controllers. That will allow you to bind each button or a group of buttons to a different listener/controller which performs different operations on the Model depending on the listener.

One possible solution is you could bind one listener to all of the numbers, then individual controllers for each of the operations (+, -, *, =, etc).

Answer 2

The big problem is deciding what is a Model in your application. Usually MVC is used for data presentation/manipulation, and you don't really have any data.

You could - for fun (education) - create for example a MathOperationModel that would be exchanged between Server and Client. Implementing typical CRUD (Create Read Update Delete) actions for it etc.

The calculator 'gui' would be probably a View of MathOperationModel, and all button - pushing would be GUI-side. Then after filling calculator fields (operand a, operand b, operator) the model would be submitted to the Controller and saved, or just calculated (either by Controller or some external class) and user could be redirected to a simple View for either double result or something that encapsulates it :) Or maybe the Model would keep the history and you would redirect him back to the View, just with the operands/operation fields cleared and a a list displaying history.

Long story short: you might do better if you think of an application that has to do with more data-oriented scenario (standard school students database or employees on a payroll or even an address book). Is not really a requirement, but it fits it well...

Answer 3

The MVC pattern was originally formulated before graphical interfaces became commonplace. In that era,it was up to the application to correlate a screen position with a particular button/input field. It was the job of the Controller part of MVC to make that mapping.

Nowadays, translating mouse clicks to a press of the correct button (or a key press to a character in an input field) is taken care of by the OS. For that reason, to say what the role of the Controller is in modern applications, especially desktop applications. It might be valuable to also look at related patterns, such as MVVM and MVP.

In all of these, the View component is responsible for the (graphical) interface that the user sees.
The Model component is responsible for the business logic (the calculations in your case) and should be completely independent from how the user interacts with the program. For the Model, it must not make a difference if the user enters an equation (like 1 + 2 * 3) or presses a sequence of buttons.
The variation between MVC, MVP and MVVM lies in how the Model and View components are connected with each other. This is where, for example, a press on a + button gets translated to tell the Model that a + has been entered.