|
|||||||||
|
|||||||||
| |||||||||
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
 |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
Dev Shed Forums Sponsor:
|
 AT&T devCentral & BlackBerry(r) Webcast Series: BlackBerry and GPS -Build Location Awareness into your BlackBerry Applications, July 10th-1:00PM EST. Register Today!
|
|
#1
February 8th, 2004, 02:42 PM
|
|||
|
|||
Module Questions
I've these classes in different files.
File 1: class socketDriver(pC.parseCommand): File 2: class parseCommand(cM.chanManagement, aM.authManagement): File 3: class authManagement: File 4: class chanManagement: I import File 2 from File 1 because socketDriver needs pC. Now, my question is: why can't I just put the aM and cM imports into File 1 too? At the momment they're in File 2, because otherwise it doesn't work. Also, parseCommand and socketDriver use the 'sys' module. Why do I need to import it into both File 1 and File 2 if File 2 is being imported into File 1 (it's already in File 1). This module scope stuff is crazy. I hope I made sense...  Last edited by XxChris : February 8th, 2004 at 02:56 PM.
|
|
#3
February 8th, 2004, 04:19 PM
|
|||
|
|||
|
I have a class for socket stuff, chan management stuff and auth management stuff, should I use inheritence for to be able to use the methods from the other classes or create an instance of them and call it that way? I'm not sure when to use which.
|
|
#4
February 8th, 2004, 04:29 PM
|
||||
|
||||
|
XxChris,
A bit wordy but I hope this is helpful (appologies if this is sucking eggs to you)  . The problem is namespace, the structure of the namespace depends on the sequence of imports. To describe this I've used [] to indicate the namespaces for each module.Your working code ver A Code:
[File_1
[File_2
[File_3 ....]
[File_4 ....]
]
]
File 1 can see everything in 2,3 and 4 because they are within it's namespace. File 2 can see stuff in 3 and 4 but not in 1. From 1, references to objects in 3 and 4 would be via 2, like file_2.file_3.object and file_2.file_4.object How you want it ver B Code:
[File_1
[File_3 ....]
[File_4 ....]
[File_2 ....]
]
With ver B, as before, file 1 can see everything in 2,3 and 4. But this time file 2 cannot see stuff in 3 and 4 because it has no reference to them (it didn't import them). This means that file 2 cannot create objects that reference objects/classes defined in 3 or 4. You can do tricks like: Code:
#in file 1 import file_3 import file_4 import file_2 file_2.file_3 = file_3 file_2.file_4 = file_4 #this puts 3 and 4 in 2's namespace as well but this is IMO ugly  coding which will get you into trouble on bigger projects.One OO approach would be to keep your original structure and anytime file 1 needs to get file 3,4 stuff wrap it in a file 2 function.  This way if you ever re-use or ditsribute file_2 you don't have to remember what it depends on to drive the module and you only need to document file_2 functions and attributes.Grim
|
|
#5
February 8th, 2004, 04:32 PM
|
||||
|
||||
|
Like strike said, you should import whatever you need directly... i'm not sure excatly what you mean but whats the problem with importing what you need into each file?
If you really dont want to import the classes why not just put them all in one file? or get the same effect by using the from import format... Code:
from module import * Edit: or listen to Grim he seems to understand what you wanted.Mark. Last edited by netytan : February 8th, 2004 at 04:41 PM.
|
|
#6
February 8th, 2004, 04:41 PM
|
||||
|
||||
|
Guys,
It's personal preferences - of course - but a socket is a low level thing, a session might be considered to use a socket, authentication, and a channel so in my book I would consider wrapping all these things in session class. The authentication bit would be ideal as a mixin.my 2 cents! [is session the right term here?] Grim,
|
|
#8
February 8th, 2004, 04:57 PM
|
||||
|
||||
|
In a slightly off the wall moment :
Does anyone cook? A lot of receipe books have lots of sauce receipes. To save repetition they often they use a base sauce and add things to it. So the other sauce receipes often start like: 1. make your base sauce 2. add ingredient x and chill 3. cook slowly. You can see where i'm going with this 1 is a base class sauce, after step 2 you have a new class sauce inheriting all the attributes of the original sauce excpet it has now got an x attribute and a chill method. At step 3 when you cook it you have an instance of the new class sauce and you can actually eat it. 
|
|
#9
February 8th, 2004, 05:02 PM
|
||||
|
||||
|
The main difference between inheritance and an instance is that inherting from a class gives you a copy of that class which you can build on, alter and create instances of. Where an instance is exactly that, an instance of the class and can only be used, and not altered or built on.
Hope you got that , not the easiest thing in the world to explain.Have fun, Mark.
|
|
#10
February 8th, 2004, 05:15 PM
|
|||
|
|||
|
I understand that stuff, but I have classes that need a bit of functionality from eachother. Do I use inheritence so I can call those methods or do I do: myInstance = myClass() then call myInstance.method() from the classes which need it. At the moment some of the base classes need to use a method or two from derived classes and vice versa. Bah... OOP is confusing...
Last edited by XxChris : February 8th, 2004 at 05:23 PM.
|
|
#11
February 8th, 2004, 05:45 PM
|
||||
|
||||
|
If you inherit methods from a base class they are your methods too! You would not have to refer to the base class. (Except legitimately in functions like __init__ where the undelying base.__init__ is often called by the new classes __init__ method. Usually because it does things you cant see like allocate memory or does all you want but you wish to add a bit more to it ).
Inheritence means you get every thing from the parent, but if you wish you can change it. Code:
class myclass:
def do_authentication(self):
return TRUE #no authtication just okay everything
def print_welcome(self):
print "Hello ",
class my_new_class(myclass):
def do_authentication(self):
#do the real code
return result
def print_welcome(self,name="Sid"):
myclass.print_welcome(self)
print name
der new_function(self):
print "Doing something new that myclass can't"
old = myclass()
old.print_welcome()
#displays "Hello"
a = my_new_class()
a.print_welcome("fred")
# displays "Hello fred"
IMHO If you can't structure it this way then maybe you need to re-visit the design. OOP is about encapsulation of functionality that defines an object in that object. If that functionailty criss crosses between different objects then its a bit broken. Grim
|
|
#12
February 8th, 2004, 05:47 PM
|
|||
|
|||
|
Here is the code that I'm trying to split up into modules:
http://www.geocities.com/idontthinkalot/pybot.c It's a bit old than what I have now but the classes are the same. Last edited by XxChris : February 8th, 2004 at 06:07 PM.
|
|
#13
February 9th, 2004, 06:15 AM
|
||||
|
||||
|
Hi XxChris,
IMO nothing wrong with your code but if you are looking for suggestions: Your socketDriver is inheriting all the other classes but creates the socket object that those classes use. This suggests that the socket is a fundamental attribute and would be better defined in a base class. So I recommend you make socketDriver the base class. This is a matter of personal taste but when deciding if stuff should be in a class at all it's useful for me to think about what it is I want. For example your class parseCommand is "doing something" and not "being something" so parseCommand.parseInput, parseCommand.mapCommand could just as easily be defined as individual support functions. These are then passed the self.sock as a parameter. In your code, authManagement calls self.sock.send directly. If you were to add a send method to socketDriver then authManagement could call self.send without knowing it has an underlying socket. This encapsulates the socket in the socketDriver class so next time you want to change your code to support wet-string protocol instead of TCP/IP you only change the code for the one send method and as a bonus authManagement becomes more reusable/general. The same for chanManagement. auth/chan become "mixin" type classses. If you keep parseCommand as a class then: Code:
#perhaps something like this..
class socketDriver:
def __init__(self):
self.socket etc
.....
def connect(self):
....
def send(self,data):
....
def receive(self):
.....
return data
class authManagement:
......
class chanManagement:
......
class parseCommand(socketDriver, authManagement, chanManagement):
def mapCommand(self....
.....
def parseInput(self...
.....
def getdata(self):
input = self.receive()
if input.startswith('PING'):
self.send('PONG : PING\n\r')
print 'PONG has been sent.'
elif input:
self.parseInput(input)
myBot = parseCommand()
myBot.connect()
while True:
myBot.getData()
I find choosing a name for a class often the most difficult bit! Thats because I know if I choose a good name it helps me write the code. Why not rename parseCommand as pyBot? No offence intended - I found your code very readable and clear and would not have been able to comment otherwise. Grim.
|
|
#14
February 9th, 2004, 06:21 AM
|
||||
|
||||
|
and the modules bit:
in pybot from socketDriver import * from chanManagement import * from authManagement import * But personally I don't like using * as I don't know if different modules have used the same names.
|
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
