OOP fundamentals

OBJECTS AND CLASSES

- object
atributes - information that describe current state

- class is blueprint for objects

- class describes 2 behaivoir
type
what is it
properties, data, attributes
what describes it
width, height, color...
operations, methods, behavoir (similar like function)
what can it do
play open search...

- each object is istance of class

ABSTRACION
- focus on essentials
-
ENCAPSULARION
- who can see what
- object should show only necessities
- you should hide as much as possible
INHERITANCE
- extends from other class
- Superclass or parent class
subclass or child class

- multiple inheritance
when we extend from more than one clas
POLYMORPHISM
- overriding method of superclass

OBJECT ORIENTED DESIGN PROCES

steps
1. gather requirements
2. describe the app
3. Identify the main objects
4. Describve the Interactions
5. Create a Class Diagram

1. requirements
what application MUST DO

functional
features/capabilities
non-functional
help
legal
performance
support
security

FURPS/FURPS+
Functional requirements
Usability requirements
 Reliability requirements
Performance requirements
Supportability requirements
+
Design requirements, Implementation requirements, Interface
requirements (external hardware),
Physical requirements
USE CASES
- describing how user uses app in common language

- use cases
title - describe what we want to do
actor - who wants to do it or who is using app
scenarion - how it is done

e.g.
title - register new member, buy item
actor - user, administrator, member, ACMESystem
scenario - action description as steps
we write also extensions, if item is out of stock
and preconditions what should happend before this
- should take 1 or 2 days
- text
ACTORS
- does it have external system
- roles
visitor, member
- job titles
manager, payroll admin, ...
SCENARIOS
e.g.
- purchase items, create new document, balance accounts
not
- log in, write book, merge organizations

USER STORY
As a (type of user)
I want (goal)
so that (reason)

IDENTIFYING CLASESS
go trough user stories and fing nouns

behaviours
go to user stories and search for verbs

we should avoid global controling objects like e.g. SYSTEM OBJECT in which we
would store
general methods that are not conected

CLASS UML

!!!! if static it is written underline

---------------------------------------------
| Class name | Big first letter,
in singular
---------------------------------------------
| | - name:
String = "new product" - if we need to set default
| Atributes | - isActive:
Boolean - minus before name means
---------------------------------------------
that it should be private
| | + getName ()

| Operations | + setActive
(Boolean) plus means that should be public
| | -
getProductDetails (): String - expects to return string
---------------------------------------------

CONSTRUCTORS
same name as class
it sets default values
it can override several methods

STATIC VARIABLES AND METHODS

it is defines at class level, not when creating object instance

to get we call class e.g. SomeClass.staticValue = .93;

INHERITANCE
we should always ask question "is a" e.g. customer is a person
overriding is changing methods from superclasses

ABSTRACT CLASS
never instanced

INTERFACE
only contains methods and variables
not code
the class must implement this methods and classes

AGGREGATION AND COMPOSITION

aggregation - describes "has a" relationship e.g. car has a engine
composition - is aggregation, but it has ownership e.g. if car is deleted the
engine is deleted too

USEFULL ACRONYMS
dry - dont repeat yourself
yagni - you aint gonna need it
SOLID
single responsibility principle - object has one reason to exist
open closed principle - open for extension closed for modifications
liskov substitution principle - derived classes must be substituable
for their base clases
interface segregation principle - many specific intefaces are better
than one huge interface
dependency inversion principle - depend on abstractions, not on
concrete