En tiedä asiasta koodin tasolla, mutta jotenkin tuntuu että tässä mahdollisesti oiotaan miettimättä tietomallia. Itse miettisin tätä objektitasolla ja sitä mitä oikeasti tapahtuu. Oheisena esimerkki objektimalliajattelusta ja käyttäen yhtä yhteistä tietoa käyttäjille.
Mitkä ovat objektiluokat asiassa? Tässä esimerkissä ihminen ja kuntosali. Näiden miettiminen on aivan oleellista.
Mitkä ovat objektiluokan interfacet ja niihin kuuluvat attribuutit? Jälkimmäinen on aika selkeä, mutta interfacet eivät. Tässä esimerkissä on ihmisellä kaksi interfacea: nimitiedot ja kuntosalin jäsenyys. Kuntosalissa on kolme interfacea: nimi/identifikaatio, osoitetiedot, jäsen.
Ihmisen jäsenyyden ja kuntosalin jäsen interfacien välillä on relaatio (relationship). Ei siis itse objektien vaan näiden interfacejen. Tämän avulla nämä kaksi asiaa linkkaantuvat. (Koska relationship on interfacellä, niin hetkeksi kuvitellulla kolmannella objektilla, joka voisi olla vaikkapa yritys, on myös automaattisesti sama relationship jos sillä on sama interface eli automaattisesti myös yritys olisi kuntosalin jäsen).
Nyt sinun tapauksessasi on metodi, jolla jäsenyys tehdään. Käyttäjä A ja käyttäjä B voivat siis näin tehdä, koska käyttävät järjestelmää ihmisinä.
Nyt mennään sitten toiminnallisuuteesi:
Käyttäjällä A voi myös olla metodi, että kun kuntosali linkataan, niin hänen ruudulleen, jäsenyys interfacen attribuutti, jäsenten lukumäärä päivittyy. Tämä metodi käynnistetään muulloinkin, jolloin tämä tieto pysyy ajantasalla käyttäjän A ruudulla.
Vastaava tapahtuu käyttäjälle B, joka saa lukumäärän 2, jos heillä on sama kuntosali.
Eli siis tässä oli esimerkki miten toisen käyttäjän syöte vaikuttaa siihen mitä näkyy toisella, ilman että he suoranaisesti vaikuttavat toisen käyttäjän tekemisiin tai tietävät toisistaan
Seuraava toiminnallisuus:
Käyttäjät A ja B ovat myös superkäyttäjiä, joille on voimassa metodi, päivitä kuntosalin osoite. Näinhän ei voi olla, että molemmat päivittävät eri osoitteen ja päivitys jatkuu hamaan ikuisuuteen, kun kumpikaan ei ole tyytyväinen. Sen lisäksi, pitää olla lukitus, jotta yksi kerrallaan voi tehdä tämän. Tässä siis pitää olla jokin triggeri, joka huomaa edellä mainitun kierteen. Tällöin voi myös olla oma kenttänsä käyttöliittymässä, joka värjäytyy punaiseksi esim. jos: "käyttäjä A on päivittänyt kentän mutta joku muu päivittää sen 24 h:n kuluessa uudestaan" - tai mitä nyt sitten haluatkaan että tapahtuu, jos yhteisen attribuutin päivitys lähestyy järjetöntä. Tässä mielessä yhteisten tietojen päivitys, tietämättä tarkalleen kuka on mukana ja mitä tekee, on aika ongelmallista yleisessä tapauksessa - sinun pitää miettiä jokainen erityinen tapaus erikseen.
Jokaisen attribuutin arvon muutos, siis pitää erikseen miettiä, että mikä on sen suhde, relationship, datamallissa ja mitä metodeja objektiin kuuluu ja milloin näitä metodeja laukaistaan tai miten niitä käytetään.
Yhtenä mössönä näitä kaikkia eri asioita ei voi miettiä - ei ainakaan 100:n käyttäjän järjestelmässä jossa on paljon attribuutteja.
En tiedä onko tästä apua, mutta objektimalli on sikäli mukava, että se kuvastaa todellisuutta melko hyvin. Hierarkinen malli ei kuvasta todellisuutta, mutta kuvastaa toki valittua järjestelmää, joka on ihan hyvä jos mitään muuta ei ole tarpeen valita esim. myöhemmin. Objektimallien kuvaamiseen löytyy toki työkaluja ja implementointiin ohjelmointikieliä. Edellinen kuvaus koski Microsoftin käyttämää objektimallia. Joku muu kertokoon parhaat, avoimet vastineet .ux -maailmassa.
Voihan tuon ylläolevan toki toteuttaa ihan funktionaalisella ohjelmoinnillakin - mitä luultavasti ajat takaa. Vastaavat asiat pitää miettiä siinäkin.