Download OOAD Module-1

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
The Story of Object-Oriented Programming
In object-oriented programming, your program will be split into several small, manageable, reusable
programs. Each small program has it’s own identity, data, logic and how it’s going to communicate with the
rest of the other small programs.
Objects
When you think about Objects, you should think about the real world situations. Object-Orientation was
intended to be closer to the real world, hence, make it easier and more realistic.
What are the Objects?, Well, Objects could be:
 Something visible for you, like the car, phone, apple, duck, lamp.
 Something that you can’t touch, like the Time, Event, Account.
Objects
Each Objects has it’s own attributes, and behavior. Objects are separate from one another. They
have their own existence, their own identity that is independent of other objects.
What do we mean by attributes?
It’s the characteristics or the properties of the Object, like for example, in case of a duck,
it’s weight & color. They describe the current state of an object. The state of one object is independent
of another. Maybe you will have a duck that’s white and another one is black.
What do I mean by behavior?
Behavior is things that the Object can do, in case of duck, It can fly. Another example, in case of Account,
we can deposit or/and withdraw from any account. Again, Each account is totally independent on the
other. We may deposit from an account and withdraw from another account.
Class
What is a class?
Well, a class is the place where you can identify the behaviors and properties of an Object. So, the
properties and behavior of an Object, will be defined inside a class.
Bank Account Class
So, a class is a blueprint, it provides the definition for an
Object, the definition says what are the properties and the
behaviors of the Object. Let’s take an example, When you
build a house, you start making the blueprint, in other words
you start defining it’s properties and behaviors, and then,
you use this blueprint to build different houses, or more
formally, different objects from the same blueprint.
So, Objects from the same blueprint, or more formally the same class, share the same properties and
behaviors. However, even they share the same Class, each Object instantiated from this Class is
independent on the other.
Abstraction
Abstraction means you start focusing on the common properties and behaviors of some Objects, and we
automatically will discard what’s unimportant or irrelevant.
What came into your mind when I say “Car”?
If we say Car, we didn’t explicitly say if the car is BMW or Audi, if it’s red or black, if it’s small or
large. Your mental model of a car might have a color and size, but, it’s unlikely to have a smell or a
flavor because those things are irrelevant to the idea of a car.
Cars
So, we abstracted the idea of what a car means. Abstraction is the heart of Object-Oriented Programming,
because it’s what we are doing when we make a class.
In case of Cars, maybe you will have different brands like, BMW, Audi, Bugatti, Chevrolet, Citroen and
so on. But, we don’t create a class for each brand, instead, we will abstract; focus on the common
essential qualities of the idea, and we will write one class called Car. And As a way to discard what’s
unimportant, we should focus on how the class should look like for this application under these
circumstances at this time. In Other words, you care only about the information that you need in this
situation.
Later on, maybe you will be having a specific car brand that has a property or a behavior that’s not
common between other car brands, and it’s specific to it’s type. In this case, you will have to do of
what’s called “Inheritance”, and we will get into it later.
Encapsulation
Instead of having a procedural, long program, we start to decompose our program into small reusable,
manageable chunks. Encapsulation implies the idea of breaking down our program into small miniprograms; classes, where each class has a set of related attributes and behaviors.
Encapsulation also implies the idea of hiding the content
of a Class, unless it’s necessary to expose. We need to
restrict the access to our class as much as we can, so that
we can change the properties and the behaviors only from
inside the class.
Encapsulation
But, How can we do that?
Start building our blueprints, or classes and define their properties and behaviors. Then, restrict access
to the inner works of that class by hiding the attributes and methods so that they’re only accessible from
inside the class scope.
What’s the difference between Encapsulation and Abstraction?
Encapsulation is a strategy used as part of abstraction. When we encapsulate, we abstract away the
implementation.
Abstraction is a more generic term, and it’s often not possible without hiding the object’s class content
by encapsulation; if a class exposes its internal content, thus, it cannot be abstracted.
Why should we hide attributes and methods of an object?
So other parts of the application won’t change the current object attributes.
If we have a bank account object, we can use the deposit and withdraw methods from other parts of the
application, and they can change the balance, but the attribute can’t be directly changed from outside the
class.
Another example, If you have a lamp object, and assigned it’s property called “turnedOff” to true. If
there are some other class that have access to this property, they can change it accidentally to false!.
And, If we’ve restricted direct access to a piece of data, we only have to worry about this one class, and
we don’t have to worry about breaking the other parts of the application that might depends on this piece
of data. So, we can more safely change the way the object works.
If you have a bank account object, and you want to change how the balance is stored. Then, the other
parts of the application don’t have to worry about this change, Why? Because the balance attribute of
the account object is already hidden; can’t be accessed directly.
Inheritance
Abstraction is, instead of creating different classes, we can instead create one generic class that has the
common, and essential properties and behavior of those classes, while Inheritance is inheriting these
common properties and behaviors, so that we can create a new class, but instead of writing it from
scratch, we can base it on an existing class.
Inheritance
A Person class with a
attributes;
name
and
address and phone number.
Now, you need to create
another
one
called
Customer. It has the same
attributes as Person, but it
also
has additional attributes
and methods.
So, we are going to inherit
from the Person class. And
the Customer class will
automatically has everything that the Person class has, all its attributes, all its behaviors, without us
having to write any code. In addition, If we make a change in the Person class, it will automatically
cascade down and affect the inheriting classes.
Now, we can add specific properties and behaviors that’s not shared across the inheriting classes in their
specific classes.
Overriding In Inheritance:- Overriding the Super class methods is not a good case practice when the
Super class is a Concrete class. That’s why developers tend to use Interfaces instead.
Inheritance defines a relationship
So, a Customer IS-A Person, and an Employee IS-A Person, and so on. The term that’s most commonly
used for this relationship is, Person class is the Super class, while the customer class is called
the Sub class. Or, We can also hear this described as the Parent class and the Child class.
Multiple Inheritance
In C++, & Python allow you to inherit from more than one Super Class; Multiple Inheritance. But, it
can get confusing as it’s much more common to inherit from one Super class. In Java & C#, You only
inherit from one Super Class.
Types of Inheritance





