At this point we should pause to discuss code organization. We have been defining classes within a single main source file. In fact, we have mostly done this for all of our work by simply reusing the Workspace template. From this point onward, we will often create separate folders for each of our projects. When we use the Workspace template for simple coding we will explicitly say to do so and when we want to use a separate folder we will say to use the NewProject program (found in the base directory of the Introduction_to_Computer_Programming_Projects folder) to set up the necessary project. (You could of course also just make a duplicate of the Workspace folder when you want to write a new program but then your new program would be called Workspace) You should compile and run the NewProject program now. If all goes well you will see the following:
The Root Directory should not be changed (unless you happen to want to store the project files somewhere other than the Introduction_to_Computer_Programming_Projects folder). The Project Directory should be Unit1 for now (in later units you can change this in order to stay organized). The Project Name can be anything you want. You should select either ConsoleApp or GraphicalApp depending on what type of project you are making. Once you are done you can click Create Project and then navigate to the newly created folder (inside of the Unit1 folder) and open the project. This will create a new Lazarus process so you may want to exit out of any currently running Lazarus processes. You may also want to create a shortcut to the NewProject executable in the Root Directory so that it is easier to access (how to do this will vary by operating system and is not described here).
The main reason we are making separate folders for each project is that we will almost always place a new class in its own unit. We do this to enhance modularity and readability of the code. In terms of modularity, a class in its own unit source file can be easily reused by multiple different programs. In terms of readability, you are decreasing the number of lines of code in each file. This will become extremely important as we build more complex programs. Once we have completed a class and are fairly sure it works, we will no longer even have to open its source file when editing other parts of the program. In other words, we are essentially sealing off different parts of the code in order to work on smaller pieces at a time. Remeber from Section 2.12 we can create a new unit by going to File -> New and then selecting Text from the window that pops up. DO NOT use File -> New Unit because this can be buggy in Lazarus. Then simply enter the basic template code for a unit:
The main reason we are making separate folders for each project is that we will almost always place a new class in its own unit. We do this to enhance modularity and readability of the code. In terms of modularity, a class in its own unit source file can be easily reused by multiple different programs. In terms of readability, you are decreasing the number of lines of code in each file. This will become extremely important as we build more complex programs. Once we have completed a class and are fairly sure it works, we will no longer even have to open its source file when editing other parts of the program. In other words, we are essentially sealing off different parts of the code in order to work on smaller pieces at a time. Remeber from Section 2.12 we can create a new unit by going to File -> New and then selecting Text from the window that pops up. DO NOT use File -> New Unit because this can be buggy in Lazarus. Then simply enter the basic template code for a unit:
unit SomeUnit;
interface
implementation
end.
interface
implementation
end.
Now click Save and save this unit with the same name that is given in the unit SomeUnit; line along with the file extension .pas (i.e., save this file as SomeUnit.pas).
We will use these methods to create Projects and new Units from now on so it is recommended that you become comfortable with this now. As our programs become increasingly complex, we will have several units and classes for every program we write (which also means that as we move forward we will start writing fewer programs and focus on making a single program more sophisticated). Although it might seem strange to dedicate an entire section to organization, it can be one of the most important aspects of programming. How you organize your code in terms of classes and source files will determine how maintainable your code will be as time goes on. Poorly organized code in extremely long source files will lead to nightmares in debugging and often completely failed attempts at developing software. You should rely on things such as abstraction when you feel that a class could very likely be made into several different custom subclasses. This not only will make coding faster and more robust, but it will also make your code easier to read and understand by others through logical groupings into class heirarchies. As a general rule, the classes you create should do one thing and do that one thing well. For example, if you wanted to read in spreadsheets you would create a single class that understands how to read and write spreadsheets as well as how to easily manipulate the data contained inside the spreadsheet. You would not want a single class that reads spreadsheets, presentations, and documents although you might have a class that manages these three in some very loose way (i.e., each class should mostly handle itself and be as independent as it possibly can be). As we continue learning about classes, how to organize them will slowly become more intuitive, but we cannot overstate the importance of planning the organization of code before writing a complex program.
We will use these methods to create Projects and new Units from now on so it is recommended that you become comfortable with this now. As our programs become increasingly complex, we will have several units and classes for every program we write (which also means that as we move forward we will start writing fewer programs and focus on making a single program more sophisticated). Although it might seem strange to dedicate an entire section to organization, it can be one of the most important aspects of programming. How you organize your code in terms of classes and source files will determine how maintainable your code will be as time goes on. Poorly organized code in extremely long source files will lead to nightmares in debugging and often completely failed attempts at developing software. You should rely on things such as abstraction when you feel that a class could very likely be made into several different custom subclasses. This not only will make coding faster and more robust, but it will also make your code easier to read and understand by others through logical groupings into class heirarchies. As a general rule, the classes you create should do one thing and do that one thing well. For example, if you wanted to read in spreadsheets you would create a single class that understands how to read and write spreadsheets as well as how to easily manipulate the data contained inside the spreadsheet. You would not want a single class that reads spreadsheets, presentations, and documents although you might have a class that manages these three in some very loose way (i.e., each class should mostly handle itself and be as independent as it possibly can be). As we continue learning about classes, how to organize them will slowly become more intuitive, but we cannot overstate the importance of planning the organization of code before writing a complex program.