Why is it considered a best practice to package the program code and the graphical interface code in different classes?

Question

So my teacher tells me that it is very important to not encapsulate the program code and the graphical interface code in the same classes, But to keep them completely independent. Im currently writing an iphone game with a grid in it. to me it makes much more sense to Create both the graphical grid and the technical code in the same "Grid" class. Will other programmer frown upon this? Is it indeed very important to keep the graphical interface and code independent. What problems will arise if I don't?

Thank you!

EDIT: thanks guys! Would it be ok for me to write up the project first and then copy code around to form the separation of concerns design. I know that this may totally defeat the purpose, but just as practice...So that next time I can apply this design pattern from the start?

Answer 1

The concept your teacher is referring to is something called Separation of Concerns.

To illustrate it in your context, if you complete your program and then decide you want to port it to Android; you'll have to re-write a lot more code than if you'd kept the grid logic separate.

An interface control should only be concerned with drawing what it's told, the grid logic should only be concerned with what's in the grid, not how to draw it.

Does this help ?

Answer 2

To make it easier to change your code. What if tomorrow you don't want to use a grid but a list? When your GUI is separated from your logic it's easy to do.

Besides that you'll write code that's more reusable. If your GUI does not contain your technical code you can also reuse it. Create a fancy grid with all options once and you can use it in other projects. Mixing your GUI and technical code will prevent you from doing this.

It also gives you code that's easier to read. If your grid does only do GUI functionality it's easier to understand or change your code.

Answer 3

The general approach of object-oriented programming to a separation of concerns, where code is separated into logical tasks. Initially, this may seem like more work. But as your project grows, it makes it easier to track and manage your code.

For that reason, it would likely be better to separate code that is responsible for displaying a grid and code that deals with data that may be displayed in that grid.

Answer 4

When Separation of Concerns is applied to an application structure, the result is multi-tier architecture (or N-Tier architecture) http://en.wikipedia.org/wiki/Multitier_architecture.

Answer 5

To build on the other answers and give you an example you should somehow allow yourself to inject your logic / data into your grid or vica versa.

Your grid control can either expose a Render method or a DataBind method.

class GridControl
{
    public Render(GridData data) { ... }
}

or

class GridControl
{
    public DataBind(GridData data) { ... }
}

Then your logical unit can either take the GridControl and bind a data object to it or manually call render with the data object everytime anything changes.

Your GridLogic should also have a reference to the GridControl so it can bind to any input / events happening.

The idea behind data binding is that your grid control watches the data for any changes and re renders itself where as exposing a render function means your logic unit manually re renders the control.

Either way splitting your logic and grid up like this allows you to more easily change one of the other without breaking anything. You can also write a new control like a ListControl to show your data as a list instead of a grid without having to rewrite all your logic.

Answer 6

I strongly recommend that you take a look at MVC architecture.

It is a refinement of the concept you have mentioned(seperation of program code and graphic interface). MVC stands for Model-View-Controller. Here the Model is the data, View is the graphic interface code and COntroller is the code that processes the data.

This way you have created three parts of your program. Each part can be replaced without requiring changes in the other two parts.

Answer 7

It depends on the kinds of future changes you can expect to occur. What you want to minimize is the number of manual code changes needed to correctly implement each single functional change.

Where MVC wins is if changes are confined to the V part, or "View".

In my experience, it is much more likely that changes affect all three parts, so it is better if they are not separated. To show what I mean, I have long used a technique I developed called Dynamic Dialogs, in which a new requirement, such as "allow user to edit name, and when complete do XYZ" is entered into the source code as a single block of text:

if(deTextEdit(&sName)){
  // do XYZ
}

instead of multiple separate edits, to specify that the edit field exists, to make up a unique identifier for it, to bind it to the model variable, and to link it to the lost-focus event handler.

If you go to that link you'll see a more complex example.

Basically the idea is to turn the code into a domain specific language, so as to minimize the number of edits to accomplish the purpose. The reason you want to do that is not only to reduce effort, but to reduce the opportunity to introduce bugs, by forgetting or mis-coding one or more of the edits. It also reduces size of source code by roughly an order of magnitude.

It is not free. It introduces a one-time learning curve for the programmer.

Answer 8

Graphical interface is sytem dependent, while the game core is an algorithm totally independent from the system it runs on. Keeping the two appart will make the program easier to maintain, test and debug because the changes in one subsystem does not affect the way the other works. Even if you do not care about portability I bet you care about robustnes and maintainability of your program.