Single Inheritance − A subclass derives from a single super-class.
Multiple Inheritance − A subclass derives from more than one super-classes.
Multilevel Inheritance − A subclass derives from a super-class which in turn is derived from
another class and so on.
Hierarchical Inheritance − A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
Hybrid Inheritance − A combination of multiple and multilevel inheritance so as to form a
lattice structure.
Polymorphism
Polymorphism; is the state where an object can take the shape of many different forms, and lets us do
the right thing at the right time.
Polymorphism
If you have Animal class, and inheriting classes; Dog, Cat, & Duck. Each of the inheriting classes
override the speak method (as each animal has a different voice).
Now, we can call the speak method on any animal object, without knowing exactly what class the animal
object was instantiated from, and it will do the correct behavior.
It’s worth mentioning that the speak method in the Animal class will be triggered unless it’s overridden.
Polymorphism is the flexibility, that triggers the correct behavior.
Genericity
Genericity is one of the most powerful means for obtaining flexibility in programming with statically
typed programming languages. Genericity constructs take on very different forms, the choice of which
has a considerable impact on expressiveness, modularity, static checkability and efficiency properties
of programs.
Generics allow the programmer to use the same method for Integer arrays, Double arrays, and even
String arrays. Another advantage of using generics is that Individual typecasting isn't required.
The programmer defines the initial type and then lets the code do its job. It allows us to implement
non-generic algorithms.
Generic Programs




