Mitme objekti andmete kirjutamine: kuidas seda vältida
Teate neid aegu, kui töötate programmi kallal ja teie koodis on mõned kohad, mis olenevalt nõuetest või mingil moel ilmnevast veast on otseselt seotud sellega, et teil on andmeid kirjutamas mitu objekti. samasse andmesalve? See pole hea.
See on kohutav viis postituse alustamiseks. Las ma proovin seda uuesti.
Mitu objekti andmete kirjutamine
Oletame, et töötate programmi kallal ja üks asi, mida kood teeb, on mõnes andmebaasis oleva loenduri värskendamine, et jälgida, kui palju muudatusi on lühikese aja jooksul toimunud.
Probleem: teil on koodis mitu kohta, mis seda loendurit värskendavad.
Mitme objekti andmete kirjutamine (juhul, kui mu käekiri on nii loetamatu, kui paistab).
Ma arvan, et paljud meist ei kavatsegi sellist koodi kirjutada, kuid seda juhtub ja kui see juhtub, tekivad kõik need kõrvalmõjud, mis lihtsalt tekitavad igasuguseid tobedaid käitumisi. (Ma ei tea selle ametlikku akadeemilist terminit – ja ma ei pea silmas KUIVAT –, kuid mulle sobib selle postituse puhul „funky käitumine".)
Teame intuitiivselt, et meil peaks olema üks koht, kus see kõik toimub, välised tegurid – olgu see siis ulatus, meiepoolne arusaamatus nõuetest aru saada või mis iganes – tekitavad kehva kodeerimise.
Seega on meie süsteemis kõik need olemid, millest igaüks räägib meie andmebaasi ühe punktiga (või mis tahes andmesalvega, mis teile meeldib), kuid ükski neist ei tea, et teised nendega räägivad.
Seadke piirid
Võime proovida selle vastu võidelda tingimustingimuste ja millegi muuga, kuid me muudame asja ainult hullemaks. Mida me siis tegema peaksime?
Ma tean, et nagu paljude asjade puhul programmeerimises, on selle lahendamiseks mitmeid viise, kuid võib-olla on üks esimesi ümberkujundamiskäike andmesalve värskenduste väljastamise eest vastutav klass.
Nii saame ülaltoodud illustratsioonist minna millekski selliseks:
Mitme objekti andmete kirjutamine: saatke need omamoodi vahendajale.
See tähendab, et kõik olemid on selle objekti ja selle objektiga ühenduses – ja ainult see objekt saab andmeid lugeda ja andmebaasi kirjutada.
On mõned disainimustrid, mis sobiksid selle konkreetse probleemiga, kuid see ei kuulu selle postituse ulatusse. Selle asemel üritan öelda, et kui leiate end silmitsi järgmise probleemiga:
- Olemid kirjutavad andmeid andmesalve,
- Mitu üksust teevad seda,
- Ja see tekitab soovimatuid tagajärgi,
Seejärel proovige luua klass või klassikomplekt, mis vastutab rangelt andmete lugemise ja kirjutamise eest. Laske teabel läbida ainult need klassid, mitte lasta andmetega manipuleerida mitmel klassil.
See muudab testimise lihtsamaks, silumise ja lõppkokkuvõttes hõlbustab lugemist.