ACO 101 – Intro to Computer Science

 28object-oriented_programming% object-oriented_programming%29

 Encapsulate complexity  divide program into classes  each class has its own responsibilities and data  class has only one purpose  class has simple interface  hide implementation details

 Encapsulate change  each class presents only a simple public interface  class hides implementation details as a result...  we can localize the effect of change

 Reuse code  classes are reusable  polymorphism lets us interchange parts  inheritance lets us build new classes that reuse code from old classes.

 Better abstraction  objects make good models for things in the real world (problem domain)  let us think about the problem instead of the code  simplify the problem so we can think about problem without too many details

An OO program consists of objects that interact with each other. (this picture is a UML Sequence Diagram)

The tenets of:

 Inheritance  Encapsulation  Polymorphism

 The child gets it all.  If an object inherits from another object – it can do EVERYTHING that object can do in addition to doing all the stuff it can do.

 The word Polymorphism is derived from two Greek words, namely Poly and Morphos. Poly indicates many and Morphos indicates forms.  Therefore, it is the existence of the same thing in different forms.  Polymorphism is behavior that varies depending on the class in which the behavior is invoked.  In other words, two or more classes can react differently to the same message.

 This is a duck object  This is a common example in learning OOP so I am using it here.  What are its attributes?  Color  Eyes  Bill  Appendages  Surface  Size  What are its behaviors?  Sound  Movement

 One quacks, one talks and one squeaks – their sound behavior will all be different  One has feathers, one has clothes and one is rubber – their surface attribute will all be different  They will all inherit from the duck object and polymorphism allows them to be different from each other and still share attributes and behaviors of the base duck object.

 Another name for this is: information hiding  Hides the way something works away from the user who can do all its operations without seeing how it does it.  A way to understand this is to think of a car, we now how to get from destination A to B without knowing how the engine works under the hood or seeing it work.

 Class Libraries  You can buy some ▪  With Java and C# there is a library that ships with them ▪ C# Framework location = C:\Windows\Microsoft.NET\Framework\v ▪ Java API location = The Java SE Runtime Environment ▪ contains the Java virtual machine, runtime class libraries, and Java application launcher ▪ For more info read this: C:\Program Files\Java\jdk1.6.0_21\jre\README.txt ▪  Game Engines  They slap a GUI on the front end of it so that game designers can build games without having to code all the physics, animation and complicated math etc.

 A class is a recipe for an object  And just like any recipe you can make as many of the object as you want to…  [Pass out recipe here]  But I wouldn’t want to eat a recipe – would you ?

During design, you need to identify the classes. Classes are used to model things:  Tangible things in the design: nouns, such as  purse, mailbox, bank account, keypad, message  Users  Student, Administrator, Bank Manager  Agents ("-er" or "-or" words)  Scanner, file reader, sentence reader, CSVreader  agents perform some operation (sentence reader)  Events and Transactions  Button click, ATM Withdrawal, Register for Course are all events  transactions are uses for interactions between classes, usually contain info that doesn't "belong" in a thing class

 Verbs in specification often are responsibilities deposit withdraw confirm

Best Design: A class should have only one purpose (but may have several related behaviors)  Purse: responsible for managing coins in a purse  More than one CLOSELY related responsibilities OK  Bank: purpose is to manage bank accounts and assets  A class should have well defined responsibilities  ATM: communicate with the client and execute transactions (but not verify them... that's the Bank's job)

 What behavior (methods) must a class provide to perform its responsibilities? A Purse is responsible for managing coins in a purse. Behavior a purse should have: 1. insert coins 2. withdraw coins 3. get balance 4. is it full? purse has a limited capacity

 Behavior should be related (coherent)  don't put unrelated responsibilities into the same class  avoid assigning too many behaviors to a class A Purse is not responsible for:  printing the balance  asking the user what he wants  computing the price of stuff

Customer getAccounts() Account getBalance() getOwner() deposit( ) withdraw() doInteterest() handle responsibilities directly related to customer. handle responsibilities directly related to bank accounts. Good Design Customer countAccounts( ) getBalance( k ) deposit( k, amt ) withdraw( k, amt ) doInteterest( k ) handle responsibilities directly related to bank accounts. Bad Design

 A class is a blueprint or definition for a kind of object.  A class defines the attributes and behavior of objects. Cat birthday color sex sleep( ) eat( Food ) play( ) chase( Object ) attributes are characteristics of objects. In Java: attributes, "fields" behavior is what the object can do. In Java: methods

 Objects are instances of a class.  [Pass out baked goods here ]  In Java, to create a new object use "new", e.g. Cat somecat = new Cat( );  create the object in memory  invoke the constructor of Cat class to initialize values. Object creation can use values, too: Cat kitten = new Cat( Color.BLACK, "male",... );

Objects have:  state - the current condition of an object  behavior - the actions or messages an object can accept  identity - every object is distinguishable, even if two objects have the same state

 The definition of a  HondaCivic consists of:  specifications  design documents  blue prints  list of parts  list of qualified suppliers  instructions for assembly  inspection procedure and check lists  operating instructions  maintenance manual and procedures

 But, the Honda Civic owner doesn't need to know all these details. He needs to know about a Honda Civic's properties (public attributes) and behavior.  For example (simplified): HondaCivic bodyStyle bodyColor trimColor engineSize doors transmissionType turnLeft( ) turnRight( ) brake( ) accelerate( ) isEngineOn( ) fuelAmount( ) properties (attributes) behavior

 You go to the Honda dealer and say... I want a Honda Civic Yes, sir. This way, please...

the dealer offers you the class for a HondaCivic... Here you are! All the documents and blue prints for a Honda Civic.... that will be 1,000,000,000 Baht, please. Construction and operation of a Honda Civic: complete documents.

but you can't drive blue prints and documents That's not exactly what I had in mind. I want a car I can drive... I see... you want an instance of Honda Civic -- a Honda Civic object.

Silver, 4 door, automatic transmission, tinted windows,... yourcar : HondaCivic bodyStyle = sedan bodyColor = silver trimColor = silver engineSize = 1600cc doors = 4 transmissionType = auto turnLeft( ) turnRight( ) brake( ) accelerate( ) isEngineOn( ) fuelAmount( ) yourcar = new HondaCivic("silver", 4door, automatic,... ); attributes behavior

HondaCivic Class = Defines the properties and behavior for all instances (objects) of this class. Object = Specific realization of the class

 Two Honda Civic cars can be distinguished even if they exactly the same features and same state (brand new) !=

 Reading  HomeWorkReading03-TheDifference.pdf  HomeWorkReading04-ClassStructure.pdf  OnComplexity.pdf  OnAbstraction.pdf