Defini3ons Programming Working out algorithms that solve - - PDF document

2013-­‑10-­‑10 ¡ 1 ¡

Lecture ¡OO ¡

Object ¡Orienta3on ¡ OOA, ¡OOD ¡ Class ¡introduc3on ¡

Defini3ons ¡

• Programming ¡

– Working ¡out ¡algorithms ¡that ¡solve ¡problems. ¡

• Coding ¡

– Implemen3ng ¡algorithms ¡in ¡some ¡language. ¡

• Language ¡

– Interface ¡to ¡processor ¡capabili3es. ¡ – Formal ¡syntax ¡for ¡describing ¡an ¡algorithm. ¡

• Interface ¡

– Set ¡of ¡features ¡a ¡thing ¡provide ¡to ¡use ¡or ¡manipulate ¡it. ¡

• Paradigm ¡

– A ¡certain ¡way ¡of ¡expressing ¡a ¡program. ¡

Paradigms ¡

• Func3onal ¡programming ¡

– Lisp ¡ – Scheme ¡ – Python ¡

• Impera3ve ¡programming ¡

– Ada ¡ – C ¡ – Python ¡

• Object ¡orienta3on ¡

– Ada ¡ – C++ ¡ – Java ¡

Func3onal ¡Programming ¡

• Programs ¡evalute ¡expressions. ¡
• The ¡program ¡have ¡no ¡global ¡state. ¡
• Func3ons ¡are ¡purely ¡mathema3cal ¡and ¡depend ¡

purely ¡on ¡input. ¡No ¡side ¡effects. ¡

• Func3ons ¡are ¡treated ¡as ¡any ¡data. ¡

– Can ¡be ¡defined ¡“on-­‑the-­‑fly” ¡inside ¡other ¡func3ons. ¡ – Can ¡be ¡passed ¡as ¡parameter. ¡ – Can ¡be ¡returned ¡from ¡func3ons. ¡

• Lambda ¡calculus ¡and ¡recursion ¡are ¡central. ¡

Impera3ve ¡programming ¡

• A ¡program ¡consist ¡of ¡statements, ¡func3ons ¡

and ¡procedures ¡that ¡manipulate ¡a ¡program ¡

• state. ¡
• Side ¡effects ¡are ¡somewhat ¡common. ¡
• Execu3on ¡is ¡sequen3al ¡rather ¡than ¡recursive. ¡
• Focus ¡on ¡how ¡the ¡program ¡should ¡do ¡

something ¡step ¡by ¡step. ¡

• Very ¡common ¡approach ¡to ¡programming. ¡

Object ¡Orienta3on ¡

• A ¡program ¡consist ¡of ¡loosely ¡coupled ¡objects ¡that ¡

cooperate ¡to ¡solve ¡a ¡task. ¡Objects ¡are ¡oXen ¡modeled ¡ to ¡represent ¡an ¡abstract ¡concept ¡or ¡real ¡world ¡thing. ¡

• Objects ¡provide ¡an ¡interface ¡that ¡allow ¡controlled ¡

interca3on ¡with ¡the ¡object. ¡

• Objects ¡hide ¡internal ¡representa3on ¡and ¡state ¡from ¡

the ¡rest ¡of ¡the ¡world. ¡

• Emphasis ¡on ¡abstrac3on, ¡encasula3on ¡and ¡inheritance ¡

to ¡be ¡able ¡to ¡easily ¡swap, ¡replace, ¡modify ¡or ¡reuse ¡

• bjects. ¡ ¡
• Objects ¡strive ¡for ¡low ¡coupling ¡and ¡high ¡cohesion. ¡
• Objects ¡oXen ¡use ¡impera3ve ¡programming ¡internally. ¡

2013-­‑10-­‑10 ¡ 2 ¡

Which ¡approach ¡to ¡use? ¡

• Use ¡an ¡approach ¡– ¡paradigm ¡– ¡that ¡suits ¡the ¡
• problem. ¡
• Find ¡a ¡language ¡that ¡allow ¡you ¡to ¡express ¡your ¡

thoughts ¡clearly. ¡

• Program ¡into ¡the ¡language: ¡do ¡not ¡limit ¡your ¡

thought ¡to ¡what ¡the ¡language ¡support, ¡ express ¡what ¡you ¡think ¡in ¡the ¡language. ¡

Terms ¡

• Cohesion ¡
• Coupling ¡
• Side ¡effect ¡
• Interface ¡
• Responsibility ¡
• Collaborators ¡
• Black ¡box ¡
• Associa3on ¡(know) ¡
• Composi3on ¡(have) ¡
• Aggrega3on ¡(part) ¡
• Inheritance ¡(is) ¡
• Abstrac3on ¡
• Encapsula3on ¡
• Design ¡paaern ¡
• Modularity ¡

¡

Language ¡features ¡

• Support ¡different ¡approaches, ¡strategies ¡
• Support ¡abstrac3on ¡on ¡many ¡levels ¡
• Support ¡readability ¡
• Support ¡correctness ¡
• Support ¡maintainability ¡
• Support ¡efficiency ¡

=> ¡Exist ¡to ¡make ¡liffe ¡easier ¡for ¡programmers. ¡

Language ¡is ¡not ¡paradigm ¡

• The ¡language ¡does ¡not ¡equal ¡a ¡certain ¡

paradigm ¡

• Most ¡lanuguages ¡support ¡several ¡paradigms ¡
• Object ¡orienta3on ¡!= ¡C++ ¡

– OO ¡is ¡a ¡paradigm, ¡not ¡a ¡language ¡ – OO ¡is ¡a ¡certain ¡way ¡of ¡tackling ¡a ¡problem ¡ – OO ¡is ¡a ¡way ¡of ¡organizing ¡programs ¡ – OO ¡is ¡a ¡work ¡process ¡used ¡to ¡design ¡a ¡solu3on ¡

OO ¡Analysis ¡1 ¡

• Find ¡objects ¡and ¡opera3ons ¡

– noun ¡== ¡object? ¡ – verb ¡== ¡opera3on? ¡ – brainstorm: ¡things, ¡concepts, ¡roles, ¡events, ¡devices, ¡ interac3ons ¡

• Classify ¡objects ¡

– responsibility ¡and ¡descrip3ve ¡name ¡ – collaborators ¡ – high ¡internal ¡cohesion ¡ – low ¡external ¡coupling ¡

OO ¡Analysis ¡2 ¡

• Describe ¡rela3ons ¡

– associa3on ¡ – aggrega3on ¡ – composi3on ¡ – inheritance ¡

• Group ¡classes ¡

– iden3fy ¡subsystems ¡

• Verify ¡with ¡use ¡cases ¡and ¡scenarios ¡
• Restart ¡and ¡improve ¡with ¡what ¡you ¡learned ¡

2013-­‑10-­‑10 ¡ 3 ¡

OO ¡Design ¡

• 1. System ¡specifica3on ¡

– parallelism, ¡db ¡connec3ons, ¡distributed ¡system? ¡

• 2. Infrastructure ¡specifica3on ¡

– storage, ¡user ¡interface, ¡protocols, ¡special ¡needs? ¡

• 3. Detailed ¡class ¡specifica3on ¡

– interface, ¡encasula3on, ¡methods, ¡members? ¡

• 4. Wrap ¡up ¡

– Is ¡the ¡complete ¡specifica3on ¡detaild ¡enough ¡for ¡ different ¡programmers ¡to ¡individually ¡come ¡up ¡with ¡ the ¡same ¡system? ¡

Comparision ¡to ¡a ¡company ¡

Think ¡of ¡a ¡large ¡company. ¡Any ¡large ¡company. ¡

• It ¡will ¡have ¡divisions ¡

– Sales ¡ ¡ ¡ ¡Marke3ng ¡ ¡ ¡Personell ¡ ¡ – R&D ¡ ¡ ¡ ¡ ¡Manufacture ¡ ¡ ¡Storage ¡ – Economy ¡ ¡ ¡Purchase ¡ ¡ ¡ ¡Espionage ¡

• Each ¡division ¡will ¡have ¡a ¡responsibility. ¡
• Divisions ¡will ¡cooperate ¡to ¡produce ¡value. ¡
• Why ¡is ¡a ¡large ¡company ¡organized ¡this ¡way? ¡
• Does ¡a ¡small ¡company ¡have ¡divisions? ¡Why? ¡

Company ¡organiza3on ¡vs. ¡ Program ¡object ¡orienta3on ¡

• A ¡company ¡is ¡split ¡in ¡divisions. ¡

– A ¡program ¡is ¡split ¡in ¡classes. ¡

• A ¡division ¡have ¡resources ¡(people, ¡money, ¡...) ¡

– A ¡class ¡have ¡member ¡variables. ¡

• A ¡division ¡provide ¡service ¡to ¡other ¡divisions. ¡

– A ¡class ¡provide ¡an ¡interface ¡to ¡other ¡classes. ¡

• A ¡divison ¡have ¡a ¡respondibility ¡and ¡will ¡protect ¡

it’s ¡resources ¡to ¡be ¡able ¡to ¡fulfil ¡it. ¡

– A ¡class ¡have ¡a ¡responsibility ¡and ¡will ¡protect ¡it’s ¡ member ¡variables ¡to ¡fulful ¡it. ¡

Example ¡case ¡

• A ¡bank ¡have ¡several ¡kinds ¡of ¡accounts; ¡savings ¡

account, ¡investment ¡account ¡and ¡checking ¡account. ¡ ¡

• An ¡account ¡have ¡at ¡least ¡one ¡owner. ¡ ¡
• Each ¡owner ¡can ¡have ¡several ¡accounts. ¡ ¡
• All ¡accounts ¡allow ¡for ¡deposits, ¡withdrawals ¡and ¡

balance ¡checking. ¡ ¡

• Each ¡account ¡type ¡have ¡interest ¡calculated ¡as ¡

described ¡on ¡upcoming ¡slide. ¡ ¡

• All ¡transac3onal ¡history ¡must ¡be ¡saved ¡with ¡the ¡

content ¡listed ¡on ¡upcoming ¡slide. ¡

Example ¡case ¡

• Interest ¡is ¡calculated ¡monthly ¡for ¡savings ¡

accounts, ¡yearly ¡for ¡investment ¡accounts ¡and ¡ daily ¡for ¡checking ¡accounts. ¡

• Interests ¡are ¡different ¡for ¡different ¡account. ¡
• A ¡transac3on ¡should ¡log ¡the ¡transferred ¡sum, ¡

the ¡sorce ¡account, ¡the ¡des3na3on ¡account ¡ and ¡the ¡3me ¡and ¡date. ¡

Class ¡

• Provide ¡lanuage ¡suport ¡for ¡object ¡orienta3on ¡paradigm ¡
• Have ¡a ¡single ¡purpose, ¡responsibility. ¡
• Consist ¡of ¡private ¡member ¡variables ¡and ¡public ¡

interface ¡methods. ¡

• Can ¡only ¡be ¡manipulated ¡through ¡a ¡well ¡defined ¡
• interface. ¡
• Constructors ¡and ¡interface ¡enables ¡the ¡programmer ¡to ¡

depend ¡on ¡always ¡known ¡and ¡correct ¡internal ¡state. ¡

• Operators, ¡constructors ¡and ¡destructors ¡allow ¡for ¡

easier ¡management. ¡

2013-­‑10-­‑10 ¡ 4 ¡

Class ¡syntax ¡

// names in italic are customizable class class-name { public: class-name(); // Constructor (Initiator) // member functions (methods in Java) return-type operation(parameter-list); private: // member variables data-type property; };

Class ¡example: ¡Account ¡

class Account { public: Account(); void deposit(int amount); void withdraw(int amount); private: string owner; int balance; };

Class ¡example: ¡Card ¡

class Card { public: Card(); void print(); int getValue(); string getSuit(); private: string suit; int value; };

Class ¡vs ¡Instance ¡

• A ¡class ¡only ¡describe ¡the ¡layout. ¡It ¡does ¡not ¡

create ¡any ¡data ¡in ¡memory. ¡It’s ¡a ¡descrip3on ¡of ¡a ¡ data-­‑type ¡with ¡opera3ons ¡“embedded”. ¡

• An ¡instance ¡is ¡a ¡variable ¡created ¡of ¡a ¡specific ¡

class, ¡an ¡object. ¡ // Create variable of type Account Account my_account; // Create a deck of 52 Card objects array<Card, 52> my_deck;

To ¡be ¡con3nued. ¡

This ¡page ¡is ¡not ¡leX ¡blank. ¡Inten3onally. ¡