In this session we are going to stay a bit with the rational

numbers we introduced in the last session and are going to explore them further.

We are going to introduce in particular an important cornerstone of software engineering,

namely data abstraction, and show how it relates to the model of classes that we've introduced earlier.

So, in this session we will learn several new aspects about classes and objects.

Let's start with the worksheet that we had at the end of last session.

I will just change this, make a new example here.

We'll say, y dot add of y.

What does that give? Well, it gives us 70 over 49.

What you've seen here is that, that's a number that's not as simple as possible.

I would have expected a simpler number, a number maybe ten over seven.

So, why is that? Well, it turns out to be able to do that,

we need to still simplify the rational number.

When we produce them with the addition and multiplication operators, it could be that

we end up with numerators and denominators that can be further simplified by dividing

both with a common divisor. And that operation needs to be done so that we can

print rational numbers in the simplest possible form.

We could, of course, implement this in each rational operation. Add a

simplification step to add and multiply and subtract and so on. But, it would be

very easy to forget this division in an operation. Also, it would violate the DRY

principal, don't repeat yourself. So, a better alternative would be to perform the

simplification just once, and the natural place for that would be in the

initialization code of the class rational, that's when we create the rational object.

Alright. So, let's see how we would do that in the worksheet.

What I'll do first is I will retake the definition of gcd that we have seen the

previous week, and then make it a method of class rational.

What's important is that I put the modifier private in front of it because I

do not want that clients of class rational can see gcd. It's strictly for

implementation purposes here. The next thing I do is I define a

private value, g, which is the greatest common divisor of x and y.

And then, when I create a numerator, I'll say the numerator is x divided by g, and

the denominator is y divided by g. Let's see whether anything changes.

Well, my addition operation now yields the rational in simplified form and that's

what we wanted. So, note that, gcd and g are private

members of class rational. We can only access them from inside the

rational class. In this example, we've calculated the gcd

immediately here on initialization of the class, so that its value can be reused in

the calculations of numer and denom here so we don't have to recalculate gcd every

time someone calls numer and denom. We could also change that, of course.

We could call GCD in the code of numer and denom like that.

So that way we avoid the additional seal G, and it could be advantages if the

functions numer and denom are not called very often.

Then we could amortize the additional cost of the GCD operations here.

What we could equally well do is turn numer and denom into vowels, so that they

are computed only once. So now that would be advantageous if the

functions numer and denom are called very often.

Because, in that case, we've already computed what they are, and we do not

repeat the computations. What's important here is that, no matter

which of the three alternatives we choose clients observe exactly the same behavior

in each case. So, this ability to choose different

implementations of the data without affecting clients is called data

abstraction. And data abstraction is one of the

cornerstones of software engineering. It's a very important principle, in

particular, as systems grow large. In the next step, we want to add two more

methods to our class rational. One method less, which compares two

rational values, and the other, maximum, which takes the maximum of two values.

Let's start with less. So, we would take a rational.

When is this rational that you see here less than the other?

Well, it would be if the numerator times the denominator of the other function is

less than the numerator of the other rational times our own denominator.

We've simply multiplied both sides with the both denominators, and that's what we

arrive at. So, let's test it.

Is x dot less y? And the answer is true, as expected.

The next function we want to do is the maximum function.

So, what could that be? The maximum of the current rational and

the parameter. Well, we'd really be able, want to be able

to use less here. And we want to say, well, if the current

rational number is less than the other rational number then, the other rational

number, otherwise the current one. But, that means we have to refer to our

rational number as a whole. And, in fact, there is a way to do that in

all, most object oriented languages this is either called "this" or "self".

So, this refers to the current rational. So it would, would say if this is less

than that, then we'll return that, otherwise, we return this.

And we can also test it. X maximum of y would be five, seven,

because that's the bigger of the two. So, we've seen that, on the inside of a

class, the name this represents the object on which the current method is executed.

And you've seen that this is essential for certain operations such as Maximum where

we have to return the whole rational number as a result, as you see here.

Okay. So, now that we are there, We can actually make a further

simplification. If we refer to a name x in a class,

that's really just an abbreviation for this dot x. So, the, the members of a

class can always be referenced with this as the prefix.

So, an equivalent way to formulate the less method is as follows.

That we say this.numer times that.denom, less than that.numer times this.denom.

And together, with the choice of our parameter name, now you see why we've

called it that. That gives us a nice symmetry in the

operations between the left operand and the right operand.

Okay. As a next step, let's look at some of the

restrictions we have to impose on rationals.

As a motivation, let me create a rational val strange equals new rational one over

zero. And then, add strange to itself. What do we get?

We get an arithmetic exception division by zero.

Because of course, a rational that has a denominator of zero doesn't exist.

It's not a rational number. So, how can we guard against users

creating illegal rationals like that? One thing we could do is add a requirement

into our class. So, show you how that's done.

We could require that y is different from zero, and then we could say denominator

must be non zero. If we do that and look at the worksheet,

then now our exception has changed. It now says, illegal argument exception,

Denominator must be nonzero. So, a requirement is a test that is

performed when the class is initialized here, and if that test fails, then you,

you will get an exception, in this case, an illegal argument exception.

So, let me remove the problematic lines to get a clean work sheet again.

The require function that we've called in class rational is actually a predefined

function. So, it's already defined for us.

And it takes a condition, that's the test and an optional message string.

In our case, that was the denominator must be positive.

If the condition here is false, then require will throw any illegal argument

exception, And that exception will contain the

message string. Designs require that's also another test

which is called assert. Assert takes a condition like require and

also an optional message string so you could use it like this for instance,

X equals square root of y. And then, you assert that x must be greater or equal

to zero. Like require, a failing assert will also

throw an exception, but it's a different one.

Now, it will throw an assertion error instead of, before, an illegal argument exception.

That, in fact, reflects a difference in intent.

Require is used to enforce a precondition on the caller of a function or the creator

of an object of some class. Whereas, assert is used to check the code of the

function itself. So, if a precondition fails, then you get

an illegal argument exception. Whereas, if an assertion fails and it's not the

caller's fault and consequently you get an assertion error.

Another syntactic construct we're going to cover is constructors.

In fact, in Scala, every class already implicitly introduces a constructor which

is called the primary constructor of the class.

That primary constructor simply takes the parameters of the class and executes all

statements in the class body. So, for instance, the constructor of class

rational would take the x and y as the parameter, and then execute the class

body. So, that means, it would execute the require,

It would execute the value definition here, and for the def, there's nothing to

execute. If you know Java, then you're used to

classes having several constructors. In fact, in Scala, that's also possible,

even though the syntax is different from Java.

So, let's say we want to have a second constructor for class Rational that only

takes one integer: denominator. In that case, we would assume that the

nominator could be zero. We can just write as follows. We can write

def this x int, And then we write x and one. So, what you

see here is a second usage of the keyword, this, now used in function position.

If this is used as a function, then it means a constructor of the class. So here,

we define a second constructor for class rational in addition to the primary one.

It only takes a single argument, and what it does it calls another constructor with

the two arguments. That constructor takes two arguments is in

fact the implicit primary constructor of class rational.

So, if we do that, then we can use class rational in a simpler way.

We could, for instance, say new rational of two,

And that then would give the rational two over one.

So, we could conveniently omit the denominator if it's one.

So, let's do an exercise. Modify the rational class so that all

rational numbers are kept unsimplified internally,

But the simplification is applied when numbers are converted to strings.

When you've done that, think about where the clients of the new class rational

would observe the same behavior when interacting with it, same behavior as the

previous one. Possible answers are yes, no, or yes for

small sizes of denominators and nominators and small numbers of operations.

Okay. So, let's see how we would solve this example.

So, I can leave the gcd function because I will still need it, but I remove the

definition of the value G as well as the two divisions here, so that means that

rationals are, from now on, kept unsimplified.

You see that our x add, sorry, our y example jumped back to seventy over

forty-nine instead of ten over seven. So, what we do instead is we go into the

toString function and do something there.

What I propose is that we define our gcd function in toString. val g equals gcd

of numer and denom. And then, we divide numer by d and denom

by g, and that would do the trick. So, now we keep the rational number unsimplified.

But, before we print it, we perform the simplification. And in our case, all the

results really gave back the same value. So, is that always the case?

Well, the answer, actually, is no. It's only the case if the numerator or

denominator is small. The reason for that is that we are dealing

here with integers as the fields of a class rational.

And, so we might exceed the maximal number for an integer which is a bit more than

two billion. For that reason, it actually, it's

actually better to always normalize numbers as early as possible because that

means that we can perform more computations without running into

arithmetic overflows.

Lecture 2.6 - More Fun With Rationals

Functional Programming Principles in Scala

Meet the Instructors