Patrone vir die oorvleueling van twee voorwerpe

Question

Ek is seker dit is reeds gevra en beantwoord so ek vra om verskoning by voorbaat vir dit nie, maar ek is nie uitzoeken die korrekte sleutelwoorde te soek. Op soek na 'Patroon "treffers te veel Q & A's te nuttig wees.

Ek is besig met 'n regressie toets app. Ek is vertoon 'n vorm op die skerm en waarvolgens gebruiker is aangeteken in die app 'n paar van die velde moet lees-alleen. So ek kan abstrakte n veld doel en ek kan abstrakte n gebruiker voorwerp maar wat patroon moet ek kyk na die kruising van hierdie twee konsepte te beskryf? Met ander woorde hoe moet ek beskryf net-lees wat vir Field 1 en Gebruiker A, moet die veld word? Dit lyk asof read-only (of nie) 'n eiendom van die Field klas moet wees, maar soos ek gesê het, dit hang af van wat die gebruiker is op soek na die vorm. Ek het 'n eenvoudige twee-dimensionele skikking (e. G. ReadOnly [Field, gebruiker] = true) beskou, maar ek wil om seker te maak ek het opgetel die mees doeltreffende struktuur om hierdie verteenwoordig.

Is daar enige sagteware ontwerp patrone met betrekking tot hierdie soort van data struktuur? Ek overcomplicating dinge - sou 'n twee-dimensionele skikking wees die beste manier om hier te gaan? Soos ek gesê het as dit gevra en beantwoord, kan ek vra om verskoning. Ek het soek hier en het niks te vind en 'n Google-soektog versuim het om óf opdaag enigiets.

Answer 1

Table gedrewe ontwerpe kan effektief wees. Steve Maguire het paar mooi voorbeelde in Skryf Solid Kode .

Dit is ook 'n goeie manier om toetse te vang, sien pas .

In jou geval iets soos:

Field1ReadonlyRules = {
    'user class 1' : True,
    'user class 2' : False
}

field1.readOnly = Field1ReadonlyRules[ someUser.userClass ]

As 'n eenkant waarskynlik wil hê jy moet 'n model beide gebruikers en gebruikers klasse / rolle / groepe in plaas van hulle te kombineer. 'N gebruiker vang gewoonlik wat (verifikasie) terwyl groepe / rolle vang wat (permissions, vermoëns)

Answer 2

Met die eerste bloos klink dit meer soos jy twee verskillende tipes gebruikers en hulle het verskillende toegang vlakke. Dit kan opgelos word deur die erfenis (PowerUser, gebruiker), of deur met 'n sekuriteit voorwerp of teken dat die vlak van die gebruiker stel.

As jy nie daarvan hou erfenis as 'n reël, jy kan 'n staat patroon gebruik op die aansoek, versier die gebruiker voorwerpe (sidder) of dalk voeg strategie patrone vir verskillende sekuriteit vlakke. Maar ek dink dit is 'n bietjie nog vroeg, ek weet nie normaalweg patrone van toepassing totdat ek het 'n ferm idee van hoe die item sal gegroei en in stand gehou word.