One of the goals of Object Oriented Programming is genericity.
Ideally, generic programs can be written once, compiled once and used for different data types.
C++ achieves genericity two ways:
1. Using virtual functions and derived classes to achieve polymorphism.
2. Using templates to mimic polymorphism.
Template classes must be re-compiled for each data type. Some do not consider this OOP.
Coupling vs Cohesion
Coupling and cohesion are two important concepts in the Object Oriented design and hence we will
briefly discuss it here.
Coupling is the degree to which one class knows about another class. If the knowledge is only through
exposed interfaces (data hiding), it is called loosely coupled. If the knowledge is more like accessing
data members directly, it is called tightly coupled. We should try to make our code as loosely coupled
as possible. Even though you make some change in a class adhering strictly to the class's API, tight
coupling can make other classes that use this class not working properly after the change.
The term cohesion is used to indicate the degree to which a class has a single, well-focused purpose.
The more focused a class is, the higher its cohesiveness, which is a good thing. The key benefit of high
cohesion is that such classes are typically much easier to maintain than classes with low cohesion.
Another benefit of high cohesion is that classes with a well-focused purpose tend to be more reusable
than other classes.
In summary, loose coupling and high cohesion are desirable, whereas tight coupling and less
cohesion can lead you to problems in the long run.
Advantages of object oriented software development
Some of the advantages of object oriented software development are:






Less maintenance cost mostly because it is modular.
Better code reusability due to features such as inheritance and hence faster development.
Improved code reliability and flexibility
Easy to understand due to real world modelling.
Better abstraction at object level.
Reduced complexity during the transitions from one development phase to another.
What is Object-Oriented Analysis and Design and How to Use it
OOAD is a technical method of analyzing and designing an application based on that system’s object
models (the logical components of the system that interact with one another).
Origins of Object-Oriented Analysis and Design
During the software development life cycle, development is typically broken up into stages, which are
loose, abstract concepts used to separate the activities taking place within each phase of development.
Often,
these
stages
might
include requirements,
planning, design, coding/development, testing, deployment, maintenance, and so forth.
In the case of stringent development methodologies, such as the waterfall method, these stages are
sequential and intended to be completely separate from one another. Thus, when creating an application
using the waterfall method, it’s unlikely that discoveries made during the testing or deployment phases
can impact the decisions already made during the planning or design phases. These limitations, along
with the strict step-by-step staging process of waterfall-esque models, led to the rise of iterative models
like object-oriented analysis and design.
While OOAD practices have been around for a number of decades, the core ideas and techniques were
largely cemented in the collective mind of the development community in the 1990s. An assortment of
practitioners and authorities in the industry, working together and on solo endeavors, began to publish
a number of books, articles, and techniques that all relied heavily on OOAD concepts. Some of these
publications and methodologies are still well-known and in use today, including the Unified Modeling
Language and the Rational Unified Process.
What is Object-Oriented Analysis?
To define object-oriented analysis, we must first define what we mean by an object. The definition of
an object, according to most dictionaries, is “a tangible, material thing.” Drilling down a bit more to
the realm of computer science, an object can be most anything in a programmatic sense, from a variable
or data model to a function, class, or method. Moving even deeper into the realm of object-oriented
programming, an object is an instance of a thing that typically represents a real world object and has
all the same types of characteristics (properties), behaviors (methods), and states (data). When
discussing OOAD concepts,
an object most
closely
resembles
the object-oriented
programming version of an object, in that it is a representation of a real world object with behaviors,
characteristics, and states.
With that out of the way, we can define object-oriented analysis (OOA). In short, OOA is an iterative
stage of analysis, which takes place during the software development life cycle, that aims to model
the functional requirements of the software while remaining completely independent of any
potential implementation requirements. To accomplish this task via OOAD practices, an objectoriented analysis will focus everything through the lens of objects. This forces OOA to
combine all behaviors, characteristics, and states together into one analysis process, rather than
splitting them up into separate stages, as many other methodologies would do.
To accomplish this goal, a typical OOA phase consists of five stages:





Find and define the objects.
Organize the objects.
Describe how the objects interact with one another.
Define the external behavior of the objects.
Define the internal behavior of the objects.
For example, a typical implementation of OOA is to create an object model for an application.
The object model might describe the names, relationships, behaviors, and characteristics of each object
in the system. With this information established for each object, the design process that follows is much
simpler.
What is Object-Oriented Design?
The process of object-oriented design is really just an extension of the object-oriented analysis process
that preceded it, except with a critical caveat: the consideration and implementation of constraints. For
example, with an analyzed object in hand, such as an object model, we must now consider how that
object would actually be designed and implemented, which will often require the application of
constraints, such as software or hardware platforms, time and budgetary limitations, performance
requirements, developer aptitude, and so forth.
Put another way, the OOD process takes the theoretical concepts and ideas planned out during
the OOA stage, and tries to find a way to design and tangibly implement them, usually via code using
whatever language and platforms the development team has settled upon. If OOA is the what,
then OOD is the how.
Advantages of Object-Oriented Analysis and Design
Encourages Encapsulation: Since everything within OOAD revolves around the concept
of objects (specifically, the object-oriented variety), one of the biggest advantages of OOAD is that it
encourages planning and development of systems that are truly independent of one another. Just like
a class written using object-oriented techniques, all the systems and objects produced during
an OOAD development life cycle can be mixed and matched as necessary, since they will ideally be
built as completely self-contained entities.
Easy to Understand: Since OOAD principles are fundamentally based on real world objects, it’s quite
easy for everyone on the team to quickly understand what an object name means or how a particular
behavior, well, behaves. This makes the overall development life cycle a much smoother process,
particularly if your team needs to frequently interact with customers or other non-technical users about
the objects and components in the system. In such cases, most people still understand how system
components and modelled objects work when they’re based on real world objects and ideas.
Disadvantages of Object-Oriented Analysis and Design


Ill-Suited to Procedural Applications: Given the object-oriented nature of OOAD, it is quite difficult
(although not impossible) to practice OOAD techniques within a procedural programming language,
or often to apply the techniques to non-object business logic. Whereas procedural applications are often
logically bound by concepts of scope and modularity, object-oriented applications, of course,
emphasize objects that simulate the real world, making OOAD methods ill-suited for procedural
languages and applications.
Too Complex for Simple Applications: While arguably not a disadvantage that is applicable to all
projects, it’s certainly the case that OOAD practices are generally not ideal for simpler projects. Many
developers have their own personal hard and fast rules to help when deciding whether a project should
be procedural or object-oriented, but in most cases, the more basic the needs of the application, the
more likely a less-structured, procedural approach is the best fit. As always, we must always use our
own best judgment.
Phases in Object-Oriented Software Development
The major phases of software development using object–oriented methodology are object-oriented
analysis, object-oriented design, and object-oriented implementation.
Object–Oriented Analysis
In this stage, the problem is formulated, user requirements are identified, and then a model is built
based upon real–world objects. The analysis produces models on how the desired system should
function and how it must be developed. The models do not include any implementation details so that
it can be understood and examined by any non–technical application expert.
Object–Oriented Design
Object-oriented design includes two main stages, namely, system design and object design.
System Design
In this stage, the complete architecture of the desired system is designed. The system is conceived as
a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects, grouped
into classes. System design is done according to both the system analysis model and the proposed
system architecture. Here, the emphasis is on the objects comprising the system rather than the
processes in the system.
Object Design
In this phase, a design model is developed based on both the models developed in the system analysis
phase and the architecture designed in the system design phase. All the classes required are identified.
The designer decides whether −

new classes are to be created from scratch,

any existing classes can be used in their original form, or

new classes should be inherited from the existing classes.
The associations between the identified classes are established and the hierarchies of classes are
identified. Besides, the developer designs the internal details of the classes and their associations, i.e.,
the data structure for each attribute and the algorithms for the operations.
Object–Oriented Implementation and Testing
In this stage, the design model developed in the object design is translated into code in an appropriate
programming language or software tool. The databases are created and the specific hardware
requirements are ascertained. Once the code is in shape, it is tested using specialized techniques to
identify and remove the errors in the code.
Why do we model?
Before constructing anything, a designer first build a model. The main reasons for constructing models
include:
• To test a physical entity before actually building it.
• To set the stage for communication between customers and developers.
• For visualization i.e. for finding alternative representations.
• For reduction of complexity in order to understand it.
Related documents