Re: Data hiding in C++
From: Gary Labowitz (glabowitz_at_comcast.net)
Date: 08/23/04
- Next message: Gary Labowitz: "Re: Data hiding in C++"
- Previous message: Artie Gold: "Re: printf"
- In reply to: Jerry Coffin: "Re: Data hiding in C++"
- Next in thread: Alwyn: "Re: Data hiding in C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 23 Aug 2004 10:48:20 -0400
"Jerry Coffin" <jcoffin@taeus.com> wrote in message
news:b2e4b04.0408222208.676708e7@posting.google.com...
> "Gary Labowitz" <glabowitz@comcast.net> wrote in message
news:<tNWdnf7i8NaJ87XcRVn-pw@comcast.com>...
>
> [ ... ]
>
> > A class, on the other hand, should represent one object which has
properties
> > and methods. What it appears you are saying is that a class has one
property
> > which is set at construction and one method.
>
> Not necessarily -- there are perfectly good reasons for other kinds of
> classes. However, if you have a variable and need it protected to the
> degree that it needs a get/set wrapper, then that's normally enough
> responsibility for one class, and other responsibilities should be
> separated out into other classes.
Okay, I get your point.
>
> > I am picturing a class Account which has properties such as
AccountNumber,
> > CurrentBalance, AvailableBalance, AccountStatus, etc. that reflect the
> > "state" of the account. It would appear that you would rather have a
class
> > for AccountNumber, another class for CurrentBalance, etc.
> > I am not going to work out details, but it would appear such a design
would
> > work, but with some strange interoperations between the classes. The
Account
> > class would be a composite of the various other classes which would
> > otherwise be properties.
> > If this is what you are saying, it is a different approach. Not a
"correct"
> > one any more than mine is. It is another one.
>
> How can you possibly claim another approach is anywhere close to equal
> when it results in code that's harder to write correctly, harder to
> read, and nearly impsosible to maintain?
>
> > I submit that it is possible to program objects that contains several
> > properties, and that it may be needed to set/get some of them because of
> > validity checking, security checking, or data transformation.
>
> You can submit anything you want. So far, you've shown precisely
> nothing to show that what you're advocating is even close to adequate,
> not to mention equal.
I guess we just plain disagree on this one.
<<snip>>
> I figure after anything over 20 years, it really doesn't matter
> anymore -- I can't think of many ways in which the code I wrote for
> CDC mainframes decades ago really makes much difference to what I'm
> doing today.
Yes, you are right. I'm an old dinosaur, I guess, and find it hard to
change, especially when it's more work. The reason code from 20 or 40 years
ago makes a difference is that we did it, got it to work, and grew a mindset
of how programming is done. The total of what we do now (with all the "new"
stuff) is flavored with the gestalt of our programming. "You can take the
boy away from the 1401, but you can't take the 1401 out of the boy."
> I'm guessing that's because you didn't really pay close enough
> attention to what I said -- struct tm itself existed before the
> standard committee go into the act. One of their main contributions in
> that area was strftime. This is significantly different: it provides a
> relatively abstract interface, so you specify the format in which you
> want a time to appear, and it takes data in a struct tm and formats it
> as you requested.
Which leads to "formatter classes" as in Java. You create a class which does
nothing but format the data. You create your data, you create your
formatter, then you call your formatter, handing it your data. It's a way,
and I am assuming that you like this much better. However, you still have to
"program" which implies that steps are taken in some specific order. I
myself don't find this all that much "better," just different. YMMV. ["It's
all just zeros and ones."]
My students, OTOH, tend to learn more about programming starting with the
old-fashioned way. They take the data they have and they format it. After
they understand how that works (if ever!) I can introduce the OO way. But
that's a different course, usually. I realize I'm approaching this from a
different point of view and with respect to teaching rather than actaully
producing paid-for code, so I'm sure my valuation of "goodness" of code is
different.
<<snip Meaning of modality paragraphs>>
Thank you, just what I wanted to know.
> ... Second, you end up with code that depends more on data and less on a
> whole sequence of operations being coded in the right order.
But all programming depends, more or less, on a squence of operations being
coded in the right order.
-- Gary
- Next message: Gary Labowitz: "Re: Data hiding in C++"
- Previous message: Artie Gold: "Re: printf"
- In reply to: Jerry Coffin: "Re: Data hiding in C++"
- Next in thread: Alwyn: "Re: Data hiding in C++"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
