Before I start my article let me explain that I have searched about OOP so much in web and they all talk about creating a class called 'shape' with various subclasses for 'square', 'circle', 'triangle' etc. This is of absolutely no use when I want to build a system to deal with real-world objects such as 'customer', 'product' and 'invoice' which have corresponding database tables. This has often led me to believe that OOP is therefore unsuitable for building common-or-garden business systems.
After that i found few conclusions and summarized all things that i searched on web. I am sure few of my friends will not agree but i am looking for their feedback ... after all it's (understanding OOPS) a common and serious problem among all quality coders .. ;)
Almost every piece of terminology used in OO seems to mean different things to different people. Some of the arguments which caused this article were:-
What does 'encapsulation' really mean?
What does 'separation of roles' really mean?
What does 'having separate layers' really mean?
What does 'visibility' really mean?
What does 'dependency' really mean?
What does 'object oriented' really mean?
What do I make into a class?
How many objects is too many?
How many objects is too few?
When is an object too big?
When is an object too small?
Whose design patterns should I use?
Which design patterns should I use?
All the while these simple questions do not have simple answers which are universally accepted then it will be impossible to produce software which satisfies everybody. No matter how hard you try someone somewhere will always find a reason to denigrate your efforts. If you use method 'A' then to the followers of method 'A' you are a hero while to the followers of method 'B' you are a heretic. If you switch to method 'B' then the followers of method 'A' will call you a heretic.
The Principles of OOP and Definitions:-
| Writing programs which are oriented around objects. Such programs can take advantage of Encapsulation, Polymorphism, and Inheritance to increase code reuse and decrease code maintenance. | |
| A class is a blueprint, or prototype, that defines the variables and the methods common to all objects of a certain kind. | |
| An instance of a class. A class must be instantiated into an object before it can be used in the software. More than one instance of the same class can be in existence at any one time. | |
| The act of placing data and the operations that perform on that data in the same class. The class then becomes the 'capsule' or container for the data and operations. | |
| The reuse of base classes (superclasses) to form derived classes (subclasses). Methods and properties defined in the superclass are automatically shared by any subclass. | |
| Same interface, different implementation. The ability to substitute one class for another. This means that different classes may contain the same method names, but the result which is returned by each method will be different as the code behind each method (the implementation) is different in each class. | |
| Describes the contents of a module. The degree to which the responsibilities of a single module/component form a meaningful unit. The degree of interaction within a module. Higher cohesion is better. A high cohesion method will be simpler to reuse, and to extend, so it will maximize reusability and extendability. | |
| Describes how modules interact. The degree of mutual interdependence between modules/components. The degree of interaction between two modules. Lower coupling is better. Low coupling tends to create more reusable methods. It is not possible to write completely decoupled methods, otherwise the program will not work! | |
| The ability to 'see' parts of an object from outside. Any method or property marked as 'public' is visible, whereas any method or property marked as 'private/protected' is not visible to the outside world and is therefore 'hidden'. Methods and properties which should not be directly accessed from outside should be hidden. Lower visibility is better. | |
| The degree that one component relies on another to perform its responsibilities. High dependency limits code reuse and makes moving components to new projects difficult. Lower dependency is better. |
Each real-world entity is modeled with its own class containing properties (variables or data) and methods (functions or operations which act upon, or change the 'state' of, those properties).
Reference: What is a Class?
A 'class' is not an 'object', it is the blueprint, pattern or prototype that defines how an object will look and behave when it is created or instantiated from that class. Software must create an object (an instance of a class) before it can access any of its methods (functions) or manipulate any of its properties (data).
Reference: What is an Object?
'Encapsulation' means that the class must define all the properties and methods which are common to all objects of that class. All those properties and methods must exist inside a single container or 'capsule', and must not be distributed across multiple locations.
Reference: encapsulation The localization of knowledge within a module. Because objects encapsulate data and implementation, the user of an object can view the object as a black box that provides services. Instance variables and methods can be added, deleted, or changed, but as long as the services provided by the object remain the same, code that uses the object can continue to use it without being rewritten.
'Implementation Hiding' means that the outside world may know about the properties and methods that exist within a class, but it does not know how each method is actually implemented. This allows the implementation to be changed at any time without the outside world being affected or even knowing that the implementation has changed.
'Inheritance' is where the properties and methods of one class (the 'superclass') are shared by another class (the 'subclass'). The subclass may choose to override any properties or methods defined in the superclass with its own specific variations, or it may choose to add extra properties and methods of its own (i.e. 'extend' the superclass). Inheritance is the mechanism whereby common code is shared between one class and another.
Reference: What is Inheritance?
An 'abstract method' is one which is defined in the superclass as nothing but an empty placeholder. The actual implementation is defined within a subclass. Different subclasses may have different implementations of the same abstract method.
An 'abstract class' is one which cannot be instantiated into an object because it does not contain any implementation details. These missing details must be supplied via a subclass so that the combination of the two, the superclass and the subclass, is then capable of being instantiated into an object. The subclass provides the missing implementation details by overriding methods and/or properties defined within the superclass. Different subclasses may therefore provide different implementation details.
Reference: abstract class A class that contains one or more abstract methods, and therefore can never be instantiated. Abstract classes are defined so that other classes can extend them and make them concrete by implementing the abstract methods.
'Polymorphism' is where different classes may have methods with the same name as other classes, but where the response obtained from those methods is determined by the object itself. In other words: same interface, different implementation; or the ability to substitute one class for another.
Few Facts that should know about encapsulation:-
Encapsulation is the same as Information Hiding.
Information Hiding is the same as Data Hiding.
Data Hiding means not using public variables.
Therefore: Encapsulation is the same as not using public variables. :)
Consider these articles I found after a quick search of the Internet using google and the word 'encapsulation' mean :
Encapsulation is not information hiding by Wm. Paul Rogers of Java World
Abstraction, Encapsulation, and Information Hiding by Edward V. Berard of The Object Agency
Encapsulation Wasn't Meant To Mean Data Hiding by Martin Fowler
Here is a definition of 'data hiding' I found at SearchDatabase.com:
Data hiding is a characteristic of object-oriented programming. Because an object can only be associated with data in predefined classes or templates, the object can only 'know' about the data it needs to know about. There is no possibility that someone maintaining the code may inadvertently point to or otherwise access the wrong data unintentionally. Thus, all data not required by an object can be said to be 'hidden'. Even more off the wall is the idea being touted around in some quarters that inheritance breaks encapsulation (refer to the third paragraph).
What are the benefits of OO Programming?
Advocates of OOP often make brash claims as to why developers should switch from 'old-fashioned' procedural programming to 'new-fangled' object oriented programming. Among these claims are:
Faster development through the use of more reusable code.
Easier maintenance as business logic is not duplicated in multiple places.
and so on, and so on, ...
It is quite clear to me that object oriented programming is anything but simple. What started life with a few simple principles - that of encapsulation, inheritance and polymorphism - has quickly grown into a multi-headed beast which means something totally different to different people. The original definitions have been redefined, re-interpreted, expanded and mutated beyond all recognition.
At Last few links that forced me to write this article:-
No comments:
Post a Comment