Hobby Programming
Posted on February 17, 2007
Filed Under Programming, Saturday Satire |
As some readers may know, I have taken up Python programming as a hobby. I was once a world champion underwater Logo programmer, but I thought it would be nice to move on to a slightly more modern language. Before I go on, I should mention that I was once heralded as the Muten-Roshi of Logo programming due to my incredible skill with "turtle graphics" (a very useful skill).
If you have followed along so far and have no questions, please skip the rest of my post and visit this site.
For the rest of us, here is the class I just invented in my pre-entry level attempt at Python:
class Ship(object):
'contains the attributes of the player or npc ship'
def _init_(self, captain, hullLife, crewNumber, crewEquipment, crewArmor, crewMoral, hullType, shield, weapon, core, lifeSupport, gravity, navigation, drive, boost, inertia, reverseThrust, stability):
self.captain = captain # ship and captain
self.hullLife = hullLife
self.crewNumber = crewNumber # crew data
self.crewEquipment = crewEquipment
self.crewArmor = crewArmor
self.crewMoral = crewMoral
self.hullType = hullType #defesive/offensive systems
self.shield = shield
self.weapon = weapon
self.core = core # support systems
self.lifeSupport = lifeSupport
self.gravity = gravity
self.navigation = navigation
self.drive = drive # inertia systems
self.inertia = inertia
self.reverseThrust = reverseThrust
self.stability = stability
def captainUpdate(self, newCaptain):
self.captain = newCaptain
def hullLifeUpdate(self, newHullLife):
self.hullLife = newhullLife
def crewNumberUpdate(self, newCrewNumber):
self.crewNumber = newCrewNumber
def crewStatUpdate(self, newCrewEquipment, newCrewArmor, newCrewMoral):
self.crewEquipment = newCrewEquipment
self.crewArmor = newCrewArmor
self.crewMoral = newCrewMoral
def attackDefenseUpdate(self, newHullType, newShield, newWeapon):
self.hullType = newHullType
self.shield = newShield
self.weapon = newWeapon
def supportUpdate(self, newCore, newLifeSupport, newGravity, newNavigation):
self.core = newCore
self.lifeSuport = newLifeSupport
self.gravity = newGravity
self.navigation = newNavigation
def inertiaUpdate(self, newDrive, newInertia, newReverseThrust, newStability):
self.drive = newDrive
self.inertia = newInertia
self.ReverseThrust = newReverseThrust
self.stability = newStability
As you can see, the intent is to build a basic object for a space game. This particular space game may have typographical errors and misconceptions at this point, and was inspired by spaghetti and cheese (this is what happens when there is not enough ravioli in the house), but these are not the most relevant issues.
Since I mentioned Logo programming, which is actually (apparently) useful as a tool for constructivist learning, I thought I would expose my own (mis)conceptions to the world and hope that the experience of other programmers might accelerate my construction of Python "knowledge."
My own first issue with this class is that there are too many values being passed into the constructor at instantiation. At least I think so. Is this normal, or should I be organizing my classes differently? Second, I defaulted to breaking my methods into chunks. I have no idea, yet, how well this will work when I start calling these methods. For example, if the crew's equipment and armor are upgraded, but the crew moral is unchanged, I will still have to "update" all three because of the way I structured my class, will I not? Early in the program, this would not be much of an issue, but later is seems like it could make a difference. If I decided to rewrite after defining a kabillion classes and a quasitrillion functions, I think I would have issues.
It would be interesting to see what Gregory thinks about this. Not everyone knows this, but Gregory is one of the better Python programmers in existence. I know this because I am a career idea map and have worked with him professionally. If you want to see real programming, work with Gregory and be amazed; or, if that is not an option, I recommend reading his weblog.
WHAT IS PYTHON?
-JAN
see http://www.python.org
They can explain it better than I can.
Wow, that *is* quite a constructor.
You don’t really need to allow all your class’s fields to be populated via the constructor. All of those fields/properties/whatever they are called are public as python doesn’t really have a concept of private variables.
You can precede methods and fields with underscores to “hide” them, and it is a good practice to do so when you intend them to be hidden for encapsulation reasons. However if you haven’t, then you can access them via the dot operator from your class instance.
It may be ideal for a game to just allow for that. Later on, you can wrap them in properties as you find things you need to do when they are set. If you name the property the same as the field and just rename the field, that will keep your class’s interface intact and limit the amount of code you need to change.
[...] am I bringing this up? One reason is due to watching my friend Rab having fun with Python. He’s having fun. He’s doing it for fun, and thus he’s having fun. Doesn’t [...]