Model-View-Controller Pattern Input

[Danny Treart]

Hi, this is a homework assignment of mine and I'm wondering if I'm implementing this properly (or if I'm anywhere close). Could you guys maybe take a peek and let me know what you think? Unfortunately, it seemed to work until I put in the InputMismatchException in the while loop, but I can probably figure that out soon. Any thoughts, advice, or critique you might be able to offer a newb?

Thanks.

import java.util.Scanner;
import java.util.InputMismatchException;

public class CounterTest {

    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int startSec = 0, endSec = 0;
        
        boolean running = true; //the program runs at least once
        boolean tryAgain = true; //checks the validity of input, runs loop again if input throws exception
        
        System.out.println("This program tests a timer.");
        
        while(running = true){
            while(tryAgain = true){
                try{
                    System.out.println("Enter a number of seconds to start at: ");
                    startSec = sc.nextInt();
                    System.out.println("Enter a number of seconds to end at: ");
                    endSec = sc.nextInt();
                } catch(InputMismatchException e){
                    System.out.println("Invalid entry. Try again.");
                    tryAgain = true;
                }
                tryAgain = false; //terminate the input loop if no exception thrown
            }
            
            //send to controller, model, view
            System.out.println("CounterController starting...");
            CounterController cControl = new CounterController(startSec, endSec);
            cControl.Start();
            
            System.out.println("Wish to run again? (y/n): ");
            String input = sc.next();
            //run again??
            if(input.equals("y")){
                running = true;
            }
            else if(input.equals("n")){
                running = false;
            }
            else
                System.out.println("Invalid entry.");
                running = false;
        }
    }
}

public class CounterController {
    
    private int startValue = 0;
    private int endValue = 0;
    
    public CounterController(int startVal, int endVal){
        this.startValue = startVal;
        this.endValue = endVal;
    }
    
    public void Start(){
        CounterModel cModel = new CounterModel(startValue, endValue);
        
    }
}

import java.lang.*;

public class CounterModel {
    
    private int counter = 0;
    
    public CounterModel(int initialVal, int endVal){
        counter = initialVal;
        CounterView cView = new CounterView(counter);
        while(counter <= endVal){  //until counter reaches the end value
            cView.Display(counter);
            try{
               Thread.sleep(1000);
            } catch(InterruptedException e){
                System.out.println("thread interrupted");
            }
        
            increment();
        }
    }
    
    public void increment(){
        counter++;
    }
}

public class CounterView {

    private int counterVal = 0;
    
    public CounterView(int counterVal){
       this.counterVal = counterVal;   
    }
    
    public void Display(int counterVal){
        System.out.println(counterVal + "..");  //display each value in the counter until the end
    }
}

[Stevens Miller]

I'll try to say something more useful soon, since MVC is kind of an obsession of mine, lately.

But, this:

Danny Treart wrote:

        while(running = true){

is certainly not what you meant. Do you see why?

[Stevens Miller]

Okay, one problem I think I see is that you've got your model creating your view, and your controller gives up control to the model for the entire duration of the life of the model. In effect, you've turned the model into the controller.

As I understand them, MVC-structured applications have the view register for events with the model (or with an object that publishes events) and then it waits for the model to fire (or use the publisher object to fire/publish) events. Upon receiving an event, the view can (if it needs to) read the model's state. The controller also waits for events, but from the view (these are generated in response to user input). Upon receiving notification of an event from the view, the controller can alter the model's state (which, most likely, causes the model to notify the view that its state has changed, so the view can read the model's state and update itself). There are only about a billion variations on this (as far as I have counted to date), so that little summary is hardly set in stone.

Rather than pontificate further, though, I think I'll watch this thread closely and wait for the wiser heads to opine. This could be very useful.

[Danny Treart]

This is the instruction from the Professor:

In this program, there will be 3 classes. Your test program will input a start and end number
of seconds. Call the CounterController only from your test program. The controller will create
an instance of CounterModel with the initial value and call increment until the end value is
reached. The CounterModel will wait 1 second, increment its counter and then display its
counter by calling CounterView. Use Thread.sleep(1000); to delay 1 second.

[Stevens Miller]

Ye Gods. What a mess!

However, as I read your instructions, it is the controller that should call the model's increment method. You have the model doing that.

As for the rest of that (and I say this in as much humility as I can muster) misguided assignment, I'll definitely wait for Campbell or Winston to advise you.

[Danny Treart]

Honestly, I appreciate your help and your feedback. Unfortunately, it has been an exhausting semester, to say the least, with regards to my assignments in this particular class. I expected to have to do a lot of research on my own (which I don't mind) but the assignments or requirements have been incredibly vague, and I'm left asking you guys, struggling staying up all night trying to finish the best I can with what I've got. Luckily, my grades here are decent, I hope I can finish strong but the assignment descriptions are killing me.

[Stevens Miller]

I sympathize. My son is in the seventh grade. Half the "wrong" answers he loses credit for on his assignments are, in my opinion, the result of ambiguous questions that could fairly be answered more than one way.

However, I believe this sentence is unambiguous:

The controller will create an instance of CounterModel with the initial value and call increment until the end value is reached.

This says that the controller will do two things: 1) it will create an instance of CounterModel with the initial value; and 2) it will call increment until the end value is reached. Thus, I think Line 18 of your CounterModel source code puts the call to increment in the wrong place. It should be in the controller.

The wording of your assignment is silent on the question of where the view should be created. There are a variety of options people use, but I am pretty sure the model is not where the view should be created. You can do any of these: 1) CounterTest.main can create the view, and pass it a reference to the controller (this is an implementation of the strategy pattern, and is the one I personally like best); 2) CounterTest.Main can create the view, which, in turn, can create the controller itself (this hard-codes your choice of controller within the view code, which is what the strategy pattern lets you avoid doing, but I've seen a lot of example MVC programs do it this way); or 3) CounterController's constructor can create the view and pass it a reference to itself (that is, the controller can pass this to the view's constructor, which may or may not get you a warning about dubious parameters in constructors, depending on your IDE and/or any other source of helpful advice you have).

There are other ways, as well, to get the model, view, and controller created and able to communicate, but I very much doubt that having the model create the view is a popular choice. That makes the model dependent upon the view, when one of the great virtues of MVC is supposed to be that the view can change at any time (even at run-time), with no accommodation required of the model to do so. Indeed, you can even have multiple views instantiated at the same time and, again, the model need not provide any support, other than emitting events. By structuring your code this way, you could, for example, replace the view you've got with one that moved a needle on a graphic timer, or blinked some number of lights. As you have written it, however, at a minimum, you would need to rewrite CounterView to make those changes, since your model has a hard-coded reference to CounterView's constructor. If you defined an interface for your view, your model could use that to send events, and you could change your view from CounterView to some other class that implemented the same interface, but only if you create the view somewhere other than inside the model (and then pass the model a reference to the view, with the reference being of the interface's type).

So, those are my suggestions (since the big boys haven't arrived yet). Move the call to increment out of the model and into the controller, and create the view outside the model.