Encapsulated Data Of The Object example essay topic

Object-Oriented Programming the desire for an easy transition from existing languages ABSTRACT Now it is clear that Object-Oriented Software Development is here to stay and is the preferred way to develop software. To be successful in the world of object-oriented programming (OOP) one has to unlearn quite a few of the habits acquired from the years of procedure-oriented programming and learn some new ways of looking at the problems. Object-oriented technology is the wave of today. Thus it is my intent in this paper to give a brief overview of object-oriented programming, discuss the concepts of abstraction, encapsulation and information hiding (as applied to OOP). This paper will also show the importance of OOP in software re-use and also try to distinguish between object-oriented languages and object-based languages. Keywords Encapsulation, object-oriented programming (OOP), abstraction, objects, classes.

INTRODUCTION Object-Oriented Programming requires a thorough understanding of some fundamental paradigms, or concepts. Understanding these paradigms is essential to building a strong foundation in the OO software world. Any language that supports OOP must support these fundamental paradigms. In other words, learning a set of powerful paradigms that are supported by many languages like Smalltalk, C++, Java, etc. Learning the syntax of a language that supports OPP is not the same as learning the concepts of OOP. One might be good in C++ or Java without any knowledge whatsoever of the basic OOP paradigms.

On the other hand, anyone who understands the fundamental concepts of OOP will be able to use those concepts effectively with any languages that support OOP and they should also know when to use a particular concept. So learning OOP concepts is just one milestone, but that is not the ultimate destination of any programmer / designer. One should be able to apply these concepts to problems in one's domain or area of expertise. Thus this paper tries to briefly discuss some concepts involved in object-oriented programming. BACKGROUND Although object-oriented technology has come into limelight only recently, it is actually more than twenty years old according to David Taylor [1].

He went on to say that all the basic concepts of the object-oriented approach were introduced in the Simula programming language developed in Norway during the late 1960's. Simula, an acronym for "simulation language", was created to support computer simulations of real world processes. The authors of Simula O.J. Dahl and Kristen Nygaard, wanted to build accurate working models of complex physical systems that could contain many thousands of components. It was apparent even back in the sixties that modular programming is essential for building complex systems, and modular ization plays a central role in Simula. But despite all efforts to find the better ways to build programs, the software crisis is growing worse with each passing year.

We need a new approach to building software, one that leaves behind the bricks and mortar of conventional programming and offers a truly better way to construct systems. This new approach must able to handle large systems as well as small, and it must create reliable systems that are flexible, maintainable, and capable of evolving to meet changing needs. Object-oriented programming can meet these challenges and even do more. Now in order to understand OOP let us first discuss what OOP is. What is OOP? Different authors define object-oriented programming as follows: "A style of design that is centered around the delegation of responsibilities to independent interacting agents, and a style programming characterized by the use of message passing and classes organized into one or more inheritance hierarchies".

[2] "OOP is a method of programming in which programs are made up of cooperating objects (which are instances of a class). Further the classes themselves are probably related using inheritance relationships" [3] Now let us try to describe OOP in details. According to Jag and Prince Sodhi [5] OOP is a method of implementation in which programs are represented as instances of classes and classes may be arranged in a hierarchy. The programming implements objects in an object-oriented language. OOP is defined as structured and designed around objects. Object-oriented programming includes encapsulation (the class concept), extensibility (inheritance by prefixing), and reusability (specialization and dynamic bidding).

In OOP, the class serves as the abstraction mechanism whereby concepts are formalized. Classes resemble abstract data types in that they contain both data and the code that manipulates the data. Also the classes can be multiple instantiations of objects that can be used to build data structures. Furthermore, an existing class can be extended or specialized with the help of a prefixing mechanism, whereby a subclass inherits attributes from its parent class.

This facilitates the development of reusable software. OOP is an ideal design for the next generation programming techniques. This is why the American National Standard Institute's (ANSI's) Object-Oriented COBOL Task Group is working to remodel COBOL as an OOP language, and it will be called COBOL Object-Oriented Language (COOL). Over time, legacy application code could be retooled into objects, probably with assistance from artificial-intelligence-based conversion products. The basic concepts of OOP are encapsulation, inheritance, polymorphism, dynamic programming, constructors, and destructors. These terms will be explained in detail in the next section of this paper.

Jag and Prince Sodhi [5] went on to say that OOP allows for the creation of a "computer" representation of the problem such that there is a one-to-one relationship between the computer world and the real world. This abstraction can accurately capture the constraints of real-world objects as well as model the operations that occur in the real world. The solution space is a replica of the problem space. Objects are created that represent their real-world counter-parts. The process of solving the problem shows that the objects should be and what they should look like.

OOP includes identification of objects, classes, and inheritance. OOP supports polymorphism during the runtime environment. Polymorphism covers binding that also include dynamic binding. OOP defines a new type of objects in terms of an existing one, called inheritance. Adding new components by adding new properties to an object, as well as adding or redefining the operations allowed on the object, is called type extension. OOP explicitly identifies common characteristics of the kinds of objects represented.

