OOP - The MVC Pattern

Helpful script writing tricks and HowTo's
User avatar
Posts: 3459
Joined: 30 Sep 2013, 01:01
Location: Germany

OOP - The MVC Pattern

20 Oct 2018, 05:10

Today I want to introduce a topic that has been very important for a lot of projects I have made.
The MVC pattern.
If you ever visited a website or opened Word or really any kind of Program it is likely that you will have seen this pattern or one of its children in action.
MVC is essentially the outline and the foundation of how most applications are build. Understanding this will allow greater inside to any application and will give you more freedom when controlling them. Understanding it will also allow you to build advanced applications more easily.

Patterns are like a blue print that assign several roles to objects that they need to fulfill. These patterns help when understanding the code of others and solve specific problems.
The MVC Pattern deals with the design of applications that have any sort of UI.
It assigns 3 roles:
  • M - Model
  • V - View
  • C - Controller
The Model
The model is the data of your application. The classes that are Model classes just take care of storing the logical data.
If you make a chess application it would be classes about the chess figures, the board and perhaps the moves that were made.
If you try to make an online shop it would be classes that represent the items that you sell, accounts that are registered and deliveries that are being made.
The instances of these classes are also often supplied by a database.

The View
The view is the UI of your application. The classes that are View classes just take care of displaying the Model and take note of user input.
In our chess application one View would be the controls that display the chessboard.
In our online shop one View would be the rows, columns and all the other html elements that create an overview of all the sold products.
The View often represents a single screen the user sees like the Menu View with all the menu buttons or the Game View with the Chess Game.

The Controller
The controller contains the actions that your user can take. The classes that are Controllers receive events from the View and change your Model depending on that.
In our chess Application there could be a game controller that makes it possible for you to move all figures.
In our online shop there could be a Controller that handles our login.
It is commonly seen that a controller is tightly interwoven with a View to the point where 1 View has 1 Controller.

Interactions between the roles
The View accesses the Model and the Controller but neither contain any code about the View.
The Controller accesses the Model but the Model does not contain any code specifically for the Controller.
The Model stands on its own and doesn't have to care about the other parts of the Program.

  • Better maintainability of the UI and Controlling Logic:
    Due to the strict splitting of the View to the Model and the Controller you can change the UI without affecting either of them.
    You can also change the way your Controlling Logic works without having to change the model.
    And if the changes to the Controlling Logic do not require new features of the UI then you don't have to touch the View either.
  • Greater Reusability:
    You can reuse the Model or the Model and the Controllers if you want to create a new Apllication with a different View.
    Perhaps you want to completely revise the way your application controls - then just discard the Controller and adapt the View to the new logic.
    Or you want to display a login form on every page of your Website.
    Then you just create a LoginView and give that part of your UI to the LoginView and handle anything this View sends with your LoginController.
  • Multiple people can work on the same project:
    The strict splitting also allows several people to work on the same project. A few take care of the View while others take care of the Controller whileanother person tries to attatch the Model to the database.
  • Easier testing:
    The diversion of roles allows you to test each part seperately. You can chech if the Controller reacts to events correctly.
    If the view displays things correctly and sends events correctly.
    And you can check if the Model reacts correctly to the changes applied by the Controller or if it contains the correct data.
    This lets you find mistakes more easily.
  • More Work:
    Maintaining this pattern throughout your code means you essentially have to create 2 classes for every screen or subscreen that you have.
    Thats more work than just having one.
  • Worse Code Navigation:
    You will easily end up with a lot of clases that can become hard to navigate.
  • UI directly linked to Data:
    While it easy to change the UI and the Controlling Logic, changing the model will result in having to change all Views and Controllers that use this Model. This is especially problematic in Web Environments where database updates and changes are commonplace.

Modern Usage and Occurencies:
The MVC Pattern spawned a whole new generation of frameworks and new design patterns.
MVC itself is mostly competed by one of its own children which are just as common as MVC itself.
Java tends to use MVP and a few web frameworks use MVVM.
Sadly I don't think I have seen a good example of MVP in AutoHotkey yet.
Recommends AHK Studio
User avatar
Posts: 3459
Joined: 30 Sep 2013, 01:01
Location: Germany

MVC Project

20 Oct 2018, 05:11

Since I have not found any good examples for MVC in AHK I thought about writing my own Application using MVC and then showcasing it here.
The Chess game I mentioned in this Tutorial might be a good example for such an Application.

This might also be a good project to work together with people - so I'm looking for people that want to collaborate with me on this project.
What you need to bring is yourself, motivation for 2 -3 hours and basic knowledge about AHK and functions.
Knowledge about Objects themselves is not that much required - though it would be helpful if you knew about arrays and associative arrays.

Since we need our Controls as Objects we are probably going to use AHK v2 and since the timing matches it might be good to try out lexikos Object.ahk:
https://autohotkey.com/boards/viewtopic ... 37&t=57591

The Game can be really simple - I mostly want to focus on the pattern and the new features of v2.
Though if many people show up or we decide we want to continue we can add more features - like a multiplayer for LAN networks.

If you want to join don't hesitate to post here or send me a PM.
I look forward to working with you.
Recommends AHK Studio
User avatar
Posts: 3459
Joined: 30 Sep 2013, 01:01
Location: Germany

MVC Children

20 Oct 2018, 05:12

Recommends AHK Studio
Posts: 3226
Joined: 17 Jul 2016, 01:02

Re: OOP - The MVC Pattern

20 Oct 2018, 09:41

Hello, thanks for the tutorial :thumbup: .
I'm looking for people that want to collaborate with me on this project.
I'd be happy to join in if I can find some time for it. Perhaps if there was a list of tasks to pick from it would be easier to get the ball rolling, so to speak.
Since we need our Controls as Objects we are probably going to use AHK v2 and since the timing matches it might be good to try out lexikos Object.ahk
Excellent idea :thumbup:

User avatar
Posts: 3459
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: OOP - The MVC Pattern

20 Oct 2018, 12:07

To be honest I have not yet prepared enough ressources to make a task list.
What i thought what be some sort of "kick off" meeting where the participants would meet up in a chat of some form and I would introduce the idea and answer questions.
After that everyone would be free to finish their task as they want. However I think it would be good if everyone just started their part right afterwards and we would finish the game in the next 2 to 3 hours.
i really only plan to take that much time since I do not have that much time myself.
Recommends AHK Studio

Return to “Tutorials”

Who is online

Users browsing this forum: No registered users and 8 guests