MVC in command line java [closed]

Question

I am trying to get MVC in my command line project.

As of now (no MVC, obviously) I have:

• MainClass (fake name obviously), a fret using the Menu few times it creates a System object
• Menu (used by the Main to present options)
• System, it has a Model as an attribute, created with a file or keyboard input, it uses the data from Model to perform a simple operation .calculate(valueA,valueB) where valueA and valueB are selected using the Menu from an areay of attributes of the Model
• Model (kind of) is the container of the data I have.

Can someone please suggest me a proper structure for the classes?

Thanks a lot, Luke

Answer 1

I'm really surprised by the negative reactions to this question, as it's a rather interesting one. I expect it's because most people assume that MVC only has any meaning in a web environment, but MVC is completely applicable to a CLI program too. It just presents a different view medium. In fact, I'd consider it the superlative MVC design that was able to plug in either a CLI, GUI, or web "view" without any change to the controller and model pieces.

All that MVC says is that, given an application, you abstract as much as possible the view portion--the presentation of the app, what users see and interact with--from the real, internal logic of the app. The way you do that is to create controllers that "glue" the view and whatever controls exist in it to the logic on the back end. Put simply, controllers translate user input into method calls and translate return values back into stuff useful to the user. The model part of the pattern is somewhat debated. Some say that each, separate piece of object graph that's sent to the view for displaying is a "model". Others maintain that the entire stateful object graph that lives in the back end is the "model", and controllers form something of a looking glass that let the view pick out, inspect, and modify specific pieces of the model. The question is really whether there are many models constantly flowing back and forth or one, large model that needs to be exposed in a way the user can comprehend.

To get to MVC in a CLI--or any type of app--have a part of the code that's clearly defined as the view/presentation. It should never, ever have anything even resembling business logic in it. Your controller(s) should be objects that know how to respond to user inputs and can send things back for viewing, though without any assumptions about how those things will be displayed or exactly what form inputs will take. The model, one way or the other, is basically the actual data or "stuff" that the user cares about, and it should be oblivious of either the view that's showing it or the controller that's... um... controlling it.