The objects contain hierarchies of categories that group common characteristics. It defines objects by the use of categories and performs interactions between the main program and objects. Also OOP performs interactions between different objects via operation of the object. This hierarchical categorization establishes a set of relationship where all the entities represent kinds of objects throughout the software model.

Now let us discuss the following concepts of OOP Abstraction According to Timothy Buddy [2] abstraction is " a technique in problem solving in which details are grouped into a single common concept. This concept can then be viewed as a single entity and nonessential information ignored". In other words abstraction is the " stripping away of irrelevant details in order to concentrate on the relevant information. It is a means for coping with complexity, and it is a natural part of problem solving. Informally, abstraction can be described as looking at the big picture" [4]. Kayshav Dattatri [3] define data abstraction as" a result of defining classes with emphasis on the similarities of its objects an ignoring their differences.

Further, uninteresting and distracting elements are suppressed while major features of the class (the abstraction) are projected. A class is an abstraction. Stated a bit differently, an abstraction focuses on the outside view of an object and clearly separates its essential behavior from the internal implementation details". To conclude the definition of abstraction Jag and Prince Sodhi [5] see abstraction as an aid to "software design so that the software engineers can disregard nonessential details and concentrate on the problem space.

Abstraction is closely related to the goal of modification and promotes good modularity". He went on to make an example of when pointing a personal computer (PC) on your desk, you think of the abstract word computer for this object, not a box that consists of memory chips, integrated electronic circuits, capacitors, resistors, inductors, or power supplies. The essential details of the object computer to some of you are visual display and keyboard, while to others they may be modems, printer, disk drive, etc. Inessential details are integrated circuits, memory chips, capacitors, and resistors. Encapsulation Timothy Budd [2] defines encapsulation as the "technique of hiding information within a structure, such as the hiding of instances data within a class. According to Kayshav Dattatri [3] encapsulation "is the results of hiding the internal implementation details of abstraction.

It clearly separates the external interface of an abstraction from the internal (mundane) implementation details. Encapsulation and abstraction are complimentary to each other. A good abstraction encapsulates something and the encapsulated entity helps the abstraction to maintain its integrity. It is important to note that abstraction precedes encapsulation.

Encapsulation is in focus only when implementation begins. In simple terms encapsulation is the grouping of an "object's state and behavior into a single unit". [4] Jag and Prince Sodhi [5] takes the definition of encapsulation into another level when they describe encapsulation as follows: Encapsulation means that an object contains both a state and an operation that can be performed on that state. The bundling of procedures and data, called encapsulation, is the foundation of the object-oriented concept.

Actions on an object's state are called methods and are initiated by messages that are sent to the object. The encapsulated data in an object are not freely accessible from outside the object. Only an object's own methods can directly manipulate its data. Methods are invoked either by another method of the object or by a procedure call from another object (message) within the application program. He went on to say that with encapsulation, the user does not worry about how an abject performs its function, and the user simply knows what the object can and cannot do. Users can be confident that when an object is added to the existing code, unpredictable things will not happen to other parts of the program.

Also encapsulation is the opposite of abstraction. Abstraction focuses upon the observable behavior of an object, and encapsulation focuses upon the implementation of the behavior. Encapsulation hides the implementation details whereas the user of the abstraction knows only the essence of behavior. We can went on and on describing data encapsulation, but now let us look at the benefits of data encapsulation according to Kayshav Dattatri [3]: When data is encapsulated, clients do cannot directly access, let alone modify, the encapsulated data of the object. Only the interface functions can access / modify the encapsulated information. Further, users of the interface will not have any knowledge as to how the functions that describe the interface use the encapsulated information, and it is no interest to the users of the object (or class).

Because it is guaranteed by the postulates of OOP that the encapsulated information is accessible only through the published interface, the integrity of the object is assured. Another benefit of data encapsulation is Implementation Independence. Since the users of a class do not see the encapsulated data (or information), they are not even aware of the existence. Therefore the interface seen by the user is not affected (and should not be affected) by a change in the encapsulated data.

As much as there are benefits to encapsulation, one must take certain precautions when doing data encapsulation. It is a good idea to encapsulate information that is of no importance to the user. However, users might need to access the encapsulated information in order to use the object effectively. When some element is encapsulated, the implementor has to provide facilities in the interface to access or manipulate the encapsulated information. The access provided may be restricted or controlled. However, the interface must provide proper facilities to access / modify the encapsulated entity.

If an abstraction encapsulates a piece of information that is very important for the user but fails to provide proper facilities to access the encapsulated information, the abstraction is not correct (i. e., the interface is not sufficient). The next point to discuss is what (and when) to encapsulate data: O If an item does not add any value to the user's perception of the class, encapsulate that item; i. e., removing that item from the interface does not reduce the usefulness of that class in any way. O If an item is a piece of sensitive data (trade secrets, patented information, personal information, etc.) encapsulate it so that the users cannot access it directly. O If some item is hazardous and requires special skills to handle (which normal users might not have), encapsulate it.

