And we would have the three accessor methods for either Numbers or Sums, which

we've numValue, which, this one applies only to Numbers.

And leftOp, rightOp,, these ones do apply to sums.

So to implement these five methods, what do we do in Number?

Well, isNumber obviously is true, isSum obviously is false. The numeric value of a

number is just the number we pass into it. And the left operand and right operand,

they are operations that are not applicable to Numbers. So both of them

would throw an error that says that say well you have called a leftOp or a rightOp

method on number and that is illegal. So let's look at Sums next.

So the idea would be that Sum of e1, e2 would correspond to the expression that is

e1 plus e2. Its five implementations are as follows.

A Sum is clearly not a Number. A Sum is a Sum.

The numeric number of a Sum is something that's not applicable, that would throw an

error. The left operand is the first argument

that we pass into Sum. The right operation is the second argument

we pass into Sum. So now that we've got the basic wiring of

expressions, let's do something with it. One thing we could do is write an

evaluation function. So the evaluation function should take one

of these expression trees and it should return the number that it represents.

So for instance, I would like to have that eval of Sum of the Number one and the

Number two, Should give me three. So how would I write an evaluation

function like that? Well, one way to do that would be to

simply ask, given an expression, what it is?.

So, we ask this question, is it a number. If yes, then we can return the numeric

value of that expression. Otherwise, if the expression is a Sum then

we take, it's both two operands, the left operand and the right operand and we

evaluate both of them using eval. And finally, you have to guard against the

case that you might have another expression that is neither a Number or a

Sum. Maybe not now, but maybe in the future,

somebody will add such a subclass of expression.

So it's prudent to have a third class which says well, if it's neither a Number

nor a Sum, Then we throw an error which says I found

an unknown expression and here it is. .

Okay. So far so good.

But there's a problem with that and that is that writing all these classification

and access of functions quickly becomes tedious.

We've already written fifteen method definitions only to do something as simple

as expressions consisting of Sums and Numbers.

And things get worse if we add other forms of expressions.

So let's demonstrate that. Let's say we want to add to our expression

trees two new classes. One that represents the product of two

expressions, e1 and e2, So e1 times e2 would be a class product

given arguments e1 and e2. and the other new class would be Var that represents

variables. So variables would take a string that

represents the name. So if you want it to continue with our

scheme of classification and access methods, then we'd need to add new methods

to, of course, those two new classes but also to all the classes defined above.