7.3 Alternative Programming Models

Functional Programming Concepts

The functional programming model’s key concept is that programs are constructed by composing functions and applying them. A pure function is one that will return the same result every time given the same arguments, and there is no reading of shared mutable state. In this context, shared data means that the data is available to multiple program locations or scopes, state represents data that are remembered over time, and mutable means it is changeable. If the data used by the function is shared mutable, it is possible to return different results for the same arguments. A pure function may not have any side effects, meaning it cannot modify any state that is not local to it. For this reason, functional programs do not have assignment statements, which is also known as referential transparency.

Some other necessary features and characteristics that may be missing in some imperative languages include first-class functions and high-order functions. A first-class function is one that can be assigned as a value to a variable. A high-order function is one that can take one or more first-class functions as arguments. It can also return functions as results, which gives a function the ability to apply functions to its arguments one at a time. This is very useful in making code both more flexible and simpler. It encourages the creation of smaller functions that take care of just one piece of a larger job, which makes for great maintainability as well.

Functional Programming Assessment

In the same way that you perform tasks over and over each day, functional programming treats functions used to execute these tasks as prime citizens. Some benefits of repetition include making programs easier to understand for the programmer as well as shortening programs. Some downsides of functional programming are having to move data through the functions, effective implementation is difficult (but not impossible), and new arrays must be created when data in an element are changed.

Encapsulation

OOP languages contain features to implement encapsulation; they are self-contained and enable data hiding. These features include scope rules, for example, defining variables and methods within classes and using access modifiers.

Object-oriented languages often have constructors, and some have destructors which support encapsulation. A constructor is a specialized method that is called upon to instantiate the object. Very often, constructors have parameters which can be used to initialize the values of the attributes with arguments that are passed to them so that the variables are not directly accessed or assigned to. A destructor is used to destroy the instantiated object and recover its memory as in C++. Java and modern HLLs have a background running program for garbage collection that automatically destroys objects and recovers memory when there are no longer any references to them in the code.

They also employ the use of methods to both set and return the values in variables so that they are not directly accessed. Data hiding is further enabled in some modern HLLs such as Java. This engages a background running process for garbage collection that automatically destroys objects and recovers memory when there are no longer any references to them in the code.

Data hiding is one of the main objectives of OOP that falls under encapsulation. Its purpose is to address the details of implementation in a class or object that are irrelevant to users of the class or object. They need only know how to use them; therefore, the details are hidden and provide only what is necessary in its public interface.

Most OOP languages have the keywords public and private. They are used to mark the visibility and access to attributes and methods by areas of code that are outside the class code itself. We call them access modifiers. A member is an attribute or method that is encapsulated within a class or object. A public member is part of the public interface, and a private member is hidden. The following Java code is an abridged class definition that demonstrates the concept:

public class Rectangle {
   // attributes
   private double length;
   private double width;
   // constructors
   public Rectangle(double length, double width) {
      . . . . .
   }
   // methods
   public double getLength() {
      return length;
   }
   . . . . .
   public double getArea() {
      . . . . .
   }
}

The class itself is public, granting access to it and its contents. The attributes are all private, not part of the public interface. In this context, the designer has decided not to allow direct access to these attributes from outside. Instead, they are accessed by public methods, some of which are not shown. The methods that we employ, called getters and setters, can present our data to the outside world in any way we choose. The method can be described as a utility method that can provide the public useful data so that they do not have to compute it themselves.

Inheritance

Figure 7.21 illustrates the implementation of single inheritance, the methodology used by most modern OOP HLLs. Classes and objects can inherit from only one parent.

Figure 7.21 This UML diagram shows single inheritance in Java. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

We refer to the parent class as the superclass in an inheritance relationship and the child classes as a subclass which contains the attributes and methods of its parent class. In this illustration, all the Vehicle attributes are inherited by the Car and the other subclasses with the same exact access modifiers. The same is true of all the methods.

Only C++ implements multiple inheritance, inheriting attributes and methods of more than one parent. This concept is exceedingly messy and can cause major problems in implementation. An example is where both parents have a method of the same name and it cannot be specified which one is inherited or overridden. To implement behavior that is shared from multiple parent classes, Java introduced the interface, which can be implemented in C++ to solve multiple inheritance issues.

An interface resembles a class definition, but it is a collection of methods only. These methods are constructed as abstract methods. An abstract method is declared without a code block for implementation. A class can use one or more interfaces. The following is a Java class definition that makes use of an interface:

public class Rectangle implements geometryMath{
}

The interface acts as a contract with the programmer. If the programmer declares that a class implements an interface, it is required that the class provide implementation code for the functions that make up all of the interface. An override defines another method with the same name and modifies its signature. The override forms a concrete instance of what was an abstract method in the interface. Interfaces appear in Java, C#, Go, or Ruby, and are the dominant approach, superseding true multiple inheritance.

Polymorphism

