您在這裡

Solutions to Exercises in Chapter 2

15 一月, 2016 - 09:02
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at http://cnx.org/contents/402b20ad-c01f-45f1-9743-05eadb1f710e@37.6

Solution to Exercise 2.1

No, it won't compile. IBinaryOp is an interface and does not specify any actual executable code, so it cannot be instantiated.

Solution to Exercise 2.2

Yes! AddOp is an concrete class and can be instantiated. AddOp is an IBinaryOp (technically, AddOpimplements the IBinaryOpinterface), so bop can reference it.

Solution to Exercise 2.3

Yes, for the same reasons as the previous exercise! MultOp is an concrete class and can be instantiated. MultOp is an IBinaryOp, so bop can reference it.

Solution to Exercise 2.4

The result is 8 because bop refers to an AddOp instance, whose apply method adds its two input values.

Solution to Exercise 2.5

The result is 15 because bop now refers to an MultOp instance, whose apply method multiplies its two input values.

Solution to Exercise 2.6

It is impossible to tell because it depends on the exact type of the object instance to which myOp refers.

Solution to Exercise 2.7

No, because bop is a variable of type IBinaryOp, which is not defined as having a getDescription method. This is true even if bop references an object of type MultOp. This is because the static typing of bop tells the compiler that it references an IBinaryOp, not the particular concrete type of the object it currently references. If we had MultOp mop = new MultOp(), then mop.getDescription() is perfectly legal.

Solution to Exercise 2.8

Yes, because aop is a variable of type AddOp, and thus can reference an instance of the same type.

Solution to Exercise 2.9

No, because aop is a variable of type AddOp, and MultIOp is not an AddOp, so aop cannot reference an instance of MultOp.

Solution to Exercise 2.10

Yes! bop is a variable of type IBinaryOp, and aop is defined as referencing an AddOp object, which is an

IBinaryOp .

Solution to Exercise 2.11

Not as written, because bop is a variable of type IBinaryOp (i.e. staticly typed as such), which and does not necessarily reference an object of type AddOp. to which aop must reference. That is, a variable of the type of the superclass can always reference an object of the type of any subclass, but a variable of the type of a particular subclass cannot necessarily reference something of the type of its superclass. Another way of saying this is that a superset contains its subsets but not the other way around. The above assignment will cause a compile time error because the compiler cannot know if the assignment is possible. An explicit cast is required to supress the compile time error (aop = (AddOp) bop), but may trigger a run-time error if indeed the instance referred to by bop is not of type AddOp.

Solution to Exercise 2.12

Try it!

Solution to Exercise 2.13

Use the same techniques as before: strategies that hold strategies.

Solution to Exercise 2.14

But isn't a MultiStrategy an IUpdateStrategy iteself? That is, since a MultiStrategy holds IUpdateStrategy's, couldn't a Multistrategy hold a Multistrategy, which is holding a Multistrategy (or two) which is hold a Multistrategy, which is holding.....?