[program-l] Re: Python: Please Help Me Think Out Loud About When To Make Classes And When Not To Make Them

  • From: "Corbett, James" <James.Corbett@xxxxxxxxxxxxx>
  • To: "'program-l@xxxxxxxxxxxxx'" <program-l@xxxxxxxxxxxxx>
  • Date: Wed, 31 Oct 2012 13:01:00 +0000

Despite your cranial capacity it was well said.

Jim

From: program-l-bounce@xxxxxxxxxxxxx [mailto:program-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jacob Kruger
Sent: October 31, 2012 8:57 AM
To: program-l@xxxxxxxxxxxxx
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

Think, and this is from my side, it comes down to that even something like a 
string object/variable, in most of the languages deal with nowadays is rendered 
as an object if you want to treat it that way, with functions and properties 
like length, substring, etc. etc.

Old jokes about explaining object orientation to non-programmers come down to 
taking any standard every day item, and explaning it in an object oriented 
manner - that fork on the table has an array property of tines/points, which 
has a length of 4 for this type of fork, which is another classification 
property, and it has other properties, like material it's manufactured from, 
length, width, descriptive specification, etc., and for methods/functions you 
can use general things like eating() would return food/sustenance, whereas a 
standard method to make use of with the object might be something like 
rearranging it's layout, and you can also apply other methods, from other 
'household' objects to this object, like making the dishwasher object perform a 
wash on it, which might then affect another of it's own properties, but one 
which might also then be inherited from it's parent type of utensil - it's 
cleanliness property...?

(and, this was just off the top of my small/dilly/distracted brain right 
now...<smile>)

Jacob Kruger
Blind Biker
Skype: BlindZA
'...fate had broken his body, but not his spirit...'
----- Original Message -----
From: Homme, James<mailto:james.homme@xxxxxxxxxxxx>
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Sent: Wednesday, October 31, 2012 2:16 PM
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

Hi Jim C,
When you say that you see everything as an object, are you able to contrast 
that with seeing things in another way?

Thanks.

Jim


From: program-l-bounce@xxxxxxxxxxxxx<mailto:program-l-bounce@xxxxxxxxxxxxx> 
[mailto:program-l-bounce@xxxxxxxxxxxxx] On Behalf Of Corbett, James
Sent: Wednesday, October 31, 2012 8:01 AM
To: 'program-l@xxxxxxxxxxxxx'<mailto:'program-l@xxxxxxxxxxxxx'>
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

Jim H.

I think the difference between you and Jacob is the OO training that he 
apparently has. Speaking of my self as a Java programmer, I see everything as 
an object.

Jim C.


From: program-l-bounce@xxxxxxxxxxxxx<mailto:program-l-bounce@xxxxxxxxxxxxx> 
[mailto:program-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jacob Kruger
Sent: October 31, 2012 7:57 AM
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

I would see it as more of an object, with game state property, sort of array 
property with elements for each block, but then they'd also have child 
properties, like possible contained piece objects, which could have type 
properties, and then the board could also have things like move history listing 
property, etc., etc.?

FWIW, that's more of the approach I went for with my PHP rendered chess board 
app/object, etc. as well, but anyway.

And, with the ludo board game engine am currently trying to finish off in PHP, 
I then also implement things like output, getBoard() functions of the 
object/class which then spit out the rendered HTML content of the board, based 
on other properties, like paths to piece images, etc. etc., but anyway...

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
'...fate had broken his body, but not his spirit...'
----- Original Message -----
From: Homme, James<mailto:james.homme@xxxxxxxxxxxx>
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Sent: Wednesday, October 31, 2012 12:55 PM
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

Hi Jacob,
Right now, in my thinking process, I am seeing the chess board as a Python 
dictionary. I know that lots of times, it is a two dimensional array.

I think I'm just going to have to attempt to code it and learn from how it 
comes out.

Jim


From: program-l-bounce@xxxxxxxxxxxxx<mailto:program-l-bounce@xxxxxxxxxxxxx> 
[mailto:program-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jacob Kruger
Sent: Tuesday, October 30, 2012 10:20 PM
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

Well, simple example might be something like a chess board, since the object 
would store it's state in properties, and let you manipulate it's contents then 
via sort of internal methods, etc. etc.

My biggest example is my mapData project where there are various 
classes/objects relating to the board, the child objects that are locations, 
the other objects that are the main character, and the sort of NPC characters, 
etc. etc.

And, also, not really related to python, but, the thing am currently busy 
with/trying to finish off is where in PHP, I am also busy with a sort of game 
board object, but am using var_export and the __set_state method of a class 
object to then re-set it's state after something like a server round trip, 
after storing it in like a session variable, etc.

In other words, comes down to, from my side anyway, wrapping something like an 
object in a class wrapper, since generally when making use of an instance, you 
don't need to keep on manipulating all of it's internal aspects one at a time, 
if you can rather make use of it's own methods/function calls, etc. etc., but 
anyway.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
'...fate had broken his body, but not his spirit...'
----- Original Message -----
From: Homme, James<mailto:james.homme@xxxxxxxxxxxx>
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Sent: Tuesday, October 30, 2012 9:58 PM
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

Hi Jacob,
What makes you decide that you need to make an object?

Jim


From: program-l-bounce@xxxxxxxxxxxxx<mailto:program-l-bounce@xxxxxxxxxxxxx> 
[mailto:program-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jacob Kruger
Sent: Tuesday, October 30, 2012 3:39 PM
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Subject: [program-l] Re: Python: Please Help Me Think Out Loud About When To 
Make Classes And When Not To Make Them

I use classes for objects, but, for just data/content manipulation functions, I 
might collect them in a separate file/module depending on their type/context, 
but, not include them in a class as such, but anyway.

Stay well

Jacob Kruger
Blind Biker
Skype: BlindZA
'...fate had broken his body, but not his spirit...'
----- Original Message -----
From: Homme, James<mailto:james.homme@xxxxxxxxxxxx>
To: program-l@xxxxxxxxxxxxx<mailto:program-l@xxxxxxxxxxxxx>
Sent: Tuesday, October 30, 2012 8:25 PM
Subject: [program-l] Python: Please Help Me Think Out Loud About When To Make 
Classes And When Not To Make Them

Hi,
I think that my chess project is one in which it's OK to make the class that 
uses the cmd class, but is also OK to import a file that has chess related 
functions, but is not a class. If I'm wrong, please tell me. Here's how I view 
the project in my mind right now, and where it's going. But the big question in 
my mind is this. What makes you either decide to make classes or not make them?

I now have a file that I'm going to change so that it returns the results of 
the functions it calls from my chess board module. In order to make the 
functions in my command file see the ones I'm making in the chess board file, I 
put an import statement at the top. When I did this, my functions could call 
the ones in my chess board file.

I'm going to have functions like new game. I think that this makes it so that I 
don't need to instantiate a chess board class. I say this because of the way 
this whole thing is constructed. Every time
I type a command, it gets ready to receive a new one.  I'm keeping the help 
functions in my commands file, though. I'm not going to migrate them over, or 
put functions in the chess board file that return help text. I may have to 
change my mind, but this is how I see it working right now.

The only thing my commands file will do is start and run the command loop.

I'm hoping that once I learn how to make GUI programs, I can simply swap out my 
command line processing file and make the GUI file just use the functions in 
the chess board file. So, in stead of a command loop, it would make some sort 
of event loop or whatever that GUI thing is called that waits for you to click 
stuff and choose stuff.

So theoretically, I can put out a command line version of my program, and a GUI 
version of it.

But what concerns me is the question of whether I'm constructing it this way 
because I come from a procedural programming back ground and subconsciously 
want to avoid making classes, or whether this is the best way to construct the 
project.

It seems like a nice way to divide things up, though, so that it helps me think 
of each file having a set of functions. For example, maybe there would be a 
third file that does nothing but save and load game data from disk, assuming 
that I want to build in the capability to save and load games in progress, and 
I see no reason I wouldn't want to do that. Here again, though, I'm thinking 
that the chess board file would import the one that loads and saves the data. 
And I'm thinking that the file that does that may not need to contain a class 
that does this. I'm not that far in my thinking though.

Thanks for listening.

Jim

________________________________

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:

  1. Home
  2. program-l
  3. Archive
  4. 10-2012