The feature of OOP in which methods that are inherited may perform in different ways in different subclasses depending on their context is called polymorphism. This is implemented overriding inherited methods in a subclass or the ones in an implemented interface. In the UML diagram, the launch behavior of a car is very different from that of a sailboat or a rocket ship. The resulting behavior is dependent on the context because it is not set at compile time. Rather, the runtime decides what to do when it encounters an object based on its class. The behavior morphs and produces different results for the same method calls depending on the object in hand, which is dynamic method binding or late binding, meaning that all methods are resolved dynamically at runtime, not by the compiler.

OOP Assessment

Remember that some languages like Java and C# are completely object-oriented; some like C++ are hybrids of procedural and object-oriented, and some are on the path toward complete object-oriented like JavaScript, PHP, and Python. Any assessment of the object-oriented paradigm must be taken in the context of where a particular language is on the scale of object orientation.

OOP advantages:

• Strong abstraction with the ability to reuse code efficiently
• Improved software development productivity and maintainability
• Faster software development, thus lower cost of development as it is very efficient for parallel development
• Adapts well to parallelism, where programs can have more than one part of the code running simultaneously
• More consistent software—dynamic method binding producing polymorphism are a mandate that subclasses implement the same behaviors with differences

OOP disadvantages:

• Steep learning curve to master OOP
• Program creation can be complex
• Slower execution due to more generated instructions by the compiler

Race Conditions

When the condition of a program and its behaviors are not synchronized, a race condition occurs. Race conditions are all about timing because anomalies can occur when we do not know which process will finish first or which part of the program is currently executing. We can exert control over when a process pauses or ends in the run-until-blocked scenario where some mechanism pauses a thread. This situation is not always a negative one; race conditions can sometimes be positive by allowing multithreading to compete unchecked for processor attention.

In many multitasking situations we want to avoid race conditions and execute a degree of control of execution; in other words, we want to synchronize threads in either the interleaved or parallel situations.

Synchronization

The building of cooperation between threads of execution, or synchronization, is often handled by first ascertaining which segments of code form a critical section. A critical section is a code block that influences the results of concurrency or parallelism. A simple example might be an employee program in which one concurrent function calculates employee pay and another one prints the paycheck. The print function cannot proceed to put the amount on the check until the calculation function returns the amount. Other situations that need the use of critical sections are as follows:

• When multiple threads need access to shared memory or resources and the timing of the access can be critical to the eventual result
• Times when processes need to communicate with each other to proceed, often implemented as message passing between processes
• Cases where all concurrent processes must finish before execution of the program proceeds
• Cases where one or more of the processes need some result from another process

As visible in Figure 7.22, when processes run in a requested order, synchronization is occurring.

Figure 7.22 When multiple threads seek access to a critical section, they need synchronization. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Since the goal is to avoid negative race conditions, we do not want to over-synchronize because it lessens the degree of parallelism that we need for performance.

Implementing Synchronization

Synchronization must be carefully implemented to avoid situations that synchronization itself can cause:

• starvation: when a process must wait to enter a critical section, but the other processes monopolize the section, and the waiting process doesn’t get processor time.
• busy waiting: when a process continually looks to see if it has access to a critical section, taking processor time from all processes.
• deadlock: when multiple threads need a critical section that is being monopolized by one of the processes.

Java is known for its strong implementation of synchronization. When marked as synchronized, it is guaranteed that it can have only one thread executing in it at the same time. Any other thread trying to enter the method or code block is blocked until the running occurrence exits the method or block. The following Java code shows the syntax of using the keyword on a method:

public synchronized void calcAverage() {
   // all of the method code
}

A synchronized method is coordinated on the object that owns the method. In OOP each instance of the object may have its own synchronization. For example, we might have a Car class that owns a method called start(). Each car instance we build has its own copy of the method; therefore, if we are starting a car, no other process can start that particular car. But if we have more than one car, another one may be started concurrently.

The following Java code shows the syntax of using the keyword on a code block within a method:

synchronized (this) {
   // critical section
}

This code will execute exactly as if it was a synchronized method. This keyword refers to the current object, so this code is also synchronizing on the object which owns the code block. This usage provides much more granularity and efficient execution times.

Another powerful tool for synchronization in Java is to declare a whole class as a thread, meaning the whole class is within a single thread of execution. There are two ways to do this. The first is having the class inherit from the Thread class from the Java API:

public class SomeThread extends Thread {
}

The other way is to have the class implement an interface from the API:

public class SomeThread implements Runnable {
}

Either of these methodologies provides access to the useful methods of the Thread class which are inherited and can be overridden to support the particular situation. The interface forms a contract with the programmer to implement these methods to support the particular task.

A Thread object is controlled by a priority-based scheduler. Some of the most important methods at the programmer’s disposal are as follows:

• start(): causes the thread to begin execution
• yield(): tells the thread scheduler that the current thread is willing to yield its control
• sleep(int time): causes the currently running thread to temporarily hibernate for a specified number of milliseconds
• setPriority(int priority): changes the priority of the current thread
• join(int time): waits for the indicated milliseconds before commanding the thread to die