Problems when splitting up a single-unit code into multiple files

[round_n_sideways]

I am working on a Sudoku solver project with GUI which so far contained of a single unit, and that unit contained all the global variables and the template for the TForm class.

Now I want to separate this one unit into 3 parts:

• solving algorithms
• event handling and UI drawing
• providing sample sudokus for testing/debugging

However, moving these to their respective units created a problem - all of them need access to the Form1 global variable, and there are function calls both directions, e. g. calls in the event handling unit to functions in the sample-provider unit, and the sample-provider unit has calls modifying the Form1 global variable.

I am very inexperienced with object-oriented programming, and figured that maybe if I move only the class template for TForm into a separate unit, and include this unit into the new 3 units I've created, it would solve the problem, but unfortunately that is not the case.
The class template requires function prototypes for all the events that might occur, but I don't want to implement the event handling in this unit for visibility reasons - I only want this unit for the class template and global variables.

What would be a good workaround to this?

[JuhaManninen]

Now I want to separate this one unit into 3 parts:

• solving algorithms
• event handling and UI drawing
• providing sample sudokus for testing/debugging

Good plan! It separates GUI and logic. In a RAD system they get easily mixed unfortunately.

However, moving these to their respective units created a problem - all of them need access to the Form1 global variable

Then your design is flawed. Form1 is part of the GUI. Code providing the logic should not need it.

What would be a good workaround to this?

No workarounds but good design.
I recommend you create an abstract master class for the logic part. It works as an API and the implementing logic inherits from it.
The GUI can use that API and maybe register callbacks if needed.

This "problem" is related to circular unit references. In many other languages they are allowed without limitations.
Initially the Pascal limitation feels like a PITA but actually it improves code quality always.
Circular unit references are still allowed through implementation section. Try to avoid them, too, and the code improves yet more.
You can look at Lazarus sources. There are very few circular references. Abstract base classes and such have been used a lot.

[round_n_sideways]

Indeed, the code is a mess, but it was kind of expected from a single-file do-all spaghetti code.

I will look into how I can implement this master class idea, but I'm also thinking about just rewriting the whole thing, as it is not terribly big yet.

Either way, thank you for your help, it's appreciated! 

[JuhaManninen]

I will look into how I can implement this master class idea, but I'm also thinking about just rewriting the whole thing, as it is not terribly big yet.

Maybe not rewriting but heavy refactoring.

[Bart]

As Juha said: very dood idea.

Your data solving algoritms do NOT need a Form.
You have to think about th einput (what, and what datatype) such an algoritm needs (probably some sort of 2-dimensional array can represent the sudoku grid).

You can make a Sudoku class, that has all the logic, and that fires events that makes it possible to draw the sudoku and get input.
This way, your drawing/input can be done in any way you can think of (GUI, text-based).

You can make this as "complicated" as needed.
E.g. a class that represents the "Sudoku-grid", a class that can solve sudoku's, a class that can input/output Sudokus and then connect them all.

Bart

Bart