INTRANET CHATTING DOCUMENTATION

OBJECT ORIENTED PROGRAMMING AND JAVA

Object-oriented Programming was developed because of limitations found in
earlier approaches of programming. To appreciate what OOP does, we need to
understand what these limitations are and how they arose from traditional programming.

PROCEDURAL LANGUAGES
Pascal, C, Basic, FORTRAN, and similar languages are procedural languages.
That is, each statement in the language tells the computer to do something: Get some
input, add these numbers,, divide by 6, display the output. A program in a procedural
language is a list of instructions.
For very small programs no other organizing principle (often called a paradigm) is
needed. The programmer creates the list of instructions, and the computer carries them
out.
Division into Functions
When programs become larger, a single list of instructions becomes unwieldy.
Few programmers can comprehend a program of more than a few hundred statements
unless it is broken down into smaller units. For this reason the function was adopted as a
way to make programs more comprehensible to their human creators. (The term
functions are used in C++ and C. In other languages the same concept may be referred to
as a subroutine, a subprogram, or a procedure.) A program is divided into functions, and
(ideally, at least) each function has a clearly defined purpose and a clearly defined
interface to the other functions in the program. The idea of breaking a program into
functions can be further extended by grouping a number of functions together into a
larger entity called a module, but the principle is similar: grouping a number of
components that carry out specific tasks. Dividing a program into functions and modules
is one of the cornerstones of structured programming, the somewhat loosely defined
discipline that has influenced programming organization for more than a decade.

Problems with Structured Programming

As programs grow ever larger and more complex, even the structured
programming approach begins to show signs of strain. You may have heard about, or
INTRANET CHATTING DOCUMENTATION

been involved in, horror stories of program development. The project is too complex, the
schedule slips, more programmers are added, complexity increases, costs skyrocket, the
schedule slips further, and disaster ensures. Analyzing the reasons for these failures
reveals that there are weaknesses in the procedural paradigm itself. No matter how well
the structured programming approach is implemented, large programs become
excessively complex.

What are the reasons for this failure of procedural languages? One of the most crucial is
the role played by data.
Data Undervalued
In a procedural language, the emphasis is on doing things--read the keyboard,
invert the vector, check for errors, and so on. The subdivision of a program into
functions continues this emphasis. Functions do things just as single program statements
do. What they do may be more complex or abstract, but the emphasis is still on the
action.
What happens to the data in this paradigm? Data is, after all, the reason for a program's
existence. The important part of an inventory program isn't a function that displays the
data, or a function that checks for correct input; it's the inventory data itself. Yet data is
given second-class status in the organization of procedural languages.
For example, in an inventory program, the data that makes up the inventory is probably
read from a disk file into memory, where it is treated as a global variable. By global we
mean that the variables that constitute the data are declared outside of any function, so
they are accessible to all functions. These functions perform various operations on the
data. They read it, analyze it, update it, rearrange it, display it, and write it back to the
disk, and so on.

We should note that most languages, such as Pascal and C, also support local
variables, which are hidden within a single function. But local variables are not useful
for important data that must be accessed by many different functions. Now suppose a
new programmer is hired to write a function to analyze this inventory data in a certain
way.
INTRANET CHATTING DOCUMENTATION

Unfamiliar with the subtleties of the program, the programmer creates a function
that accidentally corrupts the program. This is easy to do, because every function has
complete access to the data. It's like leaving your personal papers in the lobby of your
apartment building: Anyone can change or destroy them. In the same way, global data
can be corrupted by functions that have no business changing it.
Another problem is that, since many functions access the same data, the way the data is
stored becomes critical. The arrangement of the data can't be changed without modifying
all the functions that access it. If you add new data items, for example, you'll need to
modify all the functions that access the data so that they can also access these new items.
It will be hard to find all such functions, and even harder to modify all of them correctly.
It's similar to what happens when your local supermarket moves the bread from aisle 4 to
aisle 12. Everyone who patronizes the supermarket must figure out where the bread has
gone, and adjust their shopping habits accordingly.
What is needed is a way to restrict access to the data, to hide it from all but a few
critical functions. This will protect the data, simplify maintenance, and offer other
benefits as well.

Relationship to the Real World

Procedural programs are often difficult to design. The problem is that their chief
components--functions and data structures--don't model the real world very well. For
example, suppose you are writing a program to create the elements of a graphics user
interface: menus, windows, and so on. Quick now, what functions will you need? What
data structures? The answers are not obvious, to say the least. It would be better if
windows and menus corresponded more closely to actual program elements.

New Data Types

INTRANET CHATTING DOCUMENTATION

There are other problems with traditional languages. One is the difficulty of
creating new data types. Computer languages typically have several built-in data types:
integers, floating-point numbers, characters, and so on. What if you want to invent your
own data type? Perhaps you want to work with complex numbers, or two dimensional
coordinates, or dates—quantities the built-in data types don’t handle easily. Being able
to create your own types is called extensibility; you can extend the capabilities of the
language. Traditional languages are not usually extensible. Without unnatural
convolutions, you can’t bundle together both X and Y coordinates into a single variable
called Point, and then add and subtract values of this type. The result is that traditional
programs are more complex to write and maintain.

The object oriented approach

The fundamental idea behind object-oriented languages is to combine into a
single unit both data and the functions that operate on that data. Such a unit is called an
object.
An object’s functions, called member methods in Java, typically provide the only way to
access its data. If you want to read the item and return the value to you, you call a
member function in the object. It will read the item and return the value to you. You
can’t access the data directly. The data is hidden, so it is safe from accidental
modification. Data and its functions are said to be encapsulated into a single entity. Data
encapsulation and data hiding are key terms in the description of object oriented
languages. If you want to modify the data in an object, you know exactly what functions
interact with it: the member functions in the object. No other functions can access the
INTRANET CHATTING DOCUMENTATION

data. This simplifies writing, debugging, and maintaining the program.

A Java program typically consists of a number of objects, which communicate with each
other by calling one another’s members functions. We should mention that what are
called member functions in C++ are called methods in Java. Also, data items are referred
to as instance variables. Calling an object’s member function is referred to as sending a
message to the object.

An analogy
You might want to think of objects as departments—such as sales, accounting,
personnel, and so on—in a company. Departments provide an important approach to
corporate organization. In most companies (except very small ones), people don’t work
on personnel problems one day, the payroll the next, and then go out
in the field as sales people the week after. Each department has its own personnel, with
clearly assigned duties. It also has its own data: payroll, sales figures, personnel records,
inventory, or whatever, depending on the department.
The people in each department control and operate on those departments data.
Dividing the company into departments makes its easier to comprehend and control the
company’s activities, and helps them maintain the integrity of the information used by the
company. The payroll department, for instance, is responsible for the payroll data. If
you are from the sales department, and you need to know the total of all the salaries paid
in the southern region in July, you don’t just walk into the payroll department and start
running through file cabinets. You send a memo to the appropriate person in the
department, and then you wait for that person to access the appropriate person in the
department, and then you wait for that person to access the data and send you a reply with
the information you want. This ensures that the data is accessed accurately and that it is
not corrupted by inept outsiders. (This view of corporate organization is show in figure).
In the same way, objects provide an approach to program organization, while helping to
maintain the integrity of the programs data.

OOP: An approach to organization

INTRANET CHATTING DOCUMENTATION

Keep in mind that object-oriented programming is not primarily concerned with

the details of program operation. Instead, it deals with the overall organization of the
program.

Characteristics of object-oriented languages:

Let’s briefly examine a few of the major elements of object-oriented languages in
general and Java in particular.
Objects
When you approach a programming problem in an object oriented language, you
no longer ask how the problem will be divided into functions, but how it will be divided
into objects. Thinking in terms of objects, rather than functions, has a surprisingly
helpful effect on how easily programs can be designed and objects in the real world.
What kinds of things become objects-oriented programs? The answer to this is limited
only by your imagination, but there are some typical categories to start you thinking:

Physical objects
Automobile in a traffic-flow simulation
Electrical components in a circuit design to a program
Countries in an economics model
Aircraft in an air-traffic control system
 Elements of the computer-user environment
