Skip to content

Tell, don´t ask

Miért?
Az erős összetartás (cohesion) és a laza csatolás (loose coupling) erények. Osztályok nyilvános állapotrészletei ellentmondanak ennek.

Egy kicsit provokatívan megfogalmazva: az osztályoknak ne legyen property getter-e. Ezek egy osztály felhasználóit arra csábítják, hogy egy objektum értékei alapján döntéseket hozzanak. Ahelyett tehát, hogy az objektumnak megmondanánk, hogy mit tegyen, kikérdezzük, és kívülről az objektum belső állapotára vonatkozó megállapításokat hozunk.Az objektumorientált programozás egyik alapelve az Information Hiding (lásd még a sárga fokozaton). Az osztályoknak nem volna szabad olyan információkat mutatni magukról, amiből kiderül, hogy hogyan implementálták őket. Amennyiben egy osztálynak a munkájához szüksége van egy belső állapotra, akkor ezt általában egy belső mezőben tároljuk. Ha ez az érték kifelé is látható, akkor az osztály felhasználóit arra csábítjuk, hogy az objektumnak ezt a tulajdonképpen belső állapotát saját döntéseikre használják. Ezáltal az osztályt gyorsan lefokozzuk a tiszta adattárolásra. Mindenképpen előnyben kell részesíteni egy olyan implementálást, melyben az objektummal közüljük, hogy mit tegyen. Ezáltal az osztály felhasználóját már nem kell érdekelje az, hogy az osztály hogyan fogja a feladatot belül elintézni.

A Tell don’t ask-elv eredményeként viselkedéssel rendelkező objektumok jönnek „buta” adattároló objektumok helyett. Az objektumok összjátéka lazán csatolt, mivel az objektumoknak nem kell feltételezésekbe bocsátkozniuk az együttműködő objektumokról. De nem csak ennyi! Ha az objektumok nem hozzák nyilvánosságra az állapotukat, akkor megtartják a döntéshozatali fennhatóságukat. Ezzel erősödik a döntő kód összetartása (cohesion), mert egy helyre koncentrálódik.

Published inElvek