O If the class use some elements for its own housekeeping and it does not add any value to the interface, it should be encapsulated. O If some item is subject to change in the future (to use newer technology or to make it faster or safer) it should definite be excluded from the interface of the class. Information hiding Timothy Budd [2] [6] defines information hiding as "the principle that users of software component (such as a class) need to know only the essential details of how to initialize and access the component, and do not need to know the details of the implementation. By reducing the degree of interconnectedness between separate elements of a software system, the principle of information hiding helps in the development of reliable software". A lot of authors describe information hiding and encapsulation as one and the same thing but the authors of [4] see encapsulation as the grouping of the object's state and behavior into a single unit, thus in so doing encapsulation provides a way of shielding an object's data from any direct manipulation from the outside and this concept is known as data hiding.

Jag and Prince Sodhi [5] describe information hiding as follows: "Information hiding and abstraction are practically synonyms except information hiding is the ability to access data. Here, only the operations on an object are visible to an application program; the data and the way the operation are implemented are hidden. Therefore, no operations can be performed other than those specified in the interface. Information hiding (and encapsulation) makes application more flexible and extensible and provides more reusable code". Jag and Prince Sodhi [5] went on to say that both information hiding and encapsulation are mechanisms that hide code and data from application programs and protect them from implementation changes in the system's lower layers.

Information hiding and encapsulation allow the software developer to create a clean interface between the specification and the implementation of an operation. As a result, an object-oriented application program is effectively independent of the implementation of the operations it uses. In addition to what Jag and Prince Sodhi [5] have already say they continue to describe information hiding as the protection of implementation details in an object-oriented software. Information hiding is the deliberate hiding of information from those who might misuse it. This differentiates the "what" from the "how". The "what" is essential information that should be available to everyone?

This information includes specifications and interfaces information. The "how" information should be available only to a limited group and includes implementation details such as data structure. Also information supports and enforces abstraction by the suppression of details. It increases quality and supports reusability, portability, and maintainability.

It avoids confusion for the user, promotes correct data input, and enhances reliability. Information hiding enhances localization and usually includes cohesive data. Hence good modularity is achieved, and the goal of modifiability is more easily approached. Let us now discuss reusability of software in object-oriented programming.

The code reuse is performed from the beginning of the OOP coding process, as all similar characteristics of a set of objects are factored into the uppermost level of hierarchy that contains them. Software reuse will not happen automatically in OOP. The power of OOP languages is that they allow easy reuse of code. The fact that most of OOP languages has built-in class libraries, programs can be pieced together with minimal coding. If you program a class that implements a "patient" object for one system, you can use that same code when another system need a "patient" object. In fact, the more systems you implement in OOP languages, the better you will be able to reuse code, as it becomes more likely that you have already coded an object in a past system.

Polymorphism combines with dynamic binding and helps move OOP closer to the ideal of a truly generic code. This helps when code is being written which specifies only generic instructions and delegate's implementation details to particular involved objects. So to make reuse possible, programmers will write code in form of independent segments called objects. Thus the same code can be reuse on several different types of objects. This implies that we need not care how a task is handled inside an object, only that the object does what we want when we send the correct message.

So a program could include an entire set of objects. All objects derived from different object classes that respond to the same messages, even though their methods are different. As much as software reusability is important, there are always limitations to the reuse of existing software. This depends on customer requirements, which may prevent the reuse of existing software. These limitations occur because the software design is not clear enough or does not provide any guidelines for software reuse. Or this can occur when software reuse documentation is not clear enough for effective reuse in particular software.

It is then more economical for new software to be written than to reuse an existing one. To conclude the software reusability, let us briefly describe the software reusability process activities: O Construct means the reuse of existing methods and products. O Collect is the reuse of the existing library and continues building it. O Catalog is the reuse of descriptive information.

O Classify is the reuse of semantic and functional information. O Comprehend means the reuse of resources identification and analysis. O Customize is the development of applications from reusable resources. Finally let us look at the main distinction between object-oriented languages and object based languages. The definitions of object-oriented programming as objects + classes + class-based inheritance and object-based programming as a language with objects but without classes and class-based inheritance is the main difference between the two. CONCLUSION "OOP is not a panacea that solves all the software development problems.

OOP's weakness lies in the learning of an object-oriented language. Depending on the degree of expertise, coding time will be comparatively longer. It will be necessary for management to change the process and the culture to accept the objects. It requires a change in expectations and attitude for OOP. Once management and software developers understand and experience OOP in developing systems, perceptions about OOP will change". [5] As I said in the beginning OOP and object-oriented technology in general are here to stay and are the preferred ways in software development.

Bibliography

1. David A. Taylor, Object-oriented Technology: A Manager's Guide, Addison-Wesley, 1994.
2. Timothy Budd, An introduction to Object-Oriented Programming, Addison-Wesley, 1997.
3. Kayshav Dattatri, C++ Effective Object-Oriented Software Construction Concepts, Principles, Industrial Strategies, and Practices, Prentice Hall, 1997.
4. Edith Au, Dave Mak ower and the Pencom Web Works, JAVA Programming Basics, Pencom Systems Incorporated, 1996.
5. Jag Sodhi and Prince Sodhi, Object-Oriented methods for Software Development, McGraw-Hill, 1996.
6. Timothy Budd, An introduction to Object-Oriented Programming, Addison-Wesley, 1991.