I’d say no, you don’t have to override every designated initializer from the superclass chain, only your class’ direct super. However, this challenge seems weird to me. In real life, the container would never be a subclass of the item, that’s just weird; my question is, do you absolutely HAVE to have your designated initializer point to your super’s designated initializer?
BNRItem’s designated initializer asks for valueInDollars which is a useless parameter for the container as the value in dollars for the container is simply the aggregate sum of it’s component’s values.
So can we instead have BNRContainer’s designated initializer do the following?
The super’s init would call it’s own designated initializer and pass 0 as the valueInDollars.
I said earlier that I disagreed with having BNRContainer subclass BNRItem. A lot of the stuff in Item is useless for the container and just bloats it. A better way of doing this would be to have an abstract class BNRThing (an abstract class is like any other class, but it itself is never used; instead, it contains a bunch of generic attributes and methods (name, dateCreated, serialNumber… as well as accessors)), which would be subclassed by a lot of other classes that need it’s attributes and methods, including BNRContainer and BNRItem.
My two cents,
Edit: It seems my Comp Sci theory is a bit rusty, what I called an “Abstract Class” is actually called and Interface. Abstract classes are something similar but slightly different.
For the curious:
en.wikipedia.org/wiki/Class_(com … rogramming#Abstract_and_Concrete
en.wikipedia.org/wiki/Interface_ … er_science#Software_interfaces_in_object_oriented_languages