Object Oriented Programming

Front 1

Encapsulation

Back 1

The grouping of related ideas into one unit which can be referred to by a single name

Front 2

Encapsulation saves:

Back 2

Saves computer memory by using a repeating pattern of instructions and saves human memory through conceptual chunking.

Front 3

OO Encapsulation

Back 3

Groups operations and attributes into an object so that state is only changeable through the interface

Front 4

Information/implemenation Hiding

Back 4

Encapsulation's use for restricting visibility of implementation details

Front 5

Benefits of Info/Implementation Hiding

Back 5

Localizes design decisions (avoiding ripple effect) and decouples content from internal operation/representation

Front 6

Attribute

Back 6

"Externally visible property, may correspond to an instance var, but isn't required to"

Front 7

Instance variable

Back 7

implementation specific detail

Front 8

State Retention

Back 8

"objects have a memory of their state, the set of values the object currently holds"

Front 9

Object Identity

Back 9

Each object can be used separately through the reference of a handle or pointer (handles are unique)

Front 10

Messages 3 parts

Back 10

"1) Target's handle 2)Operation for target to do 3) Parameters, arguments, supplementary info"

Front 11

Operation:

Back 11

"What you want performed, an abstraction"

Front 12

Method:

Back 12

A specific implementation of an operation

Front 13

4 Roles of objects in a message

Back 13

"Sender, Target, Pointed to by a var in target, pointed to by a var in argument"

Front 14

3 Types of Messages

Back 14

"Interrogative, Informative, Imperative"

Front 15

Interrogative Message

Back 15

"Request that an object tell something about its current state, ""present"" oriented"

Front 16

Informative Message

Back 16

"Send info about something that has happened so a target CAN update itself, ""past"" oriented"

Front 17

Imperative Message

Back 17

Ask for the target to do something to itself or something in the environment

Front 18

Classes are

Back 18

"A ""stencil"" for how to make a type of object. Each one has the same structure and behavior as the class."

Front 19

Inheritance

Back 19

"IS-A relationship between class Y and class X, if Y is-a X, then Y has the attributes and operations of X"

Front 20

Advantage of inheritance

Back 20

You can first build a class for the general case and then add more specialized classes for special cases

Front 21

Code Inheritance

Back 21

the machinery used

Front 22

Type Inheritance

Back 22

What you must be able to do

Front 23

Procedural Polymorphism: Overloading

Back 23

"""static"" - operation name is the same but the list of parameters changes"

Front 24

Procedural Polymorphism: Overridding

Back 24

"""dynamic"" - pass the call down the inheritance hierarchy until you hit the most specific one"

Front 25

Type Polymorphism 3 Abilities

Back 25

1) to use any implementation of a single type 2) an object can be of two or more unrelated types 3) to use a specialized object when a more general ancestor is called for

Front 26

Dynamic Binding

Back 26

Runtime execution of the most specific version of a method when an operation is invoked. Prereq only for dynamic polymorphism

Front 27

Genericity

Back 27

"Using an abstract class to perform on different types of data, so that you don't have to rewrite the same code for int that you already have for double, usually acts upon container classes aka collections"

Front 28

Quote: user centered analysis -J. Rumbaugh

Back 28

"""The process of capturing requirements from the user's point of view"" or what's the user need to do? Okay, what do we need to put in to make that happen?"

Front 29

Quote: Scenario -M. Fowler

Back 29

"""Sequence of steps describing an interaction between a user and a system."" or flow of events that says what a user does with a system"

Front 30

Quote: Use-Case -unknown

Back 30

"""A set of scenarios tied together by a common user goal."" or buncha things the user wants to do"

Front 31

Actor

Back 31

"Some thing outside the boundaries of the system that acts upon the system (a role, not a specific person), NOT controlled by the system"

Front 32

Things actors do

Back 32

"use the system, install the system, start & stop the system, maintain the system, get and provide info for the system"

Front 33

Parts of a use case prose

Back 33

"title, id, actors, preconditions, flow of events, post conditions"

Front 34

UML Class Diagrams - CSI

Back 34

"Conceptual - models the domain, not the software itself. Specification - models the public interface. Implementation - gives the details of the implementation (code)"

Front 35

Operations - CSI

Back 35

Conceptual - gives the prose responsibility. Specification - gives what others know of how it works. Implementation - the complete code of the operation.

Front 36

Attributes - CSI

Back 36

Conceptual - the class has a property. Specification - the class can tell others about its property. Implementation Class X has property Y and the method getY()

Front 37

Associations - CSI

Back 37

Conceptual - these guys know each other. Specification - These guys are related in their workings. Implementation - These guys have pointers or references to each other.

Front 38

Attributes vs. Associations - CSI

Back 38

Conceptual - attributes are usually single values while associations may not be. Specification - attributes only imply one direction of navigation. Implementation - attributes imply a value while associations imply a reference

Front 39

Aggregation Properties

Back 39

Formed of homogenous constituents which may belong to multiple aggregates. Aggregate can exist without its components but may not be useful.

Front 40

Composition Properties

Back 40

"Formed of heterogeneous components which may only belong to a single composite. Composite has a parallel lifetime with its components. ""Heart is a component, hand is a constituent."""

Front 41

"Association, Aggregation, Composition"

Back 41

"""knows-a"", ""has-a"" replaceable/optional, ""has -a"" necessary/irreplaceable"

Front 42

Classification Relationship

Back 42

One is an instance of the other. Blue is a color.

Front 43

Generalization Relationship

Back 43

One is a specified form of the other. Pens are writing instruments.

Front 44

5 principles of object oriented programming

Back 44

1. Objects

2. Abstraction
Composition

3. Polymorphism
Overloading/overriding

4. Inheritance
Subclassing

5. Encapsulation
Information hiding

6. Decoupling

7. Modularity

Front 45

Abstraction

Back 45

Primarily defined by composition. A car is made up of a body, tires, and an engine.

Front 46

Polymorphism

Back 46

One name different meanings. Breaks down into overloading and overriding.

Front 47

Overloading

Back 47

Reusing the same name of a method with different parameters.

Front 48

Overriding

Back 48

Reusing the same method name in subclasses so that the subclass can perform a specific activity with that method.

Front 49

Decoupling

Back 49

Preventing interdependencies between objects.

Front 50

Inheritance

Back 50

Subclassing. Reusing all the abilities of parent classes in the child classes.

Front 51

Encapsulation

Back 51

Information hiding. Restricting access to the internal structure of an object.

Front 52

Modularity

Back 52

Allowing the reuse of code by creating modules that perform specific functions.