Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » .NET Framework »
Discover your business objects and classes [For those who can't code or design]
|
Terminology:
OOAD: object oriented analysis and design
OOP: object oriented programming.
Class: A set of code defining the behaviour of an object.
Object: An entity that can be created from a class by instantiating the class.
Instantiate: This is the action that creates an object from a class (an instance of a class).
Introduction:
This article is for anyone who feels a need to understand software design and development. It explains how to derive the business objects in software application without using too many technical terms.
Objects:
Normally an object is an entity that has mass, shape, volume and is visible. So we think of a pencil or a hammer as an object. But we don’t think of an electric field as an object as it doesn’t have mass, shape, visibility or space that are perceived by our human senses. Even so, an electric field is an object. Let us study this in more detail.
In case of a pencil we can see, feel and even smell it. It has characteristics like weight, color, size and shape. It has parts like the lead, eraser and the wood in which the lead is embedded. The parts too have characteristics like color, length and width. With the aid of the pencil we can perform actions like writing and sketching. All these features contribute to our perception of the pencil being an object. On the other hand the electric field is invisible, has no smell, taste and cannot be felt. But with special equipment we could determine the intensity, range of influence, direction and source of the electric field. The electric field may perform actions like creating a magnetic field in a steel object (similar to a pencil performing writing). Hence both the pencil and the electric field have features typical of objects.
In a business oriented software application, a 'business' object must have characteristics (in programming terms properties and attributes) and it may have methods and events. In OOP though we only need to instantiate a class to create an object. This concept does not suffice for an entity to be considered as a business object. An object provides reusable code.
Each part of a pencil may have its own characteristics and could also be treated as an object. For example depending upon the type of pencil its lead could be made graphite, it may be soft and the thickness could vary too. An object would normally have a purpose. The purpose of a pencil could be to write, sketch, doodle etc. This purpose is achieved by an user doing some action like writing, sketching, doodling etc. The actions that can be performed by using an object are called methods in programming. An action may have an event associated with it. This event may be fired when its corresponding action is performed. When we use the pencil to write, an event called 'OnWriting' could be fired to let a listener know that the action (writing) occurred. Similarly 'OnStartWriting', 'OnEndWriting' identify that writing has started and ended respectively. An event handler delegates work to an event receiver. An event receiver is a code/method that is executed when an event is fired. The attributes, methods and events all contribute to the behaviour of an object.
Classes:
To create objects in programming we use classes. The classes serve as templates that contain the attributes, methods and events of the object. From the software perspective the pencil as a whole can be an object. Again the parts of the pencil can be objects too. To create a pencil we could proceed as follows. First we define a class called PencilClass having the most basic features of the pencil. The basic feature of a pencil would be the lead and the lead holder. Without these two features the pencil would not be a pencil. So these two features are defined in a basic class called the base class (in our case the PencilClass) having the attributes 'lead' and the 'leadholder'.
The other parts of the pencil like the eraser, the eraser holder and other add-ons are optional and depend upon the requirements. Therefore we do not include these attributes in the base class. Instead another class having these attributes may be used. This other class say 'ColorPencilClass' could extend the PencilClass (ithe base class in this case) with attributes that are available in pencils used for coloring. Do not simply extend the PencilClass in a ElectricFieldClass unless they have some common behaviour between them and more pencil related features are provided by extending the PencilClass in a ElectricFieldClass.
E.g. 'Pencilcolorname' can be an attribute of the class ColorPencilClass that identifies the pencil by a color name.
This characteristic could be of more significance for a color pencil than for a writing pencil. The ColorPencilClass itself does not define the basic attributes required for a pencil. Instead we 'inherit' the PencilClass in the ColorPencilClass. In doing so the attributes of the PencilClass are made available in the ColorPencilClass without having to define them again. In this case the PencilClass plays the role of the base class and the ColorPencilClass becomes the derived class. In the same way the PencilClass could be extended by another class say the 'WritingPencilClass'. This way the WritingPencilClass would have the attributes of the PencilClass as well as its own attributes. The main idea behind inheriting a class is to separate the basic common features of a group of related classes. The class that inherits a base class is called the derived class. The derived class extends (i.e. adds more definition to) the base class.
The pencil's lead and eraser can be considered as subcomponents of the pencil object with their own features and can be treated as separate objects having their own classes (say LeadClass, LeadHolderClass). We could even identify components for the existing components. For example the material of the lead could itself be an object with its own class (say MaterialClass) having its own attributes. To decide on what objects (and their classes) are required would invlove a proper understanding on how exactly each object fits into the general scheme of things (i.e. the requirements software application or system we are trying to design). As a thumb rule an entity that has attributes could be a candidate for a class.
For example depending upon our requirements the purpose the pencil changes. A draftsman would give more importance to the lead provided while a little child would be more concerned with the physical appearance. Similarly in software if the application is going to be used to manufacture pencils, then each part and sub part of the pencil would need to be defined clearly and in greater detail. Each part of the pencil would also be an object and have its own class. But if the software was used to purchase a pencil for a normal office use then its details could be defined more simply. In this case 'lead' and 'lead holder' are not treated as separate objects having their own features. Instead the pencil could have an attribute called PencilType which could take different values like 'Fine', 'Regular' and 'Ordinary'.
Below are some of the classes to create pencil objects.
Class name: SimplePencilClass
Attributes: Lead, Leadholder, Length, Width, Color, Weight.
Methods: Write, Draw, Render
Events: OnStartWriting, OnEndWriting, OnWriting
Class name: AdvancedPencilClass
Attributes: (object) Lead, (object) LeadHolder, Color
Methods: Write, Draw, Render
Events: OnStartWriting, OnEndWriting, OnWriting
Class name: ColorPencilClass inherits PencilClass (or AdvancedPencilClass)
Attributes: Colorname
Methods: Draw
If the parent class gives access to its members the ColorPencilClass would also have the attributes, methods and events of its parent class by default. The Draw method in the class ColorPencilClass would override (supercede) the same method in the base class and instead apply its own implementation of this method.
Identifying objects in an application:
Consider an application that helps students register for courses. Most registration forms would have sections for personal details, address, educational details, address and referrals. Let us take a closer look at the address. The address part of an application would typically contain details like building number, street name, block/locality name, town/village name, district/county name, state/province name, country name and zip/pin code. Therefore we could have a separate class for the address portion alone say 'AddressClass'. Now each item of the address section in the registration form could be treated as an attribute of the AddressClass. Again items like town, state and country could be objects themselves. If each of these items could have more than one attribute, then they could become candidates for objects too. Assume that the item 'state' has attributes like state identity, state name, and country identity. By making it an object we would also facilitate future additions to the state like the state area, state population, state language and state ranking. On the other hand many registration applications require that the item 'town' have only the town name. This is a simple text. Here the town does not have a unique identity or be mapped to a state and there is no possibility of adding more attributes in the future. Therefore the town could be an attribute of the AddressClass and not another object by itself.
Summary:
It is essential to identify business objects and their classes with respect to the application we are developing and not by blindly imitating real life situations or other applications. Understanding the business requirements of the applications would be the ideal starting point to identifying objects.
Links
http://www.codeproject.com/Purgatory/System_Design.asp
|
Responses
|
| Author: Irfan Patel 16 Jul 2004 | Member Level: Silver Points : 0 | Thats a great article buddy!!
Its really difficult to teach things from the scratch and u did a phenomenon job !!
Even I love to write articles for beginners and intermediate !!
Kudos to u !!
keep up the good work !!
-
Irfan Patel (MCSD)
New Mumbai India
| | Author: Salu Soz 19 Aug 2004 | Member Level: Bronze Points : 0 | This is an excellent article.
Complex objects are made very simple and neatly explained with the example of visual pencil object.
Publish more such article on .NET
Salu Soz.
| | Author: sandeep Avh 26 Mar 2008 | Member Level: Diamond Points : 0 | it is really good,simple and understanding article
|
|