Hallo,
Thomas Devriendt wrote:
> Hallo,
>
> Het is inderdaad zo dat MasterClass een object UserData aanmaakt, en daar
> bewerkingen mee uitvoert.
Dit lees ik als
class MasterClass:
def __init__(self):
self.udata = UserData()
def doit():
# doe dingen met self.udata
>
> Wat ik wel niet goed versta is dit:
>
>
>>Als je die naam namelijk hard-coded in MasterClass hebt zitten kun je
>
>
>>nooit meer een ander data base object gebruiken in je MasterClass,
>
>
>>want dan moet je eerst de source van MasterClass aanpassen.
>
>
> Ik maak helemaal in het begin van MasterClass zulk een object aan, en wijs
> dat toe aan een member-variabele van masterClass. Op deze mannier kan ik
> toch eenvoudig van database object wisselen, of versta ik u verkeerd?
Voetnoot: je mag wel tutoyeren, al is dat wellicht een typisch nederlandse
gewoonte?
Hoe wou je dat doen zonder source code wijziging?
Je moet dan op zijn minst masterclass.py wijzigen met de nieuwe naam.
Bovenstaande lees ik als " 'MasterClass' heeft specifiek 'UserData' class
nodig, die laatstgenoemde class is dus onderdeel van MasterClass.".
Dat is anders dan "MasterClass heeft _een_ (ie *any*) class nodig die database
access voor hem doet". Met andere woorden, het maakt MasterClass niet uit waar
die userdata vandaan komt, hij heeft een object die dat regelt.
In dat laatste geval wil je niet dat MasterClass de naam van het UserData
object weet.
Ik los dat vaak op met
class MasterClass:
def __init__(self,udata):
self.udata = udata
etc
Nu krijgt de MasterClass een UserData object (of eigenlijk, een object wat
zich (hopelijk) gedraagt als een UserData object. MasterClass weet nu niet wat
hij krijgt (als in "dat is voor hem niet van belang, zolang het zich maar
houdt aan de interface definitie die MasterClass veracht.").
Omdat nu de classdefinitie van UserData niet gebruikt wordt, hoeft die ook
niet ge-importeert te worden.
> Je bedoelt dat ik de member-function van UserData zonder de class te
> initiëren kan aanroepen?
>
> Vb:
>
> userdata = userData().getUserInfo()
Hier maak je wel degelijk een UserData object aan, namelijk vlak voor de
aanroep naar getUserInfo(). Vlak na de assignment gooi je dan het object weer
weg.
Je kunt in new-style classes wel zg class-methods gebruiken (in C++ zijn dat
static methods (geloof dat ze in Java ook zo heten)). Class methods zijn in
Python afaik de enige manier om methods aan te roepen zonder een object te
construeren.
> Qua printen heb je zeker gelijk. Maar ik vind het gewoon te onoverzichtelijk
> om alles, onderverdeeld in "hoofdstukken", in dezelfde file te zetten. Maar
> dit is misschien vanwege mijn ervaring in php: daar werd elke keer als je de
> class aanriep het hele bestand geladen, en voor de bandwijdte was dit vrij
> lastig, daarom splitste ik zoveel als ik kon.
Je bedoelt waarschijnlijk 'responsie snelheid' ipv 'bandbreedte'.
Ik weet niet of dat ook gedaan zou hebben, ik heb een hekel aan beperkingen
die een broken implementatie mij opleggen. Waarschijnlijk zou ik wat scripts
in elkaar geflanst hebben die als post-processing stap mijn sources uit elkaar
trekken naar iets wat snel gedraaid kan worden.
(maar goed, mijn vak is compilatie en code-generatie, dus ik doe dat soort
dingen bijna dagelijks).
Als je meer code in 1 file stop kost inderdaad wat extra moeite om subdelen in
de file uit elkaar te houden. Ik gebruik daar regels commentaar voor als bijv
#
# =====================================================================
# USER INFORMATIE
#
wat zelfs als je page-up/down scrolled door de editor nog opvalt.
Wat ook erg goed werkt is is een blok docstring, al ben ik daar zelf niet zo'n
voorstander van, het breekt de code zo als je de weg weet in de files
(maar dat is ongetwijfeld een gebrek mijnerzijds, en deze mening zal op de
mailing-lijst niet gedeeld worden :-) ).
> In Java doe ik het ook zoals ik zei, gewoonweg om overzicht te houden.
Java vindt dat ook een goede gewoonte afaik (ik heb ongeveer 2 Java
programmaatjes geschreven tot nu toe (elk van < 30 regels), dus erg veel
zinnigs kan ik er niet over zeggen).
> PS: staat het oorspronkelijke bericht hier nu?
Ja, dat gaat allemaal goed.
Wat beter zou zijn is dat mijn posts niet bouncen natuurlijk.
Via mail melden dat er wat mis gaat is alleen wat moeilijk als alle admin
adressen ook op python.org zitten... :-(
Albert
_______________________________________________
Python-nl mailing list
Python-nl@python.org
http://mail.python.org/mailman/listinfo/python-nl
