Collection Class

You$$re also going to need a collection class called Package which will hold a Radio $$package$,$

that is$,$ one or more Radios, a PowerSupply, and one or more Antennas.

This class needs to have an accessor and mutator for the Radios $($however they are stored$),$ as

well as for the PowerSupply. It needs to have an add$\_$antenna method that appends an

Antenna object to its list, and a drop$\_$antenna method that removes an antenna from the list

based on an index number. Make similar methods to add and drop radios, too. There should

be a method to tell how many Radios are in the package, and another to tell how many

Antennas are in the package. There will only be one power supply per package.

In similar fashion to your last assignment, you will use a set of index values to construct

packages. They will be expressed as a list of tuples $($which will be presented later$).$

The challenge here will be to write a method in this class called validate$\_$package that takes no

parameters, but returns True if the package is valid, as well as the empty string $(),$ and False if

it is not valid or is incomplete, and a string giving the first detected reason for invalidity. You

can use a statement like:

return is$\_$valid, reason

Where is$\_$valid would be a Boolean value, and reason would be a string. Thus, a call to

validate$\_$package for some package reference p might look like:

validity, response $=$ p$.$validate$\_$package$()$

You can then use the Boolean and the response to report any problems; here$$s an example of

one possible problem:

Package removed: Power supply amperage is insufficient for radio.

Obviously, there$$s nothing to report if it$$s valid $$ you can return an empty string.

How do we validate?

A package is provisionally valid if:

$$ It contains at least one Radio

$$ It contains at least one Antenna

$$ It contains a PowerSupply

If any of these fail, you don$$t need to do any further checking $$ the package would be invalid.

Assuming it has all three categories, we continue the process of checking.

The PowerSupply must meet the safety requirement $($shown previously$)$ for all Radios in the

package. If it cannot be used with all of the Radios, then the package is invalid. Note that some

Radios, like handhelds, may not use the PowerSupply in the package, they will have their own

charger $($i$.$e$.$ their sole power type is Battery$)$ this will not invalidate the package. This would

be a radio with only B as its power code. If it contains D$,$ then it needs to be checked against

the PowerSupply. If it has A$,$ it has its own AC$/$DC power supply internally. Create a function in

RadioToolbox to check compatibility of a PowerSupply and a Radio, and will return a Boolean

according to the aforementioned rules. Use that function in doing this check; call the function

radio$\_$power$\_$compatibility $$ it takes a radio and power supply reference, and checks them by

the rules defined above.

Then, we need to be sure that every Radio in the package has at least one Antenna that is

compatible with it$.$ Recall that Antennas are compatible if they have a band in common with

the radio, and if they have a compatible connector $($as per your RadioToolbox$).$ If a package

contains a Radio for which there is no valid Antenna, it is invalid. Remove any radio for which

there is no valid antenna. Hint: Remember, your RadioToolbox has a function for determining

compatibility. Does it satisfy these requirements?

It is also possible that a package might contain several antennas $$ and it$$s possible that one or

more of them might not be compatible with any Radio. So$,$ while the package is valid in that

there is at least one Antenna for every Radio, there may not be one Radio for every Antenna.

Remove any Antennas for which there is no compatible Radio, as they would be useless, and

then the customer would have to go through the hassle of returning the Antenna$($s$)$ that are

unusable.

Now, recheck the package for proper counts $(1$ of each item$)$ after any pruning is done. It might

be wise to create a $$helper$$ method $($prefixed$,$ but not suffixed, with double underscore $\_\_$ to

make it private, and used internally only$)$ that will do that count$-$check initially. Helper methods

exist in the same class to do subtasks related to methods of that class that make no sense to put

in a toolbox class.

So$,$ at any of these stages, if the tests in that stage fail, you can return False with the description

of the problem, and stop checking. You are not generating a list of all problems; you stop as

soon as you find any problem, and report it