Re: Now I Know Why I'm Having Trouble With Objects

  • From: "R Dinger" <rrdinger@xxxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Wed, 13 Apr 2011 08:57:28 -0700

Hi Jim,

I for one think your idea of a chess move validator and future PGN file 
generator is a great idea.  Not only are there many potential objects to choose 
among in your design, but probably more important is that you are interested in 
this project and have an ultimate use for the software.  I think holding your 
attention is of more importance in this situation than developing the most 
efficient or effective system.  While I agree with Sina's suggestion for an 
effective solution, I think it may be too abstract for an early OOP learner.

As to the potential objects in your problem, you could consider some or all of 
the following:

1. Board: a collection object of Squares.
2. Square: a square on the Board has attributes of location, color, what Piece 
is on it and so forth.
3. Piece: base class for all piece types has attributes of color, location and 
so forth.
4. Specific Pieces (like Pawn): subclass of Piece adds attributes for a 
specific Piece like how to move, if captured and so forth.
5. Army: a collection class of one opponent like White that knows who is still 
in play and so forth.
6. controller: a class that controls the flow of the game, not really much of 
an object more a procedure wrapped in object clothing.  I am not an object 
purist!

Parsing the move text will be a big issue in your system.  I think it can be 
done with regular expressions, though.  I think another area of complexity is 
deciding which objects "know" where each Piece is on the Board and being able 
to query the system about moves and captures.

HTH

Richard
----- Original Message ----- 
From: Homme, James 
To: programmingblind@xxxxxxxxxxxxx 
Sent: Wednesday, April 13, 2011 4:24 AM
Subject: RE: Now I Know Why I'm Having Trouble With Objects


Hi Ken,

The only thing I want to do is to check to see if the moves are valid moves. I 
don't care about making the computer win the game. The program is eventually 
going to be a portable game notation file reader and writer when I get up to 
i/o. Right now, I'm just finishing up about arrays, so I was thinking about 
starting out simply. My first program would be one that asks for a move from 
the keyboard. Someone would type in something like e4 or Nf3, and the program 
would check to see things like can that piece move there, is it your turn, did 
you get the syntax of the move wrong, can you move there because one of your 
own pieces is on that square. It's just a way to have a project that I'm 
interested in. I could do Monopoly or something, too, if it works better. I 
just want to learn this stuff and be happy.

 

Thanks.

 

Jim

 

Jim Homme,

Usability Services,

Phone: 412-544-1810. Skype: jim.homme. NonVisualDevelopment.org: Blind people 
can drive computers. Demonstration GUI Programs: You can program GUI's while 
blind. 

 

From: programmingblind-bounce@xxxxxxxxxxxxx 
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Perry
Sent: Tuesday, April 12, 2011 10:57 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: RE: Now I Know Why I'm Having Trouble With Objects

 

Jim,

 

I want to make a small suggestion.  Your starting out with a very difficult 
problem to use OOPO to solve.  The truth is there are a lot of ways you can do 
this for a chess game and none of them are really that good.   The problem is 
chess is really just  search tree and a state machine and making objects out of 
nouns and methods out of actions will not make the best of the chess games.  If 
you're looking to learn OOP I would suggest a game like Monopoly or Life where 
you can actually have Objects work as they should for example you could have 
players on Monopoly, locations that have descriptions, prices, and things of 
the sort.  Maybe start with a card game where you can have objects that deal 
with decks of cards and players and score cards and things of the sort.    It's 
really up to you but Chess gets too complicated to fast and then you're not 
really thinking OOP your trying to decide the best method of figuring out who 
is winning which is a tougher problem then you might think.

 

Ken

 

From: programmingblind-bounce@xxxxxxxxxxxxx 
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Homme, James
Sent: Tuesday, April 12, 2011 3:27 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: RE: Now I Know Why I'm Having Trouble With Objects

 

Hi,

If it's OK, I'd like to take this a little further. I was thinking about my  
little chess move validation project. I thought I would sit down and try to 
write out a little plan, because my book says that the nouns become objects, 
but I started to get confused when I asked myself this question. Do the pieces 
move, do the squares on the board somehow get pieces, or does some controller 
in the sky move the pieces? In the real world, the controller would be the 
player who is moving the pieces. The pieces can't move them selves, and all the 
board can do is sit there and have pieces on its squares. The rules would be 
another object, would they not? Oh my head.

 

Jim

 

Jim Homme,

Usability Services,

Phone: 412-544-1810. Skype: jim.homme. NonVisualDevelopment.org: Blind people 
can drive computers. Demonstration GUI Programs: You can program GUI's while 
blind. 

 

From: programmingblind-bounce@xxxxxxxxxxxxx 
[mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Homme, James
Sent: Tuesday, April 12, 2011 3:20 PM
To: programmingblind@xxxxxxxxxxxxx
Subject: Now I Know Why I'm Having Trouble With Objects

 

Hi,

I found this humorous.

 

Understanding the Parts of VBA "Speech"

 

If you were going to play soccer using BASIC, the instruction to kick a ball 
would look something like

 

"Kick the Ball"

 

Hey-this is how we talk! It makes sense. You have a verb (kick) and then a noun 
(the ball). In the BASIC code in the preceding section, you have a verb

(print) and a noun (an asterisk). Life is good.

 

Here is the problem. VBA doesn't work like this. No object-oriented language 
works like this. In an object-oriented language, the objects (the nouns) are

most important (hence, the name: object oriented). If you are going to play 
soccer with VBA, the basic structure would be:

 

Ball.Kick

 

You have a noun-the ball. It comes first. In VBA, this is an object

. Then you have the verb-to kick. It comes next. In VBA, this is a method.

 

The basic structure of VBA is a bunch of lines of code where you have

 

Object.Method

 

Sorry, this is not English. If you took a romance language in high school, you 
will remember that they used a "noun adjective" construct, but I don't know

anyone who speaks in "noun verb" when telling someone to do something. Do you 
talk like this?

 

Water.Drink

Food.Eat

Girl.Kiss

 

Of course not. That is why VBA is so confusing to someone who previously 
stepped foot in a procedural programming class.

 

Let's carry the analogy on a bit. Imagine you walk onto a grassy field and 
there are five balls in front of you. There is a soccer ball, a basketball, a

baseball, a bowling ball, and a tennis ball. You want to instruct the kid on 
your soccer team to

 

Kick the soccer ball

 

If you tell him kick the ball (or ball.kick

), you really aren't sure which one he will kick. Maybe he will kick the one 
closest to him. This could be a real problem if he is standing in front of

the bowling ball.

 

 

Jim

 

Jim Homme,

Usability Services,

Phone: 412-544-1810. Skype: jim.homme. NonVisualDevelopment.org: Blind people 
can drive computers. Demonstration GUI Programs: You can program GUI's while 
blind. 

 

 


--------------------------------------------------------------------------------

This e-mail and any attachments to it are confidential and are intended solely 
for use of the individual or entity to whom they are addressed. If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it. If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this e-mail without the author's prior permission. 
The views expressed in this e-mail message do not necessarily represent the 
views of Highmark Inc., its subsidiaries, or affiliates.

Other related posts: