Algorithms and OOD (CSC 207 2014F) : EBoards

# CSC207.01 2014F, Class 07: Classes and Objects, Revisited

Overview

• Preliminaries.
• Upcoming Work.
• Extra Credit.
• Thinking in Objects.
• Naming Conventions.
• More Fun with Fractions.
• Lab.

## Preliminaries

• Surveys!
• Because of confusions raised yesterday, we'll spend some time debriefing on the lab. We'll move on to arrays tomorrow.
• Reminder: I am happy to receive questions via email or via the anonymous Google question form. (I'll often respond via class email or these daily announcements.)

### Extra Credit Opportunities

• Convo Wednesday at noon. "Limiting Armed Drone Proliferation" by Micah Zenko, the Douglas Dillon fellow in the Center for Preventive Action at the Council on Foreign Relations and vice chair of the World Economic Forum Global Agenda Council on Terrorism.
• Any other event in the Rosenfield Drones program.
• CS Extra, Thursday, September 11: Ajuna Kyaruzi '17 on being a SysAdmin
• CS Table, Friday, September 12: Socially-Assistive Robots Help Children with Autism

#### Peer Support

• Men's Soccer Wednesday at 5:00 p.m.

#### Miscellaneous

• Second-year students get extra credit for doing the second-year science retreat on Sept. 20.

### Questions

• What do you mean by "an experiment"?
• Sam tries to use "test" to mean "unit test"
• Sam uses "experiment" for "code I write and run and look at the output"
• Sam, like most Unix programmers, doesn't like typing a lot, so writes "Expt" rather than "Experiment"

## Thinking in Objects

• Imperative (and functional) model: Apply a procedure to values.
• "Multiply 6 and 7"
• Sometimes, there are special symbols for certain procedures
• `6 * 7`
• If we are explicit, we give the function
• multiply(6,7)
• When you start working in more of an OO-model, we instead stay "tell this value to do something" (perhaps with inputs)
• Concrete in OO languages
• 6.multiply(7)
• Why do we do things this way?
• For many operations, it makes more sense. (But we can't come up with a quick answer on the fly.)
• Uniform approach: If we do it for many operations, why not all?
• As time passes, I see Java making a wider variety of choices. String[] names = { ... }; pen.println(names.toString()); // More OOP pen.println(Arrays.toString(names)); // More imperative
• When writing methods, we always have an implicit "this object". We always use the name `this` to refer to the implicit object (at least in Java).
• For multiply, we'll expect to write

``````public class Fraction
{
BigInteger num;
BigInteger denom;

{
// a/b + c/d = (ad+bc)/bd
BigInteger resultNumerator =
BigInteger resultDenominator =
this.denom.multiply(that.denom);
return new Fraction(resultNumerator, resultDenominator);
} // class Fraction
``````
• Java has a huge collection of built-in classes.

• Why do we have the keyword `new`? Because we're building a new object, rather than modifying the current one.
• Whenever we build a new object, we explicitly or implicitly call `new ClassName(Parameters)`

## Naming Conventions

• Question to me: Should every field start with an `m_`?
• So, are there naming conventions we should follow?
• Capitalization
• constants: ALL CAPS, underscores to separate words
• Use good names: no "a" but "firstName" or whatever
• One letter names are hard to search for.

• Why is Eclipse evil?
• Computers are sentient and malicious
• And it looks like IntelliJ, while better, will hate our home directory structure

## More Fun with Fractions

What might be wrong with this code?

``````    public class Fraction
{
BigInteger num;
BigInteger denom;

public Fraction(BigInteger num, BigInteger denom)
throws ZeroDenominatorException
{
this.num = num;
this.denom = denom;
} // Fraction(BigInteger, BigInteger)

{
// a/b + c/d = (ad+bc)/bd
BigInteger resultNumerator =
BigInteger resultDenominator =
this.denom.multiply(that.denom);
return new Fraction(resultNumerator, resultDenominator);
} // class Fraction
``````
• Whoops! We should simplify.
• How do we simplify fractions?
• In 22/20, both sides are divisible by 2, so divide each part by
1. 11/10.
• Find a common divisor of numerator and denominator and divide each by that divisor.
• Alternate: Greatest common divisor (e.g., for 44/20, we should use 4, even though 2 is a divisor).
• Writing gcd

• Two parameters?
• No parameters? Use `this` (Unfortunately, we want something more general)
• Implementation: Euclid's algorithm
• Maybe one parameter: The other value (implicit: this

class BigInteger { public BigInteger gcd(BigInteger that) { } }

• We don't even have to write it! Yay!

• Code!

``````  public Fraction add(Fraction that)
{
// a/b + c/d = (ad+bc)/bd
BigInteger resultNumerator =
BigInteger resultDenominator =
this.denom.multiply(that.denom);

BigInteger gcd = resultNumerator.gcd(resultDenominator);
resultNumerator = resultNumerator.divide(gcd);
resultDenominator = resultDenominator.divide(gcd);
return new Fraction(resultNumerator, resultDenominator);