A Smalltalk programozási nyelv

A Smalltalk-programok stílusa, konvenciók

Bevezetés

A jó programozási stílus akármelyik nyelvben segíti a forráskód olvashatóságát, érthetőségét és egyértelműségét, ezért a legtöbb nyelvnek kialakult a maga stílusa. Mivel a Smalltalk nem követője sem a Pascal, sem a C-féle vonulatnak, így saját konvenciói vannak. Persze a rossz és a jó stílusnak is vannak nyelvtől független ismérvei, - mint például a globális változók, - ezeket itt érintőlegesen tárgyaljuk, de inkább a Smalltalk-specifikus konvenciókra helyezzük a hangsúlyt.

Változókkal kapcsolatos konvenciók

A Smalltalk nyelvben a rövid változónevek nem használtak, helyettük a nevek két csoportját különítjük el. Az úgynevezett szemantikus változók nevei a jelentésére utalnak, míg a típusos nevek értelemszerűen a típusára. Hogy a két stílus közül melyiket alkalmazzuk, az a felhasználástól függ. Például az objektum- és osztályszintű változók elsősorban a szemantikus elnevezést követik, a metódusok paraméterei pedig jellemzően a típusosat.

A szemantikus jellegű változók a megértést segítik, ami fontos lehet az öröklődésnél, elvégre egy, az ősosztályban (akár sokadik ős) definiált változó és a származtatott osztályban való felhasználása igen "messze" kerülhet egymástól. Néhány példa ezekre:

score
currentWorkingMemory
TotalPopulationSize

A típusos megközelítés metódusok paramétereinél gyakori, mivel így egyszerűbb a típusuk meghatározása, például:

add: anObject ifAbsent: aBlock
at: anIndex put: anObject

Metódusokban a lokális, temporális változók gyakran vegyes, mindkét konvenciót követő neveket alkalmaznak.

Ha egy változó neve több szóból áll, nem szerencsés '_' vagy '-' karakterekkel elválasztani, inkább az új szavak első betűit kell kiemelni, például:

thaDateToday
employeeRecord
objectInList
Az, hogy a legelső betű kicsi, avagy nagy, az a helyzettől függ, ezeket az eseteket a következő táblázatban foglaljuk össze:

Változó típusa Első betű
Globális változó Nagy
Osztályváltozó Nagy
Osztálynév Nagy
Osztott változó Nagy
Átmeneti változó Kicsi
Osztály előfordulási változó Kicsi
Előfordulási változó Kicsi
Metódus paraméter Kicsi

A Smalltalkban alapértelmezésben egy objektum, vagy egy osztály minden adattagja védett, általában mégis célszerűbb és szebb az attribútumok elérése úgynevezett accessor metódusok segítségével. Kívülről persze csak így lehetséges hivatkozni az adattagokra, de az objektum metódusaiban is ajánlatos ezt követni. Ezt a stílust nevezik változómentes programozásnak. A módszer előnyei egyértelműek: nem lehet ellenőrizetlenül módosítani a belső állapotot, amely esetlegesen a típusinvariánst is elronthatja.

Osztályokkal kapcsolatos konvenciók

Az osztály elnevezése minden objektum-orientált nyelvben kulcsfontosságú kérdés, a kód olvashatósága nagyban függ attól, hogy az osztályok nevei mennyire kifejezőek. A Smalltalk egyértelműen támogatja ezt, illetve a nagy kezdőbetűt ajánlja az osztályok neveihez, például:

Collection
GraphicalClassBrowser
EmployeePensionPaymentsHistory
Természetesen ennek is van határa, például egy gyakran használt osztály nevét nem célszerű túlbonyolítani.

Az OOP és az öröklődés alapvető tervezési elveit itt nem említjük, viszont egy nagyon egyszerű módszert ismertetünk arra, hogy kiderítsük, mikor érdemes egy meglévő osztályt több kisebbre osztani.

  1. Figyeljük meg az osztályhoz írt kommenteket! Amennyiben nincs, az már nem jelent jót.
    • A komment rövid és érthető? Ha nem, akkor tördeljük szét kisebb részekre - ezek mentén célszerű magát a kódot is feldarabolni, külön osztályokba, metódusokba szervezni.
    • Ha az előző pontot kielégítik a megjegyzések, győződjünk meg róla, hogy a változók jelentése összhangban van a kommentekben leírtakkal! Ha nem, biztosan módosításra lesz szükség.
    • Az előző két pontot ismételjük addig, ameddig a kívánalmaknak meg nem felel a kódunk
  2. Keressük meg az osztály metódusait felhasználó kódrészleteket, és ellenőrizzük, hogy a használat összhangban van-e a megjegyzésekben leírtakkal! Ha nem, ismételjük a korábbiakat!

A Smalltalk-szabvány szerinti rendszerosztályok módosítására is van lehetőség, viszont ez nem ajánlott, elvégre csökkentheti programunk megbízhatóságát, és hordozhatóságát. Emellett néha ténylegesen hasznos és szükséges, hogy kibővítsük a rendszerosztályokat, az viszont ökölszabály, hogy a már meglévő metódusokat ne módosítsuk, elvégre a Smalltalk igen összetett osztályhierarchiával rendelkezik, ezért nem tudhatjuk, pontosan mely osztályokban fejti ki hatását a módosítás. Ha mégis csillapíthatatlan vágyat érzünk erre, célszerűbb inkább egy osztályt származtatni a kiszemeltből, és azt alakítani.

Az mindig elvárható, hogy az általunk definiált osztályokhoz fűzzünk kellő mennyiségű megjegyzést, mely elsőszámú dokumentációként funkcionál. A későbbi újrafelhasználásoknál sokat tud segíteni, ezért célszerű tartalmaznia a következő információkat: szerző neve és elérhetősége, módosítások története és természetesen az osztály célja, feladata.

Bizonyos helyzetekben szükséges, hogy egy osztálynak egyetlen (singleton) példányát hozzuk létre, és erre hivatkozhassunk, ahonnan csak szükséges. Felvetődik a kérdés, hogy mi a szebb megoldás, egyszeri objektumot létrehozni, vagy osztály szintű metódusokat definiálni, és azokra hivatkozni. A következő szempontok miatt ajánlatos az utóbbi megközelítés elkerülése:

Metódusokkal kapcsolatos konvenciók

Metódusok neveivel kapcsolatban elvárás, hogy kezdődjenek kisbetűvel, illetve ha több szóból áll, akkor a szavak első betűje legyen nagy - kivéve természetesen a legelsőt. Két egyszerű példa erre:

account deposit: 100.
account printStatement.

Ha a metódus egy kulcsszavas üzenet több paraméterrel, akkor a kulcsszavak mindegyikére a metódusneveknél leírt forma az ajánlott. Például:
Dialog request: 'Name' initialAnswer: 'John' onCancel: [Transcript show: 'Error'].

A logikai (true vagy false) visszatérési értékű metódusoknál a név első része legyen egy ige, mint például az is vagy a has. Néhány példa:
isString
isActive
hasFood

Az öröklődési hierarchiában célszerű a metódusokat a lehető legmagasabb szinten elhelyezni, ahol még értelmesek. Átgondolandó szempontok ezen a téren: