Object-Oriented Programming (OOP) is the term used to describe a programming approach based on objects and classes. The object-oriented paradigm allows us to organise software as a collection of objects that consist of both data and behaviour. This is in contrast to conventional functional programming practice that only loosely connects data and behaviour. Since the 1980s the word 'object' has appeared in relation to programming languages, with almost all languages developed since 1990 having object-oriented features. Some languages have even had object-oriented features retro-fitted. It is widely accepted that object-oriented programming is the most important and powerful way of creating software. The object-oriented programming approach encourages:
An object-oriented programming language generally supports five main features:
If we think of a real-world object, such as a television (as in Figure 1.1), it will have several features and properties:
In many ways this compares very well to the notion of a class. A class should:
With a functional programming language (like C) we would have the component parts of the television scattered everywhere and we would be responsible for making them work correctly - there would be no case surrounding the electronic components. Humans use class based descriptions all the time - what is a duck? (Think about this, we will discuss it soon.) Classes allow us a way to represent complex structures within a programming language. They have two components:
The notation used in Figure 1.2 on the right hand side is a Unified Modelling Language (UML) representation of the An instance of a class is called an object. An object is an instance of a class. You could think of a class as the description of a concept, and an object as the realisation of this description to create an independent distinguishable entity. For example, in the case of the Television, the class is the set of plans (or blueprints) for a generic television, whereas a television object is the realisation of these plans into a real-world physical television. So there would be one set of plans (the class), but there could be thousands of real-world televisions (objects). Objects can be concrete (a real-world object, a file on a computer) or could be conceptual (such as a database structure) each with its own individual identity. Figure 1.3 shows an example where the The object-oriented paradigm encourages encapsulation. Encapsulation is used to hide the mechanics of the object, allowing the actual implementation of the object to be hidden, so that we don't need to understand how the object works. All we need to understand is the interface that is provided for us. You can think of this in the case of the There is a sub-set of functionality that the user is allowed to call, termed the interface. In the case of the television, this would be the functionality that we could use through the remote control or buttons on the front of the television. The full implemenation of a class is the sum of the public interface plus the private implementation. Encapsulation is the term used to describe the way that the interface is separated from the implementation. You can think of encapsulation as "data-hiding", allowing certain parts of an object to be visible, while other parts remain hidden. This has advantages for both the user and the programmer. For the user (who could be another programmer):
For the programmer:
So, providing the programmer does not change the interface in any way, the user will be unaware of any changes, except maybe a minor change in the actual functionality of the application. We can identify a level of 'hiding' of particular methods or states within a class using the
Figure 1.5 shows encapsulation as it relates to the If we have several descriptions with some commonality between these descriptions, we can group the descriptions and their commonality using inheritance to provide a compact representation of these descriptions. The object-oriented programming approach allows us to group the commonalities and create classes that can describe their differences from other classes. Humans use this concept in categorising objects and descriptions. For example you may have answered the question - "What is a duck?", with "a bird that swims", or even more accurately, "a bird that swims, with webbed feet, and a bill instead of a beak". So we could say that a Duck is a Bird that swims, so we could describe this as in Figure 1.6. This figure illustrates the inheritance relationship between a For example: if were to be given an unstructured group of descriptions such as Car, Saloon, Estate, Van, Vehicle, Motorbike and Scooter, and asked to organise these descriptions by their differences. You might say that a Saloon car is a Car but has a long boot, whereas an Estate car is a car with a very large boot. Figure 1.7 shows an example of how we may organise these descriptions using inheritance. So we can describe this relationship as a child/parent relationship, where Figure 1.8 illustrates the relationship between a base class and a derived class. A derived class inherits from a base class, so in Figure 1.7 the One way to determine that you have organised your classes correctly is to check them using the "IS-A" and "IS-A-PART-OF" relationship checks. It is easy to confuse objects within a class and children of classes when you first begin programming with an OOP methodology. So, to check the previous relationship between The IS-A relationship describes the inheritance in the figure, where we can say, "A Car IS-A Vehicle" and "A SaloonCar IS-A Car", so all relationships are correct. The IS-A-PART-OF relationship describes the composition (or aggregation) of a class. So in the same figure (Figure 1.9) we can say "An Engine IS-A-PART-OF a Vehicle", or "An Engine, Colour and Wheels IS-A-PART-OF a Vehicle". This is the case even though an Engine is also a class! where there could be many different descriptions of an Engine - petrol, diesel, 1.4, 2.0, 16 valve etc. So, using inheritance the programmer can:
When a class inherits from another class it inherits both the states and methods of that class, so in the case of the Polymorphism means "multiple forms". In OOP these multiple forms refer to multiple forms of the same method, where the exact same method name can be used in different classes, or the same method name can be used in the same class with slightly different paramaters. There are two forms of polymorphism, over-riding and over-loading. As discussed, a derived class inherits its methods from the base class. It may be necessary to redefine an inherited method to provide specific behaviour for a derived class - and so alter the implementation. So, over-riding is the term used to describe the situation where the same method name is called on two different objects and each object responds differently. Over-riding allows different kinds of objects that share a common behaviour to be used in code that only requires that common behaviour. Consider the previous example of the
Over-Loading is the second form of polymorphism. The same method name can be used, but the number of parameters or the types of parameters can differ, allowing the correct method to be chosen by the compiler. For example: add (int x, int y) add (String x, String y) are two different methods that have the same name and the same number of parameters. However, when we pass two The number of arguments can also determine which method should be run. For example: channel() channel(int x) will provide different functionality where the first method may simply display the current channel number, but the second method will set the channel number to the number passed. An abstract class is a class that is incomplete, in that it describes a set of operations, but is missing the actual implementation of these operations. Abstract classes:
For example: In the As discussed previously, a class is like a set of plans from which you can create objects. In relation to this analogy, an abstract class is like a set of plans with some part of the plans missing. E.g. it could be a car with no engine - you would not be able to make complete car objects without the missing parts of the plan. Figure 1.11 illustrates this example. The If we required we could also tag the As discussed previously, object-oriented programming has been around since the 1990s. Formal design processes when using objects involves many complex stages and are the debate of much research and development. Consider the general cycle that a programmer goes through to solve a programming problem:
The Waterfall Model[1], as illustrated in Figure 1.13, is a linear sequential model that begins with definition and ends with system operation and maintenance. It is the most common software development life cycle model and is particularly useful when specifying overview project plans, as it fits neatly into a Gantt chart format[2]. The seven phases in the process as shown in Figure 1.13 are:
The Waterfall Model is a general model, where in small projects some of the phases can be dropped. In large scale software development projects some of these phases may be split into further phases. At the end of each phase the outcome is evaluated and if it is approved then development can progress to the next phase. If the evaluation is rejected then the last phase must be revisited and in some cases earlier phases may need to be examined. In Figure 1.13 the thicker line shows the likely path if all phases are performing as planned. The thinner lines show a retrace of steps to the same phase or previous phases. The Spiral Model[3] was suggested by Boehm (1988) as a methodology for overseeing large scale software development projects that show high prospects for failure. It is an iterative model that builds in risk analysis and formal client participation into prototype development. This model can be illustrated as in Figure 1.14. The spiral, as shown in Figure 1.14 of development is iterative, with each iteration involving planning, risk analysis, engineering (from design, to coding, testing, installation and then release) and customer evaluation (including comments, changes and further requirements). More advanced forms of this model are available for dealing with further communication with the client. The spiral model is particularly suited to large scale software development projects and needs constant review. For smaller projects an agile development model is more suitable. One object-oriented methodology is based around the re-use of development modules and components. As such, a new development model is required that takes this re-use into account. The object-oriented model as shown in Figure 1.15 builds integration of existing software modules into the system development. A database of reusable components supplies the components for re-use. The object-oriented model starts with the formulation and analysis of the problem. The design phase is followed by a survey of the component library to see if any of the components can be re-used in the system development. If the component is not available in the library then a new component must be developed, involving formulation, analysis, coding and testing of the module. The new component is added to the library and used to construct the new application. This model aims to reduce costs by integrating existing modules into development. These modules are usually of a higher quality as they have been tested in the field by other clients and should have been debugged. The development time using this model should be lower as there is less code to write. The object-oriented model should provide advantages over the other models, especially as the library of components that is developed grows over time. Task: If we were given the problem; “Write a program to implement a simple savings account”… The account should allow deposits, withdrawals, interest and fees. Solution: The problem produces many concepts, such as bank account, deposit, withdrawal, balance etc.. that are important to understand. An OO language allows the programmer to bring these concepts right through to the coding step. The savings account may be built with the properties of an account number and balance and with the methods of deposit and withdrawal, in keeping with the concept of the bank account. This allows an almost direct mapping between the design and the coding stages, allowing code that is easy to read and understand (reducing maintenance and development costs). OOP also allows software re-use! … The concept of this savings account should be understood, independent of the rest of the problem. This general savings account will certainly find re-use in some other financial problem. So after discussion with the client, the following formulation could be achieved - Design a banking system that contains both teller and ATM interaction with the rules:
Bank:
Account:
Deposit Account:
Current Account:
Transaction:
Withdrawal:
Lodgement:
Cheque:
EuroCheque:
CurrencyConverter: Self-assessments allow you to check your understanding of a topic using multiple choice questions. These self-assessments are corrected on-line and provide explanations for questions that you may have answered incorrectly. These assessments are completely anonymous. Please go to the DCU Loop page for this module at loop.dcu.ie © Dr. Derek Molloy [1] Boehm, B. W. (1981) Software Engineering Economics, Ch. 4 Prentice Hall, Upper Saddle River, NJ. Royce, W. W. (1970) "Managing the development of large software systems: concepts and techniques", Proceedings of IEEE WESCON, August 1970. [2] http://en.wikipedia.org/wiki/Gantt [3] Boehm, B. W. (1988) "A spiral model of software development and enhancement", Computer, 21(5), 61-72. |
Course Notes >