This document discusses the key concepts of object-oriented programming including abstraction, encapsulation, classes and objects. It defines abstraction as focusing on the essential characteristics of an object and hiding unnecessary details. Encapsulation hides the implementation of an object within a class. A class defines both the data and operations of an object through its interface and implementation. Objects are instantiations of classes that come to life through constructors and die through destructors, ensuring proper initialization and resource cleanup.
This presentation describes different modeling techniques. It has three basic purposes:
Give you an overview of some of the different types of models
Give you a set of tools to decide how to create a (good) model for a problem
Give you an overview of some of the different modeling techniques
This presentation is developed for MDD 2010 course at ITU, Denmark
This presentation describes different modeling techniques. It has three basic purposes:
Give you an overview of some of the different types of models
Give you a set of tools to decide how to create a (good) model for a problem
Give you an overview of some of the different modeling techniques
This presentation is developed for MDD 2010 course at ITU, Denmark
Montage Bamboo terrarium de la marque Reptiles-PlanetRomain Julian
Vous venez d'acheter notre nouveau terrarium en bambou ou vous envisagez de le faire ?
Voici une vidéo "montage" du Bamboo terrarium de notre marque Reptiles-Planet.
On espère que cette vidéo vous sera utile. On vous invite aussi à donner votre avis par vos commentaires et vos partages.
Pour plus d'infos, visitez notre page : http://reptiles-planet.com/index.php/...
Notre produit est disponible à la vente sur : http://savannah.fr/
Montage Bamboo terrarium de la marque Reptiles-PlanetRomain Julian
Vous venez d'acheter notre nouveau terrarium en bambou ou vous envisagez de le faire ?
Voici une vidéo "montage" du Bamboo terrarium de notre marque Reptiles-Planet.
On espère que cette vidéo vous sera utile. On vous invite aussi à donner votre avis par vos commentaires et vos partages.
Pour plus d'infos, visitez notre page : http://reptiles-planet.com/index.php/...
Notre produit est disponible à la vente sur : http://savannah.fr/
Object Oriented Programming using C++ Part IIAjit Nayak
Object Oriented Concepts
Class & Objects in C++
Constructor & Destructors in C++
Operator Overloading in C++
Friend function in C++
Data Conversion in C++
This pointer in C++
Friend class in C++
Nested Class in C++
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
3. Abstraction
Dahl, Dijkstra, and Hoare suggest that “abstraction
arises from a recognition of similarities
between certain objects, situations, or processes in
the real world, and the decision to concentrate
upon these similarities and to ignore for the time
being the differences” [42].
4. Abstraction
An abstraction denotes the essential
characteristics of an object that distinguish it from
all other kinds of objects and thus provide crisply
defined conceptual boundaries, relative to the
perspective of the viewer.
5.
6. Abstraction: Perspective of User
Parent
Child Name
Class
Roll No
Mobile No
Employee
Name
Id No
Mobile No
Tax Payer
Name
Pan No
Annual Return
Bank Customer
Name
Pan No
Acct No
Acct Type
Loyalty Program
Member
Name
Card No
Points
7. Abstraction
An abstraction focuses on the outside view of an
object and so serves to separate an object’s
essential behavior from its implementation.
Deciding on the right set of abstractions for a given
domain is the central problem in object-oriented
design.
8. Abstraction
Abstraction or separation of behavior / implementation
can be achieved by applying:
Principle of least commitment: the interface of an
object provides its essential behavior, and nothing
more
Principle of least astonishment: an abstraction
captures the entire behavior of some object, no more
and no less, and offers no surprises or side effects that
go beyond the scope of the abstraction
9. Abstract Data Type (ADT)
An ADT is a mathematical model of a data
structure that specifies the type of data stored, the
operations supported on them and the type of
parameters of the operations.
Specifies what each operation does, but not how it
does it
10. Encapsulation
Encapsulation hides the details of the
implementation of an object
Typically, the structure of an object is hidden, as well as
the implementation of its methods.
Encapsulation is the process of compartmentalizing the
elements of an abstraction that constitute its structure and
behavior;
Encapsulation serves to separate the contractual interface of
an abstraction and its implementation.
12. Encapsulation
Encapsulation is most often achieved through information
hiding (not just data hiding), which is the process of hiding
all the secrets of an object that do not contribute to its
essential characteristics
14. Data Hiding
"... the purpose of hiding is to make inaccessible
certain details that should not affect other parts of a
system.“ [Ross et al, 1975]
15. Data Hiding
Data must be hidden/ private
Read access through read() functions
Write access through write() functions
For each data,
Allow both read and write
Allow read only
Allow write only
No access
16. Encapsulation / Data Hiding
void modifyX (int newVal) {
if (newVal > 100) or (newVal < 0) {
return error;
}
else
X = newVal
}
void readX() {
return X;
}
17. Abstraction & Encapsulation
Complementary concepts:
The abstraction of an object should precede the decisions about its
implementation.
Once an implementation is selected, it should be treated as a secret
of the abstraction and hidden from most clients i.e. encapsulated
“For abstraction to work, implementations must be encapsulated
Abstraction:
focuses on the observable behavior of an object
Encapsulation:
focuses on the implementation that gives rise to this behavior
18. Anatomy of a Class
PRIVATE PUBLIC
Data
Private
Functions
Read/ Write
Functions
Constructors/
Destructors
ADT Functions
Pop(), Insert ()
Public Interface
Class
• Realization of an ADT
• State /fields /data
members
• Behavior /methods
/member functions
• Public Interface: signatures
(names, return types, argument
types) of a class’s public member
functions, only part of the class
that can be accessed by a user of
the class
19. Class
• It defines the data being stored and the operations
supported by the objects that are instances of the
class
• Every class must have two parts:
• an interface – what? – Abstraction
• an implementation – how? – Encapsulation
20. Abstraction Encapsulation
External Interface
The interface of a class
captures only its outside
view, encompassing
abstraction of the
behavior common to all
instances of the class.
Internal Implementation
The implementation of a
class comprises the
representation of the
abstraction as well as the
mechanisms that achieve
the desired behavior.
Class, Abstraction & Encapsulation
21. Abstraction Encapsulation
Exposes Generic /
Generalized Features
The interface of a class is
the one place where we
assert all of the
assumptions that a client
may make about any
instances of the class
Hides implementation
details
The implementation
encapsulates details
about which no client
may make assumptions.
Class, Abstraction & Encapsulation
In C++ a Class embodies both abstraction and encapsulation
Please read: http://www.tonymarston.co.uk/php-mysql/abstraction.txt
22. Point Product
class Point
{
public:
Point (double xval, double yval);
void move(double dx, double dy);
double get_x() const;
double get_y() const;
private:
double x;
double y;
};
class Product
{
public:
Product();
void read();
bool is_better_than(Product b) const;
void print() const;
private:
string name;
double price;
int score;
};
Examples
23. Objects
Object
Instantiation of a class
Initialization of Objects
Constructors
Called automatically every time an object is created, ensures proper initialization
Overcome the problem of improper initialization in procedural languages
Resource De-allocation
Destructors
Ensures de-allocation of resources before the object dies, or goes out of scope
Overcome memory leaks etc. in procedural languages
24. Objects
Life-cycle of an Object
Born Healthy
Properly initialized by use of constructors
Lives Safely
Using read/write functions, ensure data integrity
Dies Cleanly
Using destructors
By major, we mean that a model without any one of these elements is not object oriented.
By minor, we mean that each of these elements is a useful, but not essential, part of the object model.
Abstraction is one of the fundamental ways that we as humans cope with complexity.
Abelson and Sussman call this behavior/implementation division an abstraction barrier [45] achieved by applying the principle of least commitment, through which the interface of an object provides its essential behavior, and nothing more [46].
We like to use an additional principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction.
Square (Coordinates, Color)
Bundling together of data and functions that operate on data
Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. For example, consider again the structure of a plant.
To understand how photosynthesis works at a high level of abstraction, we can ignore details such as the responsibilities of plant roots or the chemistry of
cell walls.
Similarly, in designing a database application, it is standard practice to write programs so that they don’t care about the physical representation of data
but depend only on a schema that denotes the data’s logical view [52].
In both of these cases, objects at one level of abstraction are shielded from implementation details at lower levels of abstraction.
Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity.
there are degrees of information hiding. For
example, at the programming language level, C++ provides for public,
private, and protected members ([Ellis and Stroustrup, 1990]), and Ada
has both private and limited private types ([ARM, 1983]).
Confusion can occur when people fail to distinguish between
the
hiding of information, and a technique (e.g., abstraction)
that is used to help identify which information is to be
hidden.
Programming languages have long supported encapsulation. For example,
subprograms (e.g., procedures, functions, and subroutines), arrays,
and
record structures are common examples of encapsulation mechanisms
supported by most programming languages. Newer programming languages
support larger encapsulation mechanisms, e.g., "classes" in Simula
([Birtwistle et al. 1973]), Smalltalk ([Goldberg and Robson, 1983]),
and C++, "modules" in Modula ([Wirth, 1983]), and "packages" in Ada.
Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity.
If encapsulation was "the same thing as information hiding," then one
might make the argument that "everything that was encapsulated was
Also hidden." This is obviously not true. For example, even though
information may be encapsulated within record structures and arrays,
this information is usually not hidden (unless hidden via some other
mechanism).
It is indeed true that encapsulation mechanisms such as classes allow
some information to be hidden. However, these same encapsulation
mechanisms also allow some information to be visible. Some even allow
varying degrees of visibility, e.g., C++'s public, protected, and
private members.
Simply stated, the abstraction of an object should precede the decisions about its implementation. Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients.
Abstraction and encapsulation are complementary concepts:
Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. “No part of a complex system should depend on the internal details of any other part” [50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort” [51].
“For abstraction to work, implementations must be encapsulated” [53].
Principle of encapsulation – data private; read/write functions –
Implementation function, reasons for which the class exists
In OOP we say that objects are members of classes. What does this mean?
A class is thus a description of a number of similar objects. This fits our non-technical understanding of the word class.
An object is often called an “instance” of a class.
In C++ every object must belong to a class. A class is a data type, just like int or double. However, classes are programmer-defined, whereas int and double are defined by the designers of the C++ language.
“For abstraction to work, implementations must be encapsulated” [53].
In practice, this means that each class must have two parts: an interface and an implementation.
The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class.
The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior.
The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions.
If the class’s implementation changes, the class’s clients should not be required to change.
• Interfaces define and standardize the ways in which things such as people and systems interact.
• A class’s public interface (p. 85) describes the public member functions that are made available
to the class’s clients. The interface describes what services (p. 85) clients can use and how to request
those services, but does not specify how the class carries out the services.
• Separating interface from implementation (p. 84) makes programs easier to modify. Changes in the
class’s implementation do not affect the client as long as the class’s interface remains unchanged.
• A function prototype (p. 85) contains a function’s name, its return type and the number, types
and order of the parameters the function expects to receive.
• Once a class is defined and its member functions are declared (via function prototypes), the
member functions should be defined in a separate source-code file.
• For each member function defined outside of its corresponding class definition, the function
name must be preceded by the class name and the binary scope resolution operator (::, p. 86).
* Each class should provide a constructor (p. 77) to initialize an object of the class when the object
is created. A constructor must be defined with the same name as the class.
• A difference between constructors and functions is that constructors cannot return values, so they
cannot specify a return type (not even void). Normally, constructors are declared public.
• C++ requires a constructor call at the time each object is created, which helps ensure that every
object is initialized before it’s used in a program.
• A constructor with no parameters is a default constructor (p. 77). If you do not provide a constructor,
the compiler provides a default constructor. You can also define a default constructor
explicitly. If you define a constructor for a class, C++ will not create a default constructor.
