The transcript for the video of this lecture is as follows.
Introduction
Hello, my name is Yvonne Richardson. I have a Bachelors Degree in Computer Science from Western Washington University, and a Masters in Education from the University of Washington Bothell. I am here to talk to you today about Code Optimization.
Many of you are Java developers; some of you code in C, C#, C++, JavaScript, and other languages. I would like to introduce you to a methodology that is centered around writing robust, reusable code. This is the science of Code Optimization.
Overview
There are five major concepts that are important to developing optimized code. It is more cost-effective to develop code using these concepts than it is to re-write the code later. Code that is created using these 5 architectural principles will be more modular, more maintainable, more reusable, and more robust than code that is developed without a plan.
When planning software, many teams will determine the tasks that the code should perform. This list of tasks is the plan, or system design. This tutorial guides the developer where to locate certain types of code to form an object-oriented architecture for the program. These five concepts are easily applied during rapid prototyping and development.
There will be instances when these guidelines cannot be followed exactly as described here. Solutions that are built using these guidelines may be truly optimal code, but computer languages that are not optimized using the same rules may occasionally throw compile errors. When a developer encounters these compile errors, they will be able to identify the facet of these guidelines that causes the conflict. Then, they can normalize the code so that it aligns with the computer language in which the solution is implemented.
Five Major Concepts
The five guidelines or major concepts are:
1. Use the MVC Model
2. Respect the Task-Method Correspondence
3. Pass Few Parameters
4. Declare variables locally
5. Minimize Scope of Method Calls
Guideline 1: Use the MVC Model
The first concept in optimization is having a model by which to organize your program code. The name of the model that developers are using today is the MVC model. The acronym MVC expands to Model View Controller model, which sounds somewhat redundant; however, it is important to have a model for the thing that the code is supposed to represent, in addition to a model or an architecture for the code itself. For example, a motor vehicle has at least 2 wheels and a steering device. So, if you have modeled a real-life object like a motor vehicle, you probably have a blueprint that specifies these and other major factors. That is the model that your code is based on; because the code is a separate thing, it has its own architecture. The main workings of the program code are the model of the model.
The code model of the real-life model should operate without being attached to a Graphic User Interface, or the view. This allows the graphic user interaction to become a separate piece of code, the view portion of the MVC model.
Separating the model from the view allows you to change to a new GUI as appropriate without making any changes to the model that the code is trying to represent.
The third component of the MVC model is the controller. This is often considered to be the main method, or the driver program. This is the logic that you can not include in the model or in the view, but it makes them communicate with each other, so it drives the process.
Whenever you write a program, try to divide the code into these three components. It will help organize your code, and increase its maintainability and reusability.
Guideline 2: Respect the Task-Method Correspondence
The second concept in code optimization is associated with the piece parts of the model components. Consequently, this programming style affects all 3 components of the MVC model. At a deeper level of granularity, all 3 components of the MVC model are composed of tasks. A task can be composed of subtasks. Many models do not differentiate between a component being a task and a component being a subtask; the word "task" is reasonable for specifying the code architecture.
Whether a task is named a task, or a task is named a subtask, either way, it is composed of functions, or methods, that perform that task. It is important to remember "one method one task", which is not the same as "one task one method". Eventually, what you will develop is many small pieces of code that are methods. Each method should perform one and only one task.
For example, the vehicle model contains a task named "CreateDecal". If you want to ask the user a question about their favorite color, the method that performs this task might be the FavoriteColor method. This is not the same as methods that answer the question "what kinds of stripes do you like?" or "what shape should be used for the decal?". Those are two other questions that the CreateDecal task can use, but they do not work with the same properties as the FavoriteColor method. Consequently, the FavoriteColor method does not need to perform those parts of the CreateDecal task; it performs only one task.
Likewise, when there is one task that you want to develop, try to write the entire task in one method. A method that does only one thing can be called by several tasks, which increases reusability.
The overarching task can have a meaningful name, even if it has to call several methods. This means that the overarching task is only one method long. There is a one-to-one correspondence between the task and its piece parts. The piece parts may have a one-to-many correspondence between the piece parts themselves and the tasks of the overall project.
This is the point at which you have to remember that the MVC model is not a blueprint. There may be times when some code must be duplicated in order for the overarching task to be contained in one method, or to circumvent compile warnings or errors. It is normal to include some extra methods in a task. However, using this second concept of code optimization will reduce redundancy.
Guideline 3: Pass Few Parameters
The third concept in code optimization is associated with sending parameters to methods. They are still called arguments in some instances, so that you can differentiate between formal arguments and actual arguments. Regardless, if a method does not need the values, then the values should not be passed to the method. This makes for smaller, and therefore faster interfaces between the calling method and the called method. It also emables overloading and polymorphism.
Guideline 4: Declare Variables Locally
The fourth concept in code optimization is where and how the variables are declared. There are several schools of thought on where and how to declare variables. This is associated with the actual memory locations that are used when your code runs on the computer.
In the traditional model of computing, your program would be separated into two pieces by the compiler. The two pieces are the code segment and the data segment. For the most part, within the code segment, you probably do not have variables, and also within the data segment you probably do not have code.
It is easier to create a data segment when your variables are all declared at the beginning, before any methods are created. High-level languages would not compile if data was declared anywhere else.
With the advent of optimizing compilers and byte-code based interpreters, the computing industry is moving away from the idea of code segment and data segment. Now, we can encapsulate the variables within the various objects. If the variables are local to the object, then they do not need to be out in the memory space that contains the rest of the data segment. When the variable is local to the object, what you have is a smaller series of code and data segments that are associated with each other and nothing else. They use less memory and are easier to remove from memory when their task is complete.
So, it makes sense to declare variables within the construct that uses them. I use the word "construct" because the thing that has code that operates on data may not be an entire object, a program, or a class. Viewed from this perspective, a for-loop is the same type of construct as a method that can be called. A method that can be called that you wrote is the same as a method that is located in some other class, namespace, or dynamic link library. A class is a combination of this new idea and the traditional model, because its instance variables are declared at the beginning of the class, like a code segment; the instance variables are visible to all objects and methods within the class.
So there are 2 items that the position of the declaration will affect: preconditions and postconditions. As you read your code, you can see the preconditions and the postconditions that surround the construct that needs the variable. All you know about this construct is that it has a precondition - some reason for calling it - that relies on this variable. Likewise, the post conditions imply that this construct returns some value or condition that the calling method needs when the use of the construct is complete. So the precondition and the postcondition are probably the best places to declare the variables, initialize their values, and evaluate the variables.
Guideline 5: Minimize Scope of Method Calls
Finally, the fifth concept in using the MVC model is to call methods and objects as low as possible within the program that you have developed. The scope, like a construct, like any other construct, affects object life. If the method call is located close to the method that it is being called, then when you are done with it, for all practical purposes the called method ceases to exist. This is what frees the space for its variables within the data segment, or what frees the method location within the code segment. Insofar as you can do this and stay within the Model-View-Controller model, the calling method can be located near the called method.
The program may not be optimal if all methods are called at the high level in the controller; this affects how much code must stay in memory for the program to run.
The original list of tasks helps determine where their subtasks, and the associated methods, could be located in the program. If there are methods that are best used in the view, they would not be called in either the model or the controller. If the model needs information that is not GUI-specific, the program might contain more than one GUI component - one that communicates with screen/ keyboard devices, and another that manages the information from the external source.
If the methods stay within the view, then the lowest level for calls to those view methods is in the view, which affects how long those pieces of the view will exist in memory. This is the scope that affects the lifetime of the object; when the object ceases to exist, its space is eventually collected and given back to the operating system.
Summary
In summation, the 5 design principles of code optimization are:
1. Use the MVC Model
2. Respect the Task-Method Correspondence
3. Pass Few Parameters
4. Declare variables locally
5. Minimize Scope of Method Calls
From the perspective of the Software Development Life Cycle, these guiding principles should be applied to the tasks that were specified during the business requirements phase of a project. They will help you design a robust system around an object-oriented architecture. Those code specifications can be used to develop reusable, maintainable programs, and the associated documentation, for multiple audiences.