Lec 03 - Lecture notes 3 PDF

Preview

Summary

COMP 303 W2018 ...

Description

COMP 303 Lecture 3 - Well Designed Objects 17.01.2018 Announcements: ● Readings ○ Hostmann: chapter 1, 2.1 - 2.5 ○ Tutorialspoint link java inheritance ○ Tutorialspoint link java polymorphism ○ Robillard: module 1 and 2? (to be assigned later) Lecture outline: ● Last class ○ We explored well written and optimal code ● Now our focus turns to ○ Well designed objects ○ Good class design principles ○ How encapsulation helps ○ Advantages of polymorphism About Well Designed Objects ● Object-oriented advantages ○ Encourages ■ Single purpose for each source file (.java) ■ Modularized thinking through the Class structure ○ Strong information hiding constructs ○ Strong inheritance constructs ■ Constructs: programming statements ○ Supports an API modality ■ Concept that everything is an API ● Direct OO support ○ Java, C++, Python ● Partial support ○ C through modular programming ○ Other languages through programmer discipline Single Purpose Provides control of the code and provides control over the complexity of understanding everything. ● Information control & information overload ○ A common artifact of programming ○ Results in: ■ Confusion ■ Error ■ Project delay ■ Hard to understand code ○ Single purpose fights the above things ●

There are many techniques used to control this issue

●

Single purpose: ○ Each structure you program must have a single purpose ■ No side effects, everything does one thing and only one thing.

Single Purpose ● Source Files ○ Java source file names look like this: filename.java ○ Each file name should be treated as: purpose.java ○ Where the filename describes the purpose ■ Additionally, we know that nowhere else in the application is that purpose being expressed, except in that file. ○ Programmer discipline enforces this designation ●

Classes ○ Java class names look like this: class name ○ Each class name should be treated as: class purpose ○ The class purpose and source file purpose agree ○ Programmer discipline enforces these purposes

Single Purpose ● Modularization ○ Dividing a problem statement into modules ■ Look at the problem statement and extract from it all of the single purposes/all of the modules ○ This is an OO technique that divides a problem statement into a set of related single purpose artifacts ○ Artifact in Java is the class, in C it is the module ● What are the modules in this example? ○ A teacher wants to track the course she is teaching and the students in each of her classes. She wants to track their grades, displaying class averages and other statistics. She also want to be able to identify students who are performing poorly across all her courses. ■ Modules: ● Course ○ Class average ○ List of courses? ● Student ○ List of students ■ Per course? ● Grades ○ List of grades ■ Per student? ● Teacher ○ Poor performance ○ We have to decide how these are going to be connected together ■

A student will appear in multiple courses, and then we have the grades for that one course????

When do we stop making modules? → goes back to the optimization question. What is the minimum number of objects I can have where

each object has a single purpose?

Information Hiding ● Single Purpose helps us control complexity and organize ● Information Hiding helps us ensure the code we write will be used correctly ○ How can we enforce proper usage of code? ● Code development problems (common ones we’ve experienced) ○ Global variable misused by teammate causes side-effects ○ You wrote the same code multiple times ■ Wrote it differently one time by mistake ■ Need to make bug fix in multiple locations ○ A function you wrote should not be called by your teammate, but it was ○ Your teammate used the same identifier ○ It is not clear how to use your module so teammate calls your functions randomly ●

Information Hiding in Java: ○ Class divided into Hidden and API ○ Hidden contains code/data other should not touch ○ API contains highly controlled purposeful code/data ○ API does data validation

-

Public API is what people can call. Private methods/variables cannot be called.

Information Hiding ● What should be hidden and what should be public, in this example: ○ A bank account contains the following properties (i.e. variables, constants, static stuff): ■ Account number → private ■ Owner ID number → private ■ Account type → public ■ Balance → public ○ A bank account contains the following responsibilities (i.e. activities it should do or conditions that should be true about your object):

■ ■ ■ ■ ■

●

Deposit operation Withdraw operation See the balance operation Make a transfer operation Tax balance if balance less than some limit

→ public → public → public → public → private

What API should be created in this example: (API are the public methods and variables you permit other programmers to access)

●

●

Class DynamicIntegerArray. Users of this class do not specify the size of the array, they simply use it without concern about the array size. What should be public? ○ public void add(int val, int index (≥ 0)); ○ public int get(int index(0 ≤ index ≤ current max)); What should be private? ○ private ArrayList a; ■

●

Note: doubly linked list uses a lot of memory

Using proper Java syntax, let us write the method signatures and variables.

Encapsulation Idea of linking both information hiding and single purpose. Encapsulation: single purpose and info hiding in a single concept.

● ●

Information hiding + single purpose Implication: ○ The class must contain all the properties and responsibilities associated with the purpose ○ No other location in the application can contain properties or responsibilities for that same purpose ○ If there is a class called Student, then there is no other Student in your application. ■

There might be references pointing to Student but there is no other implementation of it anywhere else.

●

Specifically: // not an exhaustive list, but things you should keep in mind (things that should be in your class) ○ Initialization ○ Instance information ○ Updating procedures ○ Access procedures (setting data and getting data) ○ Validation of all data

●

Example: ○ Assuming a checking account ○ Build a properly encapsulated class ■ Specifically: ● Initialization ● Instance information ● Updating procedures ● Access procedures (setting data and getting data) ● Validation of all data

// As a rule of thumb, data should always be private. If you make data public, you have no control over what the other // programmer can do.

class Checking { private balance; private Boolean isAmountValid(amount) { if(amount ≥ 0) true; else false; } public deposit(amount) { if(isAmountValid(amount)) … } public withdraw(amount) {

if(isAmountValid(amount)) …. } … } Note: If statements vs. Exceptions - Not all languages have exceptions, so if statements are still very useful to do. An exception is only used if you want the developer to call the function to let them know that something’s up. Review Question ● How does encapsulation help ○ Your teammate uses your code? ○ Protect your code from a developer? Problem For the following problem statement ● How would we encapsulate it? ● Describe the relationship between the modules? ● How might a team work together to built it? ○ A teacher wants to track the courses she is teaching and the students in each of her classes. She wants to track their grades, displaying class averages and other statistics. She also wants to be able to identify students who are performing poorly across all her courses. What will be the API for each of these? API - how the other developers are going to interact

●

●

●

Grades ○ Private ■ ■ ■ ■ ■ ○ API ■ ■ ■ ■ Student ○ Private ■ ■ ○ API ■ Class ○ Private ■ ■ ○ API ■

value name weight isValidValue() isValidWeight() setValue setWeight getValue getWeight

studentName studentID studentAverage

courseName courseID courseAverage

●

Teacher ○ Private ■ ○ API ■ poor()

Work Division among programmers How much knowledge do we need and how much can we assume works correctly?

●

Assume APIs work well/correctly ○ So that people do not need knowledge over other classes

Inheritance ● Encapsulation helps with single purpose and information hiding, which provides controls, and supports understanding and correct usage. ●

A major problem in software is the duplication of code. A programmer writes the same code in more than one place. This leads to issues like: writing the duplicated code incorrectly, and when making changes forgetting a duplicated code segment.

●

Inheritance helps in the duplication of code issue, and supports related code association.

●

Inheritance ○ The creation of a class using another class as a template ○ Remembering this association Syntax:

●

●

The INHERITED STUFF: ○ The child receives all the private and public stuff from the parent ○ But it cannot directly access the private stuff it inherits ■ It must use the inherited API to access the private stuff

Example: priv fn(int x) if(x < 10) return true public fn2(int y) ans = fn(y)

●

Example that demonstrates the usefulness of this technique:

○ ○ ○ ○

A bank has multiple account types: checking, savings, and investment. All accounts share: account #, owner id, balance, deposit, withdraw, and get the balance. Accounts differ: checking interest rate is 1%, savings 3%, investment 5%. Withdraw fee for savings of $1 per. Limit of 2 withdraw actions per year on investment account. How would we build this using inheritance? (signatures)

Polymorphism ● Given the Inheritance concept, we can use it to our advantage through Polymorphism ● Definition: ○ Using a single reference to point at related objects ○ In Java, a polymorphic reference can only be between parents and children ● Where: ○ Related objects are the parent and children of inherited classes

●

Example: class AAA { public int x; } class BBB extends AAA { public int y; } class CCC extends BBB { public int z; }

AAA P; p = new AAA(); p = new BBB(); p = new CCC();

// legal // legal // legal

What is inside class CCC? → x, y, z

●

What does p see and what does the object contain? ○ The object that p points to contains: x, y, and z; ○ The reference p is defined as an AAA class ■ p only knows the definition of x ■ It needs to be typecasted to see the other variables

// even though p is pointing to an object that has x, y, and z in it, p is defined as AAA. p’s definition (the class) does not contain y and z, so I cannot do p.y or p.z, because those are not contained inside the definition of AAA, even though they are physically there. So you have to typecast.

class AAA { public int x; } class BBB extends AAA { public int y; } class CCC extends BBB { public int z; } AAA p = new CCC(); To typecast p, you have to write something specifically like AAA p; p = new CCC();

We now have a p pointing to an object that has x,y,z However, that is true at runtime, but the compiler does not know this. The compiler knows that p is defined as an AAA. if we write p.y, the compiler says Syntax error, y does not belong to the definition of AAA, even though at runtime it is going to exist. We can correct this by creating another reference CCC x = (CCC) p;

// typecast

OR ((CCC)p).y;

Polymorphism ● Build an array of bank accounts and then iterate through them depositing $100 in each account. ●

Assume the following: ○ A bank has multiple account types: checking, savings, and investment. ○ All accounts share: account #, owner id, balance, deposit, withdraw, and get the balance ○ Accounts differ: checking interest rate is 1%, savings 3%, investment 5%. Withdraw fee for savings of $1 per. Limit of 2 withdraw actions per year on investment account.

Summary ● Advantages of basic OO ○ Single purpose ■ Complexity control and understanding ○ Encapsulation ■ Correct usage ■ Need to know basis ○ Polymorphism ■ Code sharing ■ Algorithm sharing since we can treat different objects in the same way ● Conclusion: ○ Faster development ○ Code that is easier to maintain and work collaboratively...