The traditional imperative programming paradigm separates input, output, data, control and processing as distinct components. It is convenient to split computers into these components but is it the best or most appropriate way of doing things? The natural world, and in particular the human thought process, does not make this distinction.
We need to consider new ways of combining and viewing components of computer systems. Perhaps there are better ways of integrating components that will assist software developers in the production of more 'natural' products. Building Blocks Consider....You need all the components required to write a letter; paper, pen, envelope and stamp. You need to know what to write, how to get to the post box, some idea of the time it takes for a letter to be delivered, etc… We could continue on and on, however the point is that
Let us try to develop a list of building blocks used when we make decisions and solve problems such as the one outlined above. There are various ways of approaching the solution to a problem. Each of these requires a set of components or building blocks upon which the approach or paradigm is based. The imperative paradigm we are all familiar with is based on variables and control structures. In this section, we introduce two other paradigms; logic and object oriented. These paradigms are built on different ways of solving problems using different components. Case Study To explain the concepts underpinning each of these paradigms let us consider a particular problem. Be aware that we are examining one particular problem and not all the paradigms are particularly suited to this problem’s solution; nevertheless our example will serve as a worthwhile introduction. The Towers of Hanoi The Towers of Hanoi is a well-known problem, which was first published in 1883 by the French mathematician Edouard Lucas. The object of the game is to move all the disks to a different pole. You can only move one disk at a time and a bigger disk can never be placed on a smaller disk. There are three poles and initially the disks are all on one pole. Try it out: http://www.softschools.com/games/logic_games/tower_of_hanoi/ Our aim in this section is not to come up with an answer but rather to illustrate different paradigms or approaches that could be used to arrive at a solution. Later in this chapter, we will examine how these paradigms are implemented using programming languages. Imperative If we were looking for an imperative method of solution we first need to consider variables.
We could create an array called Disk where for example Disk(3)=1 means the third smallest disk is currently on the first post. Another array called Post maintains the order of disks currently held on each post. Post(1,3)=5 might mean that disk 5 is currently on post 1 and is third from the bottom. An algorithm is then created using control structures. The algorithm controls the movement of the disks to eventually solve the problem. When writing the algorithm we must have a precise understanding of how to solve the problem. Logic From a logic approach we focus on facts and rules. Some initial facts for this problem are that
We could commence our exploration using the fact that all the disks are on the first pole, therefore our first move must involve moving the top disk. As a disk can only be moved from one pole to another, then this disk must be placed on the second or third pole. None of our rules help us to decide which pole so we take a guess and place it on the second pole. What move is next? Moving the second disk seems to make sense. It can’t go on the second pole as it contains a smaller disk; one of the rules says this is not allowed. It can go on the third pole so we place it there. What options do we have now? Can we move the third disk? No. Can we move the smallest disk from the middle pole? Yes, it can move to either pole. Can we move the disk on the third pole? We could move it back to the first pole. Moving the smallest disk makes sense but to which pole? We consider each of these two possibilities. Eventually, moving the small disk to the first pole leads to a dead end so we continue down the other branch. We can learn from the dead ends and introduce ‘rules of thumb’ that will enable us to reduce the dead ends encountered. Object oriented Using an object oriented approach, involves considering each component of the problem as a self-contained unit. Each unit is able to remember things (data/attributes) and do things (methods/operations). There are two types of objects in this problem, disks and poles. We can approach the problem from the point of view of each of these objects. If you were one of the disks then what do you need to know and what do you need to be able to do? Disks need to know how big they are, they need to know what pole they are on and if they are on top of the pole. They also need to ask poles if they can move to them and then know how to move to poles. The size of the disk, the pole it is on and whether it is on top is the data. Asking poles if they can move to them and moving to other poles are the methods. Let us now look at a pole. Poles need to know what disks they have. In particular, they need to know the size of their top disk. This is their data. They also need to be able to reject disks trying to move to them that are larger than their top disk. This is a method. The interaction of the disks and poles results in the eventual solution of the problem. Let us consider the interactions that may occur at the commencement of the solution using an object oriented approach. The top disk sends a message to the second pole asking if it can move there. The pole responds by checking its top disk. In this case, the pole tells the disk it can move. As a result the smallest disk moves to the second pole. The new top disk on the first pole realises it is now at the top so it attempts to move to the second pole. It is rejected. It then requests a move to the third pole and is accepted. The processing continues in this fashion until the final objective is achieved. Our explanation above implies that methods are carried out in a sequential fashion. This is not the case. A number of disks can be simultaneously requesting moves. This is one of the aspects of the object oriented paradigm that makes it so powerful; each object is able to operate on its own. As soon as a disk reaches the top of a pole it can start asking other poles for permission to move. Each disk is in control of itself. Similarly, each pole may be receiving requests from a variety of disks. It is up to the pole to either accept or reject the requests. |
12 SDD > Stem 4.0 Programming Paradigms >