cross-platform c++ classes?

Tue May 22 06:57:02 2001

Rob,

Just a few questions. See below.

Thank You,

David Demland
QA/Process Manager
CADTEL Systems, Inc.
11201 N. Tatum Ste. 200
Phoenix, AZ 85028
(602) 648-6054
Fax: (602) 953-4833
ddemland@cadtel.com

-----Original Message-----
From: plug-devel-admin@lists.PLUG.phoenix.az.us
[mailto:plug-devel-admin@lists.PLUG.phoenix.az.us]On Behalf Of Rob
Wehrli
Sent: Tuesday, May 22, 2001 4:42 PM
To: plug-devel@lists.PLUG.phoenix.az.us
Subject: Re: cross-platform c++ classes?

David Demland wrote:
>
>
> I am creating a blackjack program. There are five objects to this program:
> Card, Deck, Hand, Player, and Dealer. Most of the work each does can be

> Don't forget Chip, Bet, Payout, Shoe and Table.
>
> Shoes have some number of Decks and may know how to shuffle Deck(s).
> Player(s) make Bet(s).
> Table(s) contain Players (always at least two since Dealer->Player)
> Chip(s) are representives of Bet amounts and can be transfered between
> Player and Table using Payout (+ and -).  Payout might better be as an
> interface used by Dealer(s).

COMMENTS:

Why would you need all these extra objects. First of all the Chip and Bet
are the same object. Chips are just the display unit for the bet. Both of
which can be handled by a Player. After all is it not the player that makes
the decision on what the bet is. After all when was the last time you saw a
video blackjack program exchange Chips instead of just displaying total
numbers? Payout and Table are these not functions of the Dealer? After all
when playing at a table who controls these decisions? Does the player
declare who wins, or is it the dealer? The answer to this would show the
real world implementation. Also Shoe is a HASA relationship of deck which
means that the deck would contain the information for a Shoe object. Since
this deals only with the Deck why would anything but the deck need to know
about this, which brings up the question is Shoe really a separate object or
part of the Deck?

> figured out pretty easy. I'll look at just one of the objects for now the
> Dealer. The Dealer is a inherited class from Player. This is because the
> Dealer is nothing more than a super player so to speak.

> There are some subtle nuances to consider when inheriting Dealer from
> Player.  ISA Dealer a Player?  Using inheritance for specialization is
> not uncommon, but oftentimes a poorer choice.  A Dealer must abide by a
> different set of rules than a Player.  Does this "specialization" make
> the Dealer a unique Player type or does it add confusion to the
> inheritance path?  A Dealer (in some rule implementations) must hit on
> 16 and stand on 17, for example, whereas Players do not have to abide by
> this rule.  A Dealer always has a hidden "hole" card, whereas Players
> oftentimes do not.  Now that there are some very distinct differences
> between Players and Dealers, it almost suggests a different base class
> for both rather than a Dealer is a kind of Player.  ...not that you can
> not facilitate an implementation where a Dealer ISA Player, but is it a
> really good use of inheritance?  Perhaps both are kinds of Participants?
> ...or some other, more generic base where there can be a virtual
> implementation or pure virtual base class for your derived classes to
> "follow."

COMMENTS:

Since the Dealer is also a player why would you want to re-implement the
Player code in the Dealer as well. Does this not break the use goal of OO?
After all does the Dealer really abide by different rules than the player,
or is it that some Dealer operations are done different? For example both
need to know how ask for a card, both have to know how to "hold" a hand (no
more cards), both have to know their own name, both need to be able to show
their hand, and so forth. Take your example of a hit. Both the Player and
the Dealer have to know how to take a "hit". The actual operation of a hit
is different for both but since both are required this function would it not
be best to override the player hit method for the dealer? This way we get
all the other operations without recoding.

>
> It is simple to do. Just remember to separate the process from display.
This

> Separation of Data manipulation from Presentation of the Data is a
> common architectural theme.  Microsoft calls it "Document/View," where
> the document is the data and the view is the presentation of the data.
> The Doc is oftentimes passed to a presentation-centric "view" that knows
> how to present the data based on the needs of the windowing subsystem
> and implementor's requirements for the presentation of a particular set
> of data.  This "close coupling" of data and presentation tend to create
> two pieces of code that are somewhat dependent on each other while
> separating functionality on a "role" basis.  However, careful observance
> of Microsoft's MFC-based implementation of D/V will find an
> intelligently established set of relationships between base classes that
> must be subclassed by users for their own D/V implementations.  Behind
> the scenes, MS has given the programmer as much language "training" and
> good language feature usage "principles" as possible then left it up to
> them to simply fill in the blanks with their specific implementation
> without too much concern for future bending of the rules of good OOP.

COMMENT:

This idea is not a Microsoft idea. For those of use who was writing platform
independent code years ago, we had to do this type of architecture just to
keep from rewriting our whole application just to move it to a new platform.

> will allow a platform independent application with a small display library
> only. This type of programming allows for the application for become more
of
> a "middleware" type of application. This is one of the key points of the
> case against Microsoft about how they want to eliminate "middleware" just
to
> ensure that users are on the WinTel platform.

> I'd be at least a bit cautious when trying to summarize anything related
> to MS.  They have perhaps 35,000 of some of the world's best programming
> talent in their "skills inventory."  If you understand that all of what
> Windows is (these days) is COM, then you'll find at least some hardship
> in swallowing the above statement regarding eliminating middleware.
> Microsoft = componentware.  Everything is a component.  Just about every
> single piece of Microsoft code I've seen (past the first couple of
> service packs :) above the C library implementation is very
> well-written, highly optimized, strong OO-based code.  They have done a
> tremendous job at turning their platform into a very unified example of
> extremly closed code...that happens to be "open" only because it is
> rather popular and many millions of people are "discovering"
> new/undocumented things about it everyday.  Nothing could be more
> "right" from the perspective of truly "equalizing" Microsoft than the
> Justice Department forcing them to make their code open source, but it
> is truly anti-business in today's world...and I'm not so sure that it
> would even be a "good thing," but at least we'd all learn VERY MUCH if
> it happened.

COMMENT:

Lets get one thing clear, there is s difference between COM (Component
Software) and middleware. Middleware is code that the underline display code
can be changed out from underneath it without the application code being
effect. This is because the application uses an API approach to get to the
display code. This is very different from COM where objects are tied to the
OS and not the display. COM objects can not be moved from OS to OS without
being rewritten, middleware has an interface that shelters the code from the
OS. This is the key difference of the two.

> I hope that I haven't insulted you in anyway in this replie, I sometimes
> come across as a "know-it-all" and that is at least the furthest thing
> from the truth.  Perhaps I'm overly opinionated :) ...if I've offended
> you, please accept my apologies, my goal is only to try to share my
> experiences rather than incite riots and heated debates...which are
> always a possibility when programming is involved.  The truth about MS
> (IMHO) is that once you forget about the closed system, once you forget
> about the "company profit ethic," you'll find that they have produced
> some of the finest code in the world.  You may not be able to appreciate
> it fully from the perspective of their other "problems," but they have
> invested more good money in their codebase than most nations make in a
> year.  I believe that in a not-too distant future, MS will *have* to
> open their source to remain competitive, but today, it may as well be a
> million years from now.  Remember the Mundie anti-open source message?
> It sounds as if he is facing a rather large pill to swallow.

COMMENT:

No offence taken. Yes Microsoft does have some good software. Project, Power
Point, and Excel are examples of some of the best software for their areas.
But SourceSafe, Wind Word, and Project Central are all but total failures
and they are still in use because of the acceptance of software in any state
from a vendor because the vendor said it has to be that way. This is the
disservice for the customer that has to be changed by all of us in the
industry.

> Lastly, OO was designed to make programming more like real life.  A Cat
> "isa" Animal...OK, easy enough.  But a Dealer isa Player?  Logical
> outsider's opinions would naturally say, yes..a dealer is playing and
> therefore isa player.  But as we start to define what makes a "Player"
> and what makes a "Dealer," we soon realize that they are certainly
> similar, but one is definitely not the other (inheritance for
> specialization "error").  The logical fact that in real life they are
> both "players" serves only to confuse the issue and muddy the waters of
> "Pure OOP."  They are both Participants in the game, but to go further
> and say that the Dealer isa Player suggests the logical, which hides the
> pragmatic aspects that make them extremely different, if only in the
> smallest, most subtle ways.  Whenever we see these kinds of subtleties,
> a warning flag should POP UP and make us ever more careful to ensure
> that we're avoiding confusion at all costs, even to the point of
> rewriting complete class libraries if necessary.  It is, certainly, a
> utopian endeavor that isn't easily communicated to all OO programmers.
> In the Cat isa Animal, sure, it is, we all know it to be true because it
> meets the description of what Animals are.  A Dealer isa Player meets
> the description at first glance, and thus is the source of potentially
> endless confusion because a Cat isa Animal because it "IS," but a
> Dealer's *role* as a Player, while similar, is *not* what a Player IS.
> Does that make any sense?  So, a Dealer ISA Participant and a Player ISA
> Participant because BOTH "are" a kind of Participant.  It is tricky for
> some folks to get the "finer" sense of OO because it seems nit-picky at
> times, but subtle "OO errors" have a way of growing into truly amazing
> proportions very quickly as programmers take for granted that you said
> IT IS, but at some point, it IS NOT. :)  When we say that it is, it has
> to be all of the time in every case or else it isn't.  Bird.fly()?
> Ostrich isa Bird but _all_ Birds do not fly().  This last point is an
> obvious example in the extreme condition, but it serves to illustrate
> the mindset needed for better OOP.

> For C++ programmers everywhere, read Cline's FAQ book.  While it won't
> be overly helpful in answering any major ambiguities or gaps in
> knowledge of OOP or C++ language fundamentals, it is very helpful in
> being a reminder of what are GOOD things to do and what are BAD things
> to do.  C++ is always a learning process for all OO programmers.  Once,
> while sitting in a room full of C++ masters from around the world, the
> one thing that they could definitively agree upon was that there are
> plenty of ways of accomplishing some task using any number of features
> found in the (extremely complex) language, but that no matter which path
> you take/took, you could learn something new from and about it because
> it enables you to model real life...you may model it "properly" or
> "improperly" to any degree in between with C++ because it will happily
> allow you to say class Dealer : public Player{}; (or any other example)
> Because C++ knows *nothing* about real life.  It is up to us to
> interpret life (the artistic part of being an OO programmer) and to
> ensure that our model is "correctly" modeling that portion of life that
> we're implementing.  Obviously, there is a lot of room for
> interpretation in any implementation choice.  And, the one thing that is
> certainly a constant in life is that it changes over time.  Just as life
> and our model of it must change, our implementation of it must change.
> For that reason, we use the mechanics of the language to facilitate the
> eventual changes by using the _4_ key OO "points of interest."
> Abstraction, Inheritance, Polymorphism and Encapsulation.  (Most use "3"
> points and leave Abstraction off of the list, but I feel that it is a
> necessary "player" to *reaffirm* the GOAL of correct use of the
> language.  Of course, an in-depth study of Encapsulation would require a
> lot of discussion of abstraction...and a "Pure OOP" discussion on
> Inheritence requires it, too, especially in pure virtual bases.
> Polymorphism is uniquely abstraction through multiple implementations,
> which is a whole 'nother topic :)

>
> Thank You,
>
> David Demland

Take Care.

Rob!
_______________________________________________
PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel