OOP Class Notes for 9/5/12
Java Introduction
- Java Code Pipeline
- Java code progression: .java -> javac -> .class -> java -> (program execution)
- .java is the source files in java
- .class is the java byte code, not compatible with most processors
- Does not use registers, stack based per invocation
- Compiled in a "just in time" manner into standard binary by Java VM
- Java code progression: .java -> javac -> .class -> java -> (program execution)
- Q: how does java VM know the stuff in referenced code in a .class file?(dependencies) A: It goes back to the .java files to figure out if it needs stuff
- Q: how does it link/load libraries? A: Dynamically(only loads class files if they are referenced from other classes)
- Q: How does it know where to file those class files? A: From the class path(directories containing class files to look for referenced classes in)
- Q: What is a jar(Java ARchive) file? A: Functionally a zip file
Code Example
- A four dimensional point class, with constructors, getters, and some other things
- Code from lecture: Point.java
- Code Discussion:
- What data do we need?
- Four coordinates
- How should we represent them?
- Four doubles
- Generic objects(more flexible, but adds complexity and more vague, time consuming, bad idea)
- How should we represent them?
- Four coordinates
- Need to consider what type to make the coordinates, use your head
- We choose to make them an array of doubles(more ease of reference, but more memory overhead)
- What should they be named?
- Pick "descriptive names" over "convenient names", important for group work, large projects(both common with java)
- Use array initializers, like so:
coordinates = new double[] { c1, c2, c3, c4 };
- NOT like so:
coordinates=new double[]; coordinates[0]=c1; coordinates[1]=c2; coordinates[2]=c3; coordinates[3]=c4;
final
to mark array as immutable(but no way to stop the array's fields from being changed in java however)
- GPN:
- choose descriptive method names(do not just call it
get()
) - What should the type of the parameter of the getter be?
- Why not
byte
?- Because people pass it
int
objects, you have to change them to bytes
- Because people pass it
- Why not
- So we use
int
- choose descriptive method names(do not just call it
return coordinates[idx];
- Throws error if index passed is out of bounds however
- GPN:
- java inheritance error hierarchy:
ArrayIndexOutOfBoundsException inherits IndexOutOfBoundsException inherits RuntimeException inherits Exception inherits Throwable inherits Object
- exceptions signal coding errors or things malfunctioning at runtime; need
try{}; catch{}
cases to resolve them if possibly expected. - Also conveniently hides implementation details when you
try{}; catch{}
- Encapsulation and hiding are important
- Creating an interface for the outside that is simple and clean
- Error handling is slower than ignoring errors, but here it is more important to be robust(make programming decisions!)
- Error handling should never be present on the critical path!
- Also important to get the working version quickly, don't get hung up on issues of performance here(too much)
- java inheritance error hierarchy:
- GPN:
- How do we compute it?
- Pythagoras to the rescue! (in 4 dimensions)
- GPN:
- balance housekeeping versus efficiency
- where to we declare variables only used inside a loop?(inside or outside)
- Trick Question- Correct answer is inside since java handles it such that there is no added performance cost.
- where to we declare variables only used inside a loop?(inside or outside)
- Don't use hardcoded values(such as defined numbers of iterations for
for
loops), define apublic static final
value to store the number(easier to change when used multiple times) - Don't add strings in a loop(produces a new string each time, very inefficient)
- Adding them outside a loop is ok(compiler is smart)
- balance housekeeping versus efficiency