Object-Oriented Programming [Java]

Three Fundamental Features of OOP

Encapsulation

Inheritance

Polymorphism

Encapsulation

An object-oriented technique in which the internal details of an object are "hidden" in order to simplify their use and reuse.

Inheritance

A relationship between two classes in which one class ( the subclass) inherits all of the properties and capabilities of another ( the superclass)

Polymorphism

Declaring a variable to have one type while it refers to an object of a subclass of that type.

Object-Oriented Analysis

A means of determining what aspects of a given problem can be viewed as objects in an eventual object-oriented design.

Object-Oriented Design

A software design method that models the characteristics of abstract or real objects using classes and objects.

Object-Oriented Programming

A programming technique that features objects, classes, encapsulation, interfaces, polymorphism, and inheritance.

Cohesion

Degree to which responsibilities of a given component are a meaningful unit

Cohesion vs Coupling

Greater cohesion reflects better design. Less coupling reflects better design.

Coupling

Degree to which one component must directly access the data of another component.

Roles

Sets of Responsibilities

Roles vs. Objects

They are the same when a given role is always played by the same object type.

Software Components

Reuse of code (e.g. Visual Basic, JavaBean)

Frameworks

Reuse of "plug-in" code (e.g. Java Swing)

Design Paterns

Reuse of Design

Agile Software Development

A philosophy of software development that embraces flexibility and agility. The design "evolves".

3 Means of Object-Object Access

- Parameter Passing

- Object declared in method

- Object is a member of another object through composition [subtype]

Is-a Relationship

Describes an inheritance relationship between two classes

Has-a Relationship

The relationship demonstrated by a class that contains another class.

Uses-a Relationship

Implemented-In-Terms-Of Relationship

Static Members

Known as "class variables", because there is only one unique value for all the objects of that same class.

This

Special reference that refers to the object in which it is used.

Super

Special reference that refers to the superclass of the object in which it is used.

Liskov Substitution Principle

Determine whether a subclass is a subtype

Protected Access

No outside classes can use this data field, except descendant classes. Defeats the purpose of OOP.

Upcasting

Type cast to the type of an ancestor class. Is usually done automatically.

Downcasting

Type cast to the type of a descendant class; may cause runtime errors.

Interfaces

A purely abstract class. Can only contain constants and method signatures.

Marker Interface

An interface with no methods or fields

Use Case Diagram

UML diagram that captures all actors (an individual or another system) and use cases involved with a system or product. Used to model user requirements.

Use Case

Functional requirement of a system as a sequence of steps.

Generalization (Base Use Case)

A way to indicate that a given use case is a variation of, or specific version of, another use case. [Closed Unfilled Arrow]

Extension

A way to indicate limited ways a use case can vary (e.g. Delete Message, current or all?) <>

Includes

A way to indicate steps that occur in more than one scenario. (e.g. Validate Pin)<>

Associated Scenario

The detailed steps of a use case.

Class Diagram

A visual representation of the relationships between classes.

Composition

Represents real-world whole-part relationships, e.g., an engine is a part of a car

Aggregation

Represents a class as a collection or container of other classes.

Dependency

Used to show that some UML element or a set of elements requires, needs or depends on other model elements for specification or implementation

Multiplicity

Minimum and maximum number of occurrences of one object for a single occurrence of related object

Role Name

Signifies the role that a participating entity type plays in each relationship instance. In some cases the same entity type participates more than once in a relationship type in different roles.

Sequence Diagram

A type of diagram that shows objects participating in interactions and the messages exchanged between them.

Singleton Pattern

This pattern ensures you have at most one instance of a class in your application

Iterator Pattern

The design pattern that provides a way to access the elements of an aggregate object sequentially without exposing the underlying representation.

Adapter Pattern

The design pattern that translates one interface for a class into a compatible interface.

Facade Pattern

Simplifies the interface of a group of classes. Hides the complexity of one or more classes behind a clean, well-lit facade. Makes an interface simple. Provides a unified interface to a set of interfaces in a subsystem.

Object-Oriented Analysis Stage

Determines the requirements of a system

Focus on what needs to be done (not how)

Carried out by a team of analysts

End product is a conceptual model

5 Design Principles

1) Major subsystems should be loosely coupled, allowing independence

2) Many-to-many relationships require an additional class

3) Avoid exposing details of business logic implementation to the user interface

4) Avoid exporting mutable objects

5) Avoid importing objects of an internal type in the system

Law of Demeter

"Single Dot Rule"

Long lists of method calls are attributed to bad design