Re: Airplane Program with Linked Lists. The linked list portion is very confusing to me.
Francis Glassborow wrote:
Seungbeom Kim wrote:
I agree that it should probably be a class at some point in the future,
but what invariants should be enforce by the class at this time?
struct SEAT {
bool occupied; // initially, false
string first,last; // passenger name
int numBags; // max of 4
char mealType; // (r)egular, (v)egetaria, (o)ther
};
I don't see any. (Except that the restrictions upon numBags and mealType
could be enforced by separate classes.) Therefore I don't see an
immediate need to make this into a real "class" (i.e. with private
parts), though adding a constructor would certainly help.
I think you are missing the reason for making data private. It isn't
just to enforce invariants but to reduce the opportunity for accidental
change.
How does seat.set_last("Kim") make the opportunity for accidental change
lower than seat.last = "Kim" ?
And there is an obvious (to me) invariant in that occupied and
the passenger name are linked.
It's not specified what values the other fields should have when occupied
is false. I just assumed that they are meaningless and ignored.
Of course, the corresponding member functions could enforce that they
cannot be read nor written when occupied is false. But I assumed such
a simple example would not go that far.
(and so is the meal type when I think about it)
Of course, I would make it an enum rather than an unconstrained char.
Once you have made data public it becomes extremely difficult to change
the decision for anything more than a toy program.
That's true. But it's also true that a literal translation of a struct
into a class doesn't automatically make it much more flexible. For
example, the decision of what data type each member should be of, or
whether the passenger name should be stored as a single string or a
first/last pair or a title/first/middle/last tuple, for example,
should be made beforehand, and using a class doesn't relieve you
of that design process nor makes such a change much easier.
And this is a toy program with minimal functionality, after all. :)
I understand the value of exercises where you're supposed to pretend
to be working on something serious while you're actually working on
a toy program, but the educational purpose is achieved only when
subsequent assignments involving the changes are tried so that it is
learned how much easier a proper encapsulation makes such changes.
A toy program in which each field is just expanded into three lines
(variable+accessor+mutator) without a specific purpose is not only
weird, but also pointless.
What I'd like to emphasize is that the class interface design should
not be a mere reflection of, nor a mere translation from, an underlying
data structure, but should be the other way round, a higher-level
process that the corresponding data structure is derived from. Too
often, class interface design is presented or taught in the wrong
direction, just to show the formalities of encapsulation.
I haven't found an easy way to handle multidimensional arrays (with
dynamic sizes, of course) in C++ yet; to beginners, I would just
recommend to stick to built-in arrays.
"with fixed sizes", I meant but forgot to add.
Very definitely not the way I would go. Ray arrays introduce a multitude
of problems with argument passing.
I may need better memory or imagination, but what problems?
Not much more than a single-dimensional built-in array, I guess, when
the style "SEAT s[][COLS]" is consistently used, as the OP already did.
--
Seungbeom Kim
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]