 |
.. (לתיקייה המכילה) | |
What is the MtmRailSystemStationParams structure needed for? Should we use it to store common rail station data in our ADTs' implemetation? | |
|
The structure is there to keep AddStation parameter count down to about 5 from about 9. Additionally, it encourages getting part of the error handling code out of the AddStation functions and into a common auxiliary function. Actually, it is advisable (although not compulsory) to NOT use the same structure to store data internally (rather, create your own separate typedef which can be easily replaced with a different structure). This is because implementation needs never exactly match user interface for long. While using an interface structure (though hidden) may seem like convenient and saving code-replication in the short term, in the long term you will be struggling to replace it if your implementation uses the same structure internally. |
What do we do when deleting a mixed station invalidates a line? | |
| For the sake of simplicity, suppose that will never happen (put a debug assertion or an error printout in the code). |
Do we need to keep input/output stream replacement functionality from the first homework? | |
| Yes. As stated in the exercise, all functionality from exercise 1 should be maintained, unless stated otherwise. Moreover, make sure to adapt your old code to the requested code conventions and design principles covered in the meanwhile. |
MtmRailSystem interface lacks a printAllStations function | |
| Added. Please download the updated interface. |
Error codes enum lacks LINE/STATION_ALREADY_EXISTS codes | |
| Added. Please download the updated interface. |
How can we handle the fields common to both kinds of rail stations in a way that prevents code replication? | |
|
Note that you might want to declare one (or more) of your datatypes as internal and exempt from information hiding (and thus not an ADT). In such a case, you need to provide a very good motivation for exposing this datatype fields in the comments in its header. Note that otherwise all major datatypes need to be implemented as ADTs (that is, with information hiding) and all major datatypes (without exemption) need to be according to what was seen in class, in particular - have their own header and .c files. |
Do we have to replace all our data structures with Set? What about the list of stations on a line? | |
|
The list of stations on a line needs to be kept in a specific order and thus a set is not a suitable container (although one may implement that way as the set is ordered). In all other cases, Set must be used. |
AddLine function requires printing the name of a station that does not exist, which is known only inside MtmRailSystem. However, there is no stream parameter to the function | |
| Exercise has been updated - you do not have to print the non-existant station's name, only the fact that there is one. Same goes for printItinerary in the event of an error when one of the stations does not exist. |
Can two stations of different kinds have the same name? | |
| No, station names (and line numbers) are globally unique. |
If tariff was not set, and getCost or printItinerary functions need to print a degenerate output, which to choose - complain about the tariff or print degenerate output? | |
| Printing an error message goes first. |