OOP -interface and objects.pptx

How to Think in Terms of
Objects

Introduction
• When moving to an OO language, you must first go through the
investment of learning OO concepts and the corresponding thought
process.
• If this paradigm shift does not take place, one of two things will
happen:
• Either the project will not truly be OO in nature (for example, it will use C++
without using OO constructs) or the project will be a complete object-
disoriented mess.

Introduction
• Changing from FORTRAN to COBOL, or even to C, requires you to
learn a new language; however, making the move from COBOL to C++,
C# .NET, Visual Basic .NET, Objective-C, Swift, or Java requires you to
learn a new thought process.
• Three important things you can do to develop a good sense of the OO
thought process are
• Knowing the difference between the interface and implementation
• Thinking more abstractly
• Giving the user the minimal interface possible

KNOWING THE DIFFERENCE BETWEEN THE
INTERFACE AND THE IMPLEMENTATION

• Properly constructed classes are designed in two parts—the interface
and the implementation.

The Interface
• The services presented to an end user constitute the interface. In the
best case, only the services the end user needs are presented.
• As a general rule, the interface to a class should contain only what the
user needs to know.
• In the toaster example, the user needs to know only that the toaster must be
plugged into the interface (which in this case is the electrical outlet) and how
to operate the toaster itself.

The Implementation
• The implementation details are hidden from the user.
• One goal regarding the implementation should be kept in mind:
• A change to the implementation should not require a change to the user’s
code.
• This might seem a bit confusing, but this goal is at the heart of the design
issue.
• Good Interfaces - If the interface is designed properly, a change to the
implementation should not require a change to the user's code.

• Remember that the interface includes the syntax to call a method
and return a value.
• If this interface does not change, the user does not care whether the
implementation is changed.
• As long as the programmer can use the same syntax and retrieve the
same value, that’s all that matters.

• An Interface/Implementation Example
• Knowing your end users is always the most important issue when
doing any kind of design.
• You should do some analysis of the situation and conduct interviews
with end users, and then list the requirements for the project

The following are some requirements we might want to use for the
database reader:
• We must be able to open a connection to the database.
• We must be able to close the connection to the database.
• We must be able to position the cursor on the first record in the
database.
• We must be able to position the cursor on the last record in the
database.
• We must be able to find the number of records in the database.
• We must be able to determine whether there are more records in
the database (that
• is, if we are at the end).
• We must be able to position the cursor at a specific record by
supplying the key.
• We must be able to retrieve a record by supplying a key.
• We must be able to get the next record, based on the position of
the cursor.

For each of the requirements we listed, we need a corresponding method that
provides the functionality we want. Now you need to ask a few questions:
• To effectively use this class, do you, as a programmer, need to know anything
else about it?
• Do you need to know how the internal database code opens the database?
• Do you need to know how the internal database code physically positions
itself over a specific record?
• Do you need to know how the internal database code determines whether
any more records are left?
You don’t need to know any of this information. All you care about is that you get
the proper return values and that the operations are performed correctly. In fact,
the application programmer will most likely be at least one more abstract level
away from the implementation

Minimal interface
• The idea behind the minimal interface is to design an API that allows
the client to do everything they need to do, but boils down the
capabilities to the smallest reasonable set of methods that will do the
job

Object Persistence
• Object persistence refers to the concept of saving the state of an
object so that it can be restored and used at a later time.
• An object that does not persist basically dies when it goes out of
scope.
• For example, the state of an object can be saved in a database.
• Persistence is the ability of an object to survive the lifetime of the OS process
in which it resides

Standalone Application
• Even when creating a new OO application from scratch, it might not
be easy to avoid legacy data.
• Even a newly created OO application is most likely not a standalone
application and might need to exchange information stored in
relational databases (or any other data storage device, for that
matter).
• Legacy data refers to information that is stored in outdated or
obsolete systems, formats, or technologies

USING ABSTRACT THINKING WHEN
DESIGNING INTERFACES
• One of the main advantages of OO programming is that classes can be
reused.
• In general, reusable classes tend to have interfaces that are more
abstract than concrete.
• Concrete interfaces tend to be very specific, whereas abstract
interfaces are more general.
• However, simply stating that a highly abstract interface is more useful than a
highly concrete interface, although often true, is not always the case.

• The goal is to design abstract, highly reusable classes—and to do this
we will design highly abstract user interfaces.
• To illustrate the difference between an abstract and a concrete interface, let’s
create a taxi object.
• It is much more useful to have an interface such as “drive me to the airport”
than to have separate interfaces such as “turn right,” “turn left,” “start,”
“stop,” and so on, because, all the user wants to do is get to the airport.

PROVIDING THE ABSOLUTE MINIMAL USER
INTERFACE POSSIBLE
When designing a class, the general rule is to always provide the user with as
little knowledge of the inner workings of the class as possible. To accomplish
this, follow these simple rules:
• Give the users only what they absolutely need. In effect, this means the class has as
few interfaces as possible.
• It is better to have to add interfaces because users really need it than to give the
users more interfaces than they need.
• Public interfaces define what the users can access.
• It is vital to design classes from a user’s perspective and not from an information
systems viewpoint.
• Make sure when you are designing a class that you go over the requirements and the
design with the people who will actually use it—not just developers (this includes all
levels of testing).

Determining the Users
• The first impulse is to say the customers. This is only about half right.
Although the customers are certainly users, the cabbie must be able
to successfully provide the service to the customers.
• In other words, providing an interface that would, no doubt, please the
customer, such as “Take me to the airport for free,” is not going to go over
well with the cabbie.
• Thus, in reality, to build a realistic and usable interface, both the
customer and the cabbie must be considered users.
• In short, any object that sends a message to the taxi object is
considered a user (and yes, the users are objects)

OOP -interface and objects.pptx

Object Behavior
• Identifying the users is only a part of the exercise.
• After the users are identified, you must determine the behaviors of
the objects.
• From the viewpoint of all the users, begin identifying the purpose of
each object and what it must do to perform properly.
• Note that many of the initial choices will not survive the final cut of
the public interface.

Environmental Constraints
• The environment often imposes limitations on what an object can do
• Environmental constraints are almost always a factor. Computer
hardware might limit software functionality.
• For example, a system might not be connected to a network, or a company
might use a specific type of printer.
• In the taxi example, the cab cannot drive on a road if a bridge is out, even if it
provides a quicker way to the airport.

Identifying the Implementation
• After the public interfaces are chosen, you need to identify the
implementation.
• After the class is designed and all the methods required to operate
the class properly are in place, the specifics of how to get the class to
work are considered.
• Technically, anything that is not a public interface can be considered
the implementation.
• This means that the user will never see any of the methods that are
considered part of the implementation, including the method’s signature
(which includes the name of the method and the parameter list), as well as
the actual code inside the method.

Identifying the Implementation
• The implementation is totally hidden from the user. The code within public
methods is a part of the implementation because the user cannot see it.
• The user should see only the calling structure of an interface—not the code inside it.
• This means that, theoretically, anything that is considered the
implementation might change without affecting how the user interfaces
with the class.
• This assumes that the implementation is providing the answers the user
expects.
• Whereas the interface represents how the user sees the object, the
implementation is really the nuts and bolts of the object.
• The implementation contains the code that represents that state of an
object.

OOP -interface and objects.pptx

More Related Content

Similar to OOP -interface and objects.pptx (20)

More from EdFeranil (15)

Recently uploaded (20)

OOP -interface and objects.pptx