o Windows
o Menus
o Graphics objects(lines ,rectangles, circles)
o The mouse and the keyboard

 Programming constructs
o Customized arrays
o Stacks
o Linked lists
INTRANET CHATTING DOCUMENTATION

 Collection of data
o An inventory
o A personnel file
o A dictionary
A table of the latitudes and longitudes of world cities
 User defined data types
o Time
o Angles
o Complex numbers
o Points on the plane

 Components in a computer games

Ghosts in maze game
Positions in a board game (chess, checkers)
Animals in an ecological simulation
Opponents and friends in adventure games
The match between programming objects and real-world objects us the happy
result of combining data and functions: the resulting objects offer a revolution in
program designing, no such close match between programming constructs and the
items being modeled exists in a procedural language.

Classes

In OOP we say that objects are members of classes. What does this mean? Let’s
look at an analogy. Almost all computer languages have built-in data types. For
instance, a data type int, meaning integer is pre-defined in Java. You can declare as
many variables of type int as you need in your program:
Int day;
INTRANET CHATTING DOCUMENTATION

Int count;
Int divisor;
Int answer;

A class serves as a plan, or template. It specifies what data, and what functions will be
included in objects of that class. Defining the class doesn’t create any objects, just as the
mere existence of a type int doesn’t create any variables.
A class is thus a collection of similar objects. This fits our non technical understanding
of the word class, Prince, sting etc., are members of the class of rock musicians. There is
no person called rock musician but specific people with specific names are members of
this class if they possess certain characteristics.

Abstraction
An essential element of object-oriented programming is abstraction. Humans
manage complexity through abstraction. For example, people do not think of a car as a
set of tens of thousands of individual parts. They think of it as a well-defined object with
its own unique behavior. This abstraction allows people to use a car to drive to the
grocery store without being overwhelmed by the complexity of the parts that form the
car. They can ignore the details of how the engine, transmission, and braking systems
work. Instead they are free to utilize the object as a whole.
A powerful way to manage abstraction is through the use of hierarchical classifications.
This allows you to layer the semantics of complex systems, breaking them into more
manageable pieces. From the outside, the car is a single object. Once inside, you see that
the car consists of several subsystems: steering, brakes, sound system, seat belts, heating,
cellular phone, and so on. In turn, each of these subsystems is made up of more
specialized units. For instance, the sound system consists of a radio, a CD player, and/or
INTRANET CHATTING DOCUMENTATION

a tape player. The point is that you manage the complexity of the car (or any other
complex system) through the use of hierarchical abstractions.
Hierarchical abstractions of complex systems can also be applied to computer programs.
The data from a traditional process-oriented program can be transformed by abstraction
into its component objects. A sequence of process steps can become a collection of
messages between these objects. Thus, each of each object describes its own unique
behavior. You can treat these objects as concrete entities that respond to messages telling
them to do something. This is the essence of object-oriented programming.

Object-oriented concepts form the heart of Java just as they form the basis for
human understanding. It is important that you understand how these concepts translate
into programs. As you will see, object-oriented programming is a powerful and natural
paradigm for creating programs that survive the inevitable changes accompanying the life
cycle of any major software project, including conception, growth, and aging. For
example, once you have a well-defined objects and clean, reliable interfaces to those
objects, you can gracefully decommission or replace parts of an older system without
fear.

Encapsulation

Encapsulation is the mechanism that binds together code and the data it
manipulates, and keeps both safe from outside interference and misuse. One way to think
about encapsulation is as a protective wrapper that prevents the code and data from being
arbitrarily accessed by other code defined outside the wrapper. Access to the code and
data inside the wrapper is tightly controlled through a well-defined interface. To relate
this to the real world, consider the automatic transmission on an automobile. It
encapsulates hundreds of bits of information about your engine, such as how much you
are accelerating, the pitch of the surface you are on, and the position of the shift lever.
You, as the user, have only one method of affecting this complex encapsulation: by
INTRANET CHATTING DOCUMENTATION

moving the gear-shift lever. You can’t affect the transmission by using the turn signal or
windshield wipers, for example. Thus, the gear-shift lever is a well-defined (indeed,
unique) interface to the transmission. Further, what occurs inside the transmission does
not affect objects outside the transmission. For example, shifting gears does not turn on
the headlights! Because an automatic transmission is encapsulated, dozens of car
manufacturers can implement one in any way they please. However, from the

Driver’s point of view, they all work the same. This same idea can be applied to
programming. The power of encapsulated code is that everyone knows how to access it
and thus can use it regardless of the implementation details—and without fear of
unexpected side effects.
In Java the basis of encapsulation is the class. Although the class will be
examined in great detail later in this book, the following brief discussion will be helpful
now. A class defines the structure and behavior (data and code) that will be shared by a
set of objects. Each object of a given class contains the structure and behavior defined by
the class, as if it were stamped out by a mold in the shape of the class. For this reason,
objects are sometimes referred to as instances of a class. Thus, a class is a logical
construct; an object has physical reality.
When you create a class, you will specify the code and data that constitute that
class. Collectively, these elements are called members of the class. Specifically, the data
defined by the class are referred to as member variables or instance variables. The code
that operates on that data is referred to as member methods or just methods.
Since the purpose of a class is to encapsulate complexity, there are mechanisms
for hiding the complexity of the

Implementation inside the class. Each method or variable in a class may be marked
private or public. The public interface of a class represents everything that external users
of the class need to know, or may know. The private methods and data can only be
accessed by code that is a member of the class. Therefore, any other code that is not a
member of the class cannot access a private method or variable. Since the private
members of a class may only be accessed by other parts of your program through the
INTRANET CHATTING DOCUMENTATION

class’ public methods, you can ensure that no improper actions take place. Of course,
this means that the public interface should be carefully designed not to expose too much
of the inner workings of a class.

Inheritance
Inheritance is the process by which one object acquires the properties of another
object. This is important because it supports the concept of hierarchical classification.
As mentioned earlier, most knowledge is made manageable by hierarchical (that is, top-
down) classifications. For example, a Golden Retriever is part of the classification dog,
which in turn is part of the mammal class, which is under the larger class animal.
Without the use of hierarchies, each object would need to define all of its

Characteristics explicitly. However, by use of inheritance, an object need only define

those qualities that make it unique within its class. It can inherit its general attributes
from its parent. Thus, it is the inheritance mechanism that makes it possible for one
object to be a specific instance of a more general case.
Most people naturally view the world as made up of objects that are related to each other
in a hierarchical way, such as animals, mammals, and dogs. If you wanted to describe
animals in an abstract way, you would say they have some attributes, such as size,
intelligence, and type of skeletal system. Animals also have certain behavioral aspects;
they ear, breathe, and sleep. This description of attributes and behavior is the class
definition for animals. If you wanted to describe a more specific class of animals, such as
mammals, they would have more specific attributes, such as type of teeth, and mammary
glands. This is known as a subclass of animals, where animals are referred to as
mammals’ super class.
Since mammals are simply more precisely specified animals, they inherit all of the
attributes from animals. A deeply inherited subclass inherits all of the attributes from
each of its ancestors in the class hierarchy. Inheritance interacts with encapsulation as
well. If a given class encapsulates some attributes, then any subclass will have the same
attributes plus any that it adds as part of its specialization (see Figure 2-2). This is a key
concept which lets object-oriented programs grow in complexity linearly rather than
INTRANET CHATTING DOCUMENTATION

geometrically. A new subclass inherits all of the attributes of all of its ancestors. It does
not have unpredictable interactions with the majority of the rest of the code in the system.

Polymorphism

Polymorphism (from the Greek, meaning “many forms”) is a feature that allows
one interface to be used for a general class of actions. The specific action is determined
by the exact nature of the situation. Consider a stack (which is a last-in, first-out list).
You might have a program that requires three types of stack. One stack is used for
integer values, one for floating-point values, and one for characters. The algorithm that
implements each stack is the same, even though the data being stored differs. In a non-
object-oriented language, you would be required to create three difference sets of stack
routines, with each set using different names. However, because of polymorphism, in
Java you can specify a general set of stack routines that all share the same names.
More generally, the concept of polymorphism is often expressed by the phrase
“one interface, multiple methods.” This means that it is possible to design a generic
interface to a group of related activities. This helps reduce complexity by allowing the
same interface to be used to specify a general class of action. It is the compiler’s job to
select the specific action (that is, method) as it applies to each situation. You, the
programmer, do not need to make this selection manually. You need only remember and
utilize the general interface.
Extending the dog analogy, a dog’s sense of smell is polymorphic. If the dog
smells a cat, it will bark and run after it. If the dog smells its food, it will salivate and run
to its bowl. The same sense of smell is at work in both situations. The difference is what
is being smelled, that is, the type of data being operated upon by the dog’s nose! This
same general concept can be implemented in Java as it applies to methods within a Java
program.

Polymorphism, Encapsulation, and Inheritance Work Together

When properly applied, polymorphism, encapsulation, and inheritance combine to
produce a programming environment that supports the development of far more robust
INTRANET CHATTING DOCUMENTATION

and scaleable programs than does the process-oriented model. A well-designed hierarchy
of classes is the basis for reusing the code in which you have invested time and effort
developing and testing. Encapsulation allows you to migrate your implementations over

Time without breaking the code that depends on the public interface of your classes.
Polymorphism allows you to create clean, sensible, readable, and resilient code.
Of the two real-world examples, the automobile more completely illustrates the power of
object-oriented design. Dogs are fun to think about from an inheritance standpoint, but
cars are more like programs. All drivers rely on inheritance to drive different types
(subclasses) of vehicles. Whether the vehicle is a school bus, a Mercedes sedan, a
Porsche, or the family minivan, drivers can all more or less find and operate the steering
wheel, the brakes, and the accelerator. After a bit of gear grinding, most people can even
manage the difference between a stick shift and an automatic,
Because they fundamentally understand their common super class, the transmission.

People interface with encapsulated features on cars all the time. The brake and gas
pedals hide an incredible array of complexity with an interface so simple you can operate
them with your feet! The implementation of the engine, the style of brakes, and the size
of the tires have no effect on how you interface with the class definition of the pedals.
The final attribute, polymorphism, is clearly reflected in the ability of car manufacturers
to offer a wide array of options on basically the same vehicle. For example, you can get
an antilock braking system or traditional brakes, power or rack-and-pinion steering, 4-, or
6-, or 8-cylender engines. Either way, you will still press the break pedal to stop, turn the
steering wheel to change direction, and press the accelerator when you want to move.

PROJECT TESTING

COMPILING TEST
INTRANET CHATTING DOCUMENTATION

It was a good idea to do our stress testing early on, because it gave us time to fix
some of the unexpected deadlocks and stability problems that only occurred when
components were exposed to very high transaction volumes.

EXECUTION TEST

This program was successfully loaded and executed. Because of good

programming there were no execution errors. The complete performance of the project
“INTRANET CHATTING” was good.

OUTPUT TEST

The successful output screens are placed in the output screens section
above with brief explanation about each screen.

FUTURE IMPROVEMENT

1. This project can be enhanced by implementing different protocols and can be

made more useful for varied clients according to the requirements of the client, it
can also possible in future that each client in this globe has his own customized
“INTRANET CHATTING”.

2. It can be enhanced in the field of voice chatting. Using VoIP protocol

3. It can be enhanced in the field of Video Conferencing.

CONCLUSION
INTRANET CHATTING DOCUMENTATION

Even though this application has been developed with the users own Protocols,
this can be used in an Intranet based organization.

1. This system was developed so that people can exchange information as

well as converse with each other.
2. Through this system people can access chat rooms globally.
3. The system is interactive and friendly.
4. Entire system is fully automatic to the clients and satisfies the clients
request
5. Especially the system is more useful to the technical people when the need
for sending pictures, images it is solved through WHITE BOARD
UTILITY OF “INTRANET CHATTING”.