2013-‑10-‑10 ¡ Defini3ons ¡ • Programming ¡ – Working ¡out ¡algorithms ¡that ¡solve ¡problems. ¡ • Coding ¡ Lecture ¡OO ¡ – Implemen3ng ¡algorithms ¡in ¡some ¡language. ¡ • Language ¡ – Interface ¡to ¡processor ¡capabili3es. ¡ – Formal ¡syntax ¡for ¡describing ¡an ¡algorithm. ¡ Object ¡Orienta3on ¡ • Interface ¡ OOA, ¡OOD ¡ – Set ¡of ¡features ¡a ¡thing ¡provide ¡to ¡use ¡or ¡manipulate ¡it. ¡ • Paradigm ¡ Class ¡introduc3on ¡ – A ¡certain ¡way ¡of ¡expressing ¡a ¡program. ¡ Paradigms ¡ Func3onal ¡Programming ¡ • Func3onal ¡programming ¡ • Programs ¡evalute ¡expressions. ¡ – Lisp ¡ • The ¡program ¡have ¡no ¡global ¡state. ¡ – Scheme ¡ – Python ¡ • Func3ons ¡are ¡purely ¡mathema3cal ¡and ¡depend ¡ • Impera3ve ¡programming ¡ purely ¡on ¡input. ¡No ¡side ¡effects. ¡ – Ada ¡ • Func3ons ¡are ¡treated ¡as ¡any ¡data. ¡ – C ¡ – Python ¡ – Can ¡be ¡defined ¡“on-‑the-‑fly” ¡inside ¡other ¡func3ons. ¡ • Object ¡orienta3on ¡ – Can ¡be ¡passed ¡as ¡parameter. ¡ – Ada ¡ – Can ¡be ¡returned ¡from ¡func3ons. ¡ – C++ ¡ • Lambda ¡calculus ¡and ¡recursion ¡are ¡central. ¡ – Java ¡ Impera3ve ¡programming ¡ Object ¡Orienta3on ¡ • A ¡program ¡consist ¡of ¡loosely ¡coupled ¡objects ¡that ¡ • A ¡program ¡consist ¡of ¡statements, ¡func3ons ¡ cooperate ¡to ¡solve ¡a ¡task. ¡Objects ¡are ¡oXen ¡modeled ¡ and ¡procedures ¡that ¡manipulate ¡a ¡program ¡ to ¡represent ¡an ¡abstract ¡concept ¡or ¡real ¡world ¡thing. ¡ state. ¡ • Objects ¡provide ¡an ¡interface ¡that ¡allow ¡controlled ¡ interca3on ¡with ¡the ¡object. ¡ • Side ¡effects ¡are ¡somewhat ¡common. ¡ • Objects ¡hide ¡internal ¡representa3on ¡and ¡state ¡from ¡ the ¡rest ¡of ¡the ¡world. ¡ • Execu3on ¡is ¡sequen3al ¡rather ¡than ¡recursive. ¡ • Emphasis ¡on ¡abstrac3on, ¡encasula3on ¡and ¡inheritance ¡ • Focus ¡on ¡how ¡the ¡program ¡should ¡do ¡ to ¡be ¡able ¡to ¡easily ¡swap, ¡replace, ¡modify ¡or ¡reuse ¡ objects. ¡ ¡ something ¡step ¡by ¡step. ¡ • Objects ¡strive ¡for ¡low ¡coupling ¡and ¡high ¡cohesion. ¡ • Very ¡common ¡approach ¡to ¡programming. ¡ • Objects ¡oXen ¡use ¡impera3ve ¡programming ¡internally. ¡ 1 ¡
2013-‑10-‑10 ¡ Which ¡approach ¡to ¡use? ¡ Terms ¡ • Associa3on ¡(know) ¡ • Use ¡an ¡approach ¡– ¡paradigm ¡– ¡that ¡suits ¡the ¡ • Cohesion ¡ problem. ¡ • Composi3on ¡(have) ¡ • Coupling ¡ • Aggrega3on ¡(part) ¡ • Find ¡a ¡language ¡that ¡allow ¡you ¡to ¡express ¡your ¡ • Side ¡effect ¡ thoughts ¡clearly. ¡ • Inheritance ¡(is) ¡ • Interface ¡ • Abstrac3on ¡ • Program ¡into ¡the ¡language: ¡do ¡not ¡limit ¡your ¡ • Responsibility ¡ thought ¡to ¡what ¡the ¡language ¡support, ¡ • Encapsula3on ¡ • Collaborators ¡ express ¡what ¡you ¡think ¡in ¡the ¡language. ¡ • Design ¡paaern ¡ • Black ¡box ¡ • Modularity ¡ ¡ Language ¡features ¡ Language ¡is ¡not ¡paradigm ¡ • Support ¡different ¡approaches, ¡strategies ¡ • The ¡language ¡does ¡not ¡equal ¡a ¡certain ¡ paradigm ¡ • Support ¡abstrac3on ¡on ¡many ¡levels ¡ • Most ¡lanuguages ¡support ¡several ¡paradigms ¡ • Support ¡readability ¡ • Object ¡orienta3on ¡ != ¡C++ ¡ • Support ¡correctness ¡ – OO ¡is ¡a ¡paradigm, ¡not ¡a ¡language ¡ • Support ¡maintainability ¡ – OO ¡is ¡a ¡certain ¡way ¡of ¡tackling ¡a ¡problem ¡ • Support ¡efficiency ¡ – OO ¡is ¡a ¡way ¡of ¡organizing ¡programs ¡ => ¡Exist ¡to ¡make ¡liffe ¡easier ¡for ¡programmers. ¡ – OO ¡is ¡a ¡work ¡process ¡used ¡to ¡design ¡a ¡solu3on ¡ OO ¡Analysis ¡1 ¡ OO ¡Analysis ¡2 ¡ • Describe ¡rela3ons ¡ • Find ¡objects ¡and ¡opera3ons ¡ – noun ¡== ¡object? ¡ – associa3on ¡ – verb ¡== ¡opera3on? ¡ – aggrega3on ¡ – brainstorm: ¡things, ¡concepts, ¡roles, ¡events, ¡devices, ¡ – composi3on ¡ interac3ons ¡ – inheritance ¡ • Classify ¡objects ¡ • Group ¡classes ¡ – responsibility ¡and ¡descrip3ve ¡name ¡ – iden3fy ¡subsystems ¡ – collaborators ¡ • Verify ¡with ¡use ¡cases ¡and ¡scenarios ¡ – high ¡internal ¡cohesion ¡ – low ¡external ¡coupling ¡ • Restart ¡and ¡improve ¡with ¡what ¡you ¡learned ¡ 2 ¡
2013-‑10-‑10 ¡ OO ¡Design ¡ Comparision ¡to ¡a ¡company ¡ 1. System ¡specifica3on ¡ Think ¡of ¡a ¡large ¡company. ¡Any ¡large ¡company. ¡ – parallelism, ¡db ¡connec3ons, ¡distributed ¡system? ¡ • It ¡will ¡have ¡divisions ¡ 2. Infrastructure ¡specifica3on ¡ – Sales ¡ ¡ ¡ ¡Marke3ng ¡ ¡ ¡Personell ¡ ¡ – storage, ¡user ¡interface, ¡protocols, ¡special ¡needs? ¡ – R&D ¡ ¡ ¡ ¡ ¡Manufacture ¡ ¡ ¡Storage ¡ 3. Detailed ¡class ¡specifica3on ¡ – Economy ¡ ¡ ¡Purchase ¡ ¡ ¡ ¡Espionage ¡ • Each ¡division ¡will ¡have ¡a ¡responsibility. ¡ – interface, ¡encasula3on, ¡methods, ¡members? ¡ 4. Wrap ¡up ¡ • Divisions ¡will ¡cooperate ¡to ¡produce ¡value. ¡ – Is ¡the ¡complete ¡specifica3on ¡detaild ¡enough ¡for ¡ • Why ¡is ¡a ¡large ¡company ¡organized ¡this ¡way? ¡ different ¡programmers ¡to ¡individually ¡come ¡up ¡with ¡ • Does ¡a ¡small ¡company ¡have ¡divisions? ¡Why? ¡ the ¡same ¡system? ¡ Company ¡organiza3on ¡vs. ¡ Example ¡case ¡ Program ¡object ¡orienta3on ¡ • A ¡company ¡is ¡split ¡in ¡divisions. ¡ • A ¡bank ¡have ¡several ¡kinds ¡of ¡accounts; ¡savings ¡ account, ¡investment ¡account ¡and ¡checking ¡account. ¡ ¡ – A ¡program ¡is ¡split ¡in ¡classes. ¡ • An ¡account ¡have ¡at ¡least ¡one ¡owner. ¡ ¡ • A ¡division ¡have ¡resources ¡(people, ¡money, ¡...) ¡ • Each ¡owner ¡can ¡have ¡several ¡accounts. ¡ ¡ – A ¡class ¡have ¡member ¡variables. ¡ • All ¡accounts ¡allow ¡for ¡deposits, ¡withdrawals ¡and ¡ • A ¡division ¡provide ¡service ¡to ¡other ¡divisions. ¡ balance ¡checking. ¡ ¡ – A ¡class ¡provide ¡an ¡interface ¡to ¡other ¡classes. ¡ • Each ¡account ¡type ¡have ¡interest ¡calculated ¡as ¡ • A ¡divison ¡have ¡a ¡respondibility ¡and ¡will ¡protect ¡ described ¡on ¡upcoming ¡slide. ¡ ¡ it’s ¡resources ¡to ¡be ¡able ¡to ¡fulfil ¡it. ¡ • All ¡transac3onal ¡history ¡must ¡be ¡saved ¡with ¡the ¡ – A ¡class ¡have ¡a ¡responsibility ¡and ¡will ¡protect ¡it’s ¡ content ¡listed ¡on ¡upcoming ¡slide. ¡ member ¡variables ¡to ¡fulful ¡it. ¡ Example ¡case ¡ Class ¡ • Interest ¡is ¡calculated ¡monthly ¡for ¡savings ¡ • Provide ¡lanuage ¡suport ¡for ¡object ¡orienta3on ¡paradigm ¡ • Have ¡a ¡single ¡purpose, ¡responsibility. ¡ accounts, ¡yearly ¡for ¡investment ¡accounts ¡and ¡ • Consist ¡of ¡private ¡member ¡variables ¡and ¡public ¡ daily ¡for ¡checking ¡accounts. ¡ interface ¡methods. ¡ • Interests ¡are ¡different ¡for ¡different ¡account. ¡ • Can ¡only ¡be ¡manipulated ¡through ¡a ¡well ¡defined ¡ interface. ¡ • A ¡transac3on ¡should ¡log ¡the ¡transferred ¡sum, ¡ • Constructors ¡and ¡interface ¡enables ¡the ¡programmer ¡to ¡ the ¡sorce ¡account, ¡the ¡des3na3on ¡account ¡ depend ¡on ¡always ¡known ¡and ¡correct ¡internal ¡state. ¡ and ¡the ¡3me ¡and ¡date. ¡ • Operators, ¡constructors ¡and ¡destructors ¡allow ¡for ¡ easier ¡management. ¡ 3 ¡
Recommend
More recommend