Har nu lagt upp ett till Designmönster på min blog, En liten artikel som handlar om Desription pattern. Ta er en titt, kom gärna med frågor eller synpunkter.

http://www.nsquared2.net/johan/viewpost.aspx?PostID=35

Mvh Johan

"When do you need to describe all the characteristics? Most of the answers will be at the User Interface."

Om du bara behöver informationen i UI så hör den inte hemma i klassen Person (som jag förutsätter finns i mellanlagret).

Din Description klass liknar mest nån generell slaskhink där all möjlig extra info kan slängas in. Lite som Winforms kontrollernas Tag egenskap, fast om möjligt ännu värre. Att du dessutom ärver från HybridDictionary och därmed avstår från stark typning gör inte saken bättre.


MS

MS:

Det Johan pratar om handlar om Object Thinking. Tex om jag ska ge ett mer komplext exempel än person så har du tex en produkt som förser dig med en förklaring över produkten. Om allt är ett objekt så skulle du få ett Description objekt som håller förklaringen kring tex en produkt. HubridDictionary i detta fall anser jag inte vara fel att använda. Men dock så gillar jag inte alls att använda ett Description eftersom det inte är hårt typat och alla "egenskaper (nycklar)" måste dokumenteras eftersom de inte finns som egenskaper på klassen. Du kan läsa om detta i Object Thinking ISBN: 0735619654 på sidan 125.

En fråga av ren nyfikenhet:

>(som jag förutsätter finns i mellanlagret).

Vad har mellanlagret med ett "entity" objekt att göra? Ett "entity" objekt som Person är i Johans exempel hör hemma i sort sett överallt, speciellt i en domain-model och även i en fler skiktad lösning.


/Fredrik Nromén NSQUARED2
http://normen.mine.nu/myblog

Vet inte om det var johans exempel eller ej, men jag är nog benägen att hålla med Mattias om att det verkar inte vara en så elegant ersättare som det vill beskrivas som. Ett par av mina funderingar, efter att bara ha skummat igenom materialt, är

* Man går totalt miste om all input validation. Ögonfärg skulle t.ex bara kunna sättas till en giltig medlem av EyeColor enum och valideras i set-accessorn med Enum.IsDefined som evt kastar ett InvalidEnumArgumentException. Samma sak gäller för ålder, som skulle kunna bekränsas till ett vist intervall, födelsedatum som skulle behöva validera formatet eller andra texter som måste begränsas i längd för att kunna sparas ner i t.ex en databas.

* Johan säger att man oftast vill åt dessa egenskaper i användargränssnittet och ok det är väl så men det betyder inte att man kan slaska ut dem rakt upp och ner, oformaterat och i godtycklig ordning. T.ex kanske man skall skriva ut information om all personal på ett företag (som representeras av ett Person / Employee objekt) och då vill an fylla i en viss mall... kanske en repeater.. då kommer du ändå få "trixa" för att få rätt på det. Så ser jag nog hellre att jag har typade, validerade properties (business rules) som jag explicit kan anropa från en DataBinder, code-behind metod eller t.ex från ItemDataBound callbacken för att fylla i presentationsinformationen i mitt UI.


<b>PS.</b> Med risk för att få "det var inget bra exempel" så visst kan jag köpa det ,men då kommer det med en uppmaning att tänka igenom de exempel i innehållet lite innan det publiceras. Ni är juh tvillingbröder så det är juh som att ha en medfödd granskare :-)

Andreas:

Som jag nämde i mitt svar på Mattias inlägg så beksriver Johan en del ur Object Thinking där allt är ett objekt (Vilket Johan borde kanske ha nämt). Tex du om du ser på en person så ser du inte bara vilken färg han har på ögonen utan vad han har för hårfärg mm. Du ser en "Description" av personen. Denna Description är ett objekt enligt Object Thinkers. Alla personer har inte samma "description" vissa har ett ärr, andra har en for stärre än den andre etc. Om en Person skulle beskriva sig själv så skulle det innebära en massa sub klasser för varje person som har något en annan inte har, men med hjälp av ett Description objekt så håller du dig till objektet Person men du får ut olika egenskaper för olika personer. Johan nämner även att han själv använder sig inte av detta "description" mönster i sin text.

När det gäller att gå igenom varandras inlägg så finns det många saker som gör att vi inte gör det, mest beror det på tid andra saker är mer personliga. Har du någon gång hört att tvillingar håller sams jämt? ;)

Fredrik:

Så i princip glömmer Object Thinkers allt vad typade properties etc är? Eftersom i princip allt skulle kunna falla in under en beskrivning för något. Ta en produkt, då kan man säga att gällande momssats, förpackningstyp, pris, tillverkningsdatum mm beskriver produkten? Och som en följd av detta så finns det väl inte direkt någon mening med att ha typade objekt, bara en gemensam klass där man kan fylla på beskrvningar och kanske ange vad det är med ett enum värde

public enum ObjectType
{
  Product = 1,
  Person = 2,
  Car = 3
}

public class ObjectThinkersObject
{
   ...

   public ObjectThinkersObject(ObjectType type)
   {
      ...
   }

   public Description Description
   {
      get { ... }
   }
}

Andreas:

I princip anser jag att du har rätt. Men David West menar på att egenskaper som identifierar ett objekt ska finnas kvar så som tex personummer för en person, artikelnummer för en artikel mm.

David West nämner att ett objekt beskriver sig själv och eftersom det kan beskriva sig själv på så många olika sätt med olika egenskaper (se om ärr etc i föregående inägg) så är ett Description objekt ett sätt att göra det på.

>Och som en följd av detta så finns det väl inte direkt någon mening med att ha typade objekt, bara en >gemensam klass där man kan fylla på beskrvningar och kanske ange vad det är med ett enum värde

Det skulle iofs fungera men dock så har alla objekt olika "behaviors" så som gå, prata etc. De är ofta unika för alla typer av objekt.

När jag läste om Description objektet i Object Thinking så höll jag inte med honom, det va fult sätt att designa ett objekt på. Skulle det finnas ett objekt, låt oss säga Person och olika personer skulle skilja sig ifrån varandra, då skulle jag ha utöver vanliga fasta egenskaper som ögonfärg etc ha med en egenskap som ger mig ett Description objekt. I den produkt jag är med och utvecklar har vi en property som heter "Properties" den använda för att andra kan lägga till egenskaper på alla olika typer av objekt. Tex vi har definierat en Användare med de egenskaper vi tycker en användare har. Men våra kunder vill ofta ha fler egenskaper och olika kunder vill ha olika för en Användare. Om du har ssett i AD så kan du bygga ut profiler för en användare, på samma sätt kan du göra det i vårt system fast för alla typer av objekt. Så vi valde att bygga ut våra objekt så kunderna kan själva lägga på egna värden som beskriver ett objekt utöver de fasta egenskaper vi anser att objektet ska ha.

/Fredrik Normén NSQAURED2
http://normen.mine.nu/myblog

Fredrik,

<b>I princip anser jag att du har rätt. Men David West menar på att egenskaper som identifierar ett objekt ska finnas kvar så som tex personummer för en person, artikelnummer för en artikel mm.</b>

Vilket betyder att alla unika egenskaper (om vi drar en parallell med databaser så blir det primärnycklar, sekundärnycklar etc) skall enligt Object Thinking finnas kvar som typade properties med business rules.

Hur förhåller detta sig till att en viss kombination (öka antalet beskrivande attribut leder till större filtrering) av beskrivningar (t.ex blå ögon, vikt 90kg, ärr på vänster kind) kan unikt identifiera ett givet objekt? Dock lämnar detta utrymme för att det skulle bli så att alla kombinationer av beskrivande egenskaper inte returnerar ett unikt objekt.

<b>I den produkt jag är med och utvecklar har vi en property som heter "Properties" den använda för att andra kan lägga till egenskaper på alla olika typer av objekt.</b>

Har varit med och utvecklat en produkt med samma typ av lösning och om detta är Object Thinking så känns det lite overkill att basera literatur o liknande kring det.. känns inte som ett stort ämne =)

Trevlig kväll! =)

MS:

Mellanlagret?

Detta är ett designmönster, jag tycker jag tydligt säger att jag inte bygger på detta sätt, och sedan syftar jag faktiskt på XP som handlar om Exptreme Programming. Det vill säga, detta Designmänster passar ypperligt i ett sådant tillfälle då man bara behöver presentera data en enda gång.

Tänk dig den tid det tar att skriva alla properties, testa all properties med Unittesting, vs Testa endast denna property... Jag personligen bygger inte på detta sätt, och kör heller inte XP (Extreme Programming.)

Det finns även andra fall en sådan lönsning kan vara effektiv om man inte vill nyttja Emit m.m. Det är i de fall då man exempelvis har kunder som hela tiden vill ha olika sortsersdata. Där du helt enkelt inte vill bygga flera olika klasser kundspecifika. Då det bara gäller presentation av data och inte för något annat syfte, information som inte utgör någon funktionalitet under XP utveckling tas fram fortare på detta sätt... Det är ett designmönster. Val av vem som att nyttja...

Mvh Johan

Andreas:

Detta handlar om att effektivt ta fram kod under XP data som bara behöver användas en enda gång som inte utgör någon som helst funktionalitet. Anser du att du skulle bygga typade attribut (properties) för en hel rad information som bara används vid presentation under XP förhållanden? Där delar som Unittesting ingår?

Informationen i detta designmönster är menat endast för att beskriva lite information om saker som inte utgör funktionalitet. Som jag även skrev, måste dessa egenskaper utgöra funktionalitet läggs de till typade och inte i någon description klass.

Sedan är det faktiskt skillnad på att nyttja designmönster eller ej. I mitt fall har jag inte gjort på detta vis, men jag bygger inte under XP förhållanden med YDGNI som en viktigdel samt unittesting.
Unittesting nyttjar jag dock men det hör inte hit.

30 Propterties a ca 30 minuter (om vi låtstas att en property tar en minut, vet går fortare.)
test av alla Properties skall ske. a 30 minuter (1 minut property ) detta är 1 timmers utv tid under XP förhållande... I detta designmönster. 1 Property a 1 minut, 1 minut testning då man vet att dess contaioner klass redan fungerar. det är 2 minuter mot 60. Information som bara skall presenteras en enda gång som inte hänger med systemet runt som inte använda någon annan stans än på en profilsida tar alltså ca 58 minuter fortare att ta fram med detta mönster. Ypperligt bra mönster må jag säga för sådana förhållanden... Men absolut inget jag skulle använda mig av under andra förhållande än XP.

Jag presenterar ett mönster, säger inte SÅ här skall man göra. Detta är en tanke, tanken grundas från David West idéer ang Object thinking (hans object thinking) du o jag har ju helt annan metafor av verkligheten. GOF alla mönster nyttjar du ju inte heller eller hur? Och vem säger att alla deras mönster faller oss i smaken?

Sedan kan detta mönster falla en rad andra i smaken, och då är jag bara glad som spred det vidare.
Som bekant Arkitektur är religion, det är dialekter och metfaroren Politik passar också bra in här.
Det vi anser rätt är så som vi tycker det skall vara eller som känns bäst för oss. Men dessa designmönster kanske känns bäst för andra..

Så för er som vill nyttja detta designmönster, som ser fler fördelar med det än typade properties, använd det om det faller er i smaken.

mvh Johan

Det här är ett gammalt sätt att lösa problem med extenderbara entiteter. Det är alltid knepigt det här om man ska helt typade objekt med getters och setters, obj.getSomeProperty, eller om man ska något lika flexibelt som med recordsets där man kan göra rs.getString("someProperty").

Själv tycker jag om att ha en mer statiskt domänmodell med typade objekt...allt blir så mycket enklare då :) Jag håller inte med att man bara vill åt dessa egenskaper, som t ex kunden själv vill lägga till, endast i UI lagret. De brukar ofta användas t ex vid olika typer av urval, alla som har blåa ögon, alla som har ett ärr på vänsta kinden osv. Det är väldigt svårt att göra dessa urval om man inte känner till sin domänmodell. Det är också ofta svårt, om man vill ha det snyggt, att presentera data som inte är typad. Om man vill lista alla personer som finns upplagda i en databas i en tabell...vilka egenskaper ska då synas osv. Eftersom alla ser olika ut så blir detta en ganska tuff uppgift.

Men visst...i vissa fall har man inte mycket val, kundens krav bestämmer...fast jag tycker att det är väldigt ugly.

/Nils

Johan,

Du snackar om XP som om det vore en komponent eller liknande "XP data" och "presentation under XP förhållanden". XP är och förblir en utvecklings metodik så du får nog formulera dig lite annorlunda eller utveckla vad du menar.

Att man proppar på saker på ett objekt för att kunna testa det med unit testing köper jag inte. Inte iheller det med att skriva propar är en tidkrävande process. Bara för VS.NET 2002/2003 inte har någon automatic code insertion så betyder det inte att andra miljöer inte har det och att det inte finns en hel rad av plugins som löser det.

Ett designmönster är en allmänt erkänd lösningning på eett vanligt problem. Lösningan skall vara beprövad. Jag har inte själv läst boken ni hänvisar till, som kanske skulle svara på många av mina funderingar kring detta, men att slänga in "metadata" om ett objekt skulle jag kanske inte kalla för dett designmönster ?

Sen tar du upp lite om tid för proppar me doch utan XP "förhållande".. det finns inte en 1:1 relation där eftersom, som jag tidigare nämnde, kan inte alla properties ersättas då man behöver typade, validerade properties i många fall så jag kan inte riktig hänga med på generaliseringen. Och även om det används på en profilsida så kan det finns behov att struktuerat kunna presentera informationen och att "slänga allt i en hög" underlättar inte det där. Även här faller man tillbaka på att det finns massvis med andra utveckligsmiljöer och addins som automatiserar property skapandet och då har man inte "vunnit" någon tid med Object Thinking. Och även om man hade gjort det.. så till vilken kostnad? otypoad, ovaliderad data.

Jag kan hålla med om att det finns massor av information som man exponerar som kanske inte behöver valideras och typas, men då skulle jag nog vilja se att man ändå använde kända nycklar (kanske ett enum) för att hitta dem.. kan nog se ytterst få tillfällen då detta medför någon "vinst" vare sig i utvecklingstid eller föränklad användning.. bara om man skall göra en "dump" av information och helt ärligt hur ofta händer det ? kanske vid debugging .

<b>Jag presenterar ett mönster, säger inte SÅ här skall man göra. Detta är en tanke, tanken grundas från David West idéer ang Object thinking</b>

Tacksam för att du för fram informationen. Hoppas du /och fredrik) inte ser detta som kritik från mig, utan jag försöker föra en diskussion om något jag inte är insatt i och där av ifråga sätter jag informationen. Jag sväljer inte det med hull och hår om jag är tveksam. Jag skulle gärna vilja se riktiga (inte fiktiva och hypotetiska) situationer där detta är användbart och har tillämpats.. finns det några "best practises" dokumenterade för detta?

Trevlig kväll =)

Nils,

Precis... DU har så rätt så. Men som jag även tydligt (tycker jag i alla fall) beskriver så om denna description bara används vid ett tillfälle och inte utgör funktionalitet i systemet är det ett ypperligt designmönster för XP. Eftersom det alltid finns undantag så skulle jag nog t om. kunna säga att de som bygger på detta sätt av samma förutsättning att det inte skall nyttjas till något funktionellt så spar det tid och ökar möjligheten att öka på dess beskrvining om man anser att fler saker skall till som inte används i systemet.

I ditt fall med sortera på Ögon som är blå. Så vill du ju åt mer funktionalitet än att bara spresentera data i exempelvis ett UI eller hur? Då kanske man skall se över om man inte skall låta ögon vara typade istället för det underlättar för att snabbt nå ett resultat under XP.

Dock kan man ju alltid itterera genom alla Personer plocka dess descirption med keyn eyeColor och kolla om den är blå :-) allt är rellativt.

mvh Johan

Andreas:

Helt lugnt, ser det inte som kritik. Har inte pratat med min bror om detta heller, och inte orkat läsa hans inlägg, jag tror inte vi ser detta på samma sätt.

Ett designmönster måste inte vara någto alla känner till. Alla har sina egna designmönster om man sedan trycker ut dem i en bok så alla ser dem är en annan sak... Designmänster är ingen produkt, utan ett mönster som kan ge fördelar under oliak förhållanden. I detta fall anser jag det hela vara ett design mönster då du faktiskt effektiviserar något, du kan återanvända mönstret i din kod design på andra klasser om du vill m.m.

Problemet med XP (Extreme programming) är att det är så jobbigt att skriva Extreme Programming hela tiden, och självklart menar jag inte Windows XP. Att några galningar säger XP till Windows XP kan inte jag rå för så om det blir rörigt så kan jag ju inte göra så mycket åt det.

Även om du skulle kunna tryck upp
<code>
public *** ***
{
get { return ***** ; }
set { this.***** = value; }
}
</code>

via verktyg så måste du ändå skriva in alla **** till vad de är, vilket tar tid.
XP handlar fortfarnade om Extreme programming, Där YDGNI är en stor bit i metoden. (om vi nu skall kalla XP för metod). Varje minut är en förlust typ. Och i detta fall är datan i mitt exempel halt onödig för applikationens funktionalitet. Anser jag att jag måste validera den vid set så har den helt plötsligt fått betydelse. Sedan om man nyttjar self fill idén så kommer den del av Person som fyller upp datan kunna sköta kontrollerna åt dig. Set skulle inte ens behövas. Detta är också en syn många har.
Enititeter som fyller sig själva. Det har oftast bara Gets och Sets där de utgör någon funktionell förändring.

Mvh Johan

Nils:

Visst kan det vara ett problem när det gäller vad som ska visas då man lsitar användare. Vi valde dock att lista det som vi anser är viktigt så som användarnamn, för och efternamn samt en förklarande text om användaren. Sedan när en administratör får in på en användare så listar vi de "utökade profiler" som administartören har valt att bygga ut användaren med. Varje profilegenska eller vad man ska kalla det för har en typ kopplat till sig, denna typ kan tex vara string etc, varje typ har även en sk formaterare (en klass som bestämmer hur typen ska presenteras i UI). Denna typ av lösning har fungerat jätte bra för våra kunder och oss själva. Ett liknande applikations block har Microsoft Patterns & Prectices gjort, dock så beskrivs profiler i xml i web.config (så som Profile gör i ASp.Net 2.0) vilket iofs skulle kunnas tänkas vara snyggare än som vi lagra det i databas. Att vi valde databas är för att vi har så många olika objekt som våra kunder vill kunna utöka.

De objekt som inte båra kunder kräver att de ska kunna utöka har vi hård typade egenskaper för, vilket jag tycker är en självklarthet.

Andreas:

>Har varit med och utvecklat en produkt med samma typ av lösning och om detta är Object Thinking så >känns det lite overkill att basera literatur o liknande kring det.. känns inte som ett stort ämne =)

Jag anser inte att det har med Object Thinking att göra utan en lösning för att lösa våra kunders behov. Men jag tog upp det för det påminner lite om "Description" fallet.

Angående "identifiera ett object":

Jo visst kan andra egenskaper identifiera ett objekt. Men en ögon färg tex blå är ofta inte unikt för en person, visst en kombiniering av olika egenskaper gör personen unik, väljer man att dessa ska finnas för alla person objekt så tycker jag att de ska skapas som properties. Men även om David West är en stor arkitekt inom Java världen så anser inte jag att han har rätt, men jag förstår hans tankesätt.
Att förklara ett helt nytt tanke sätt som Objeckt Thinking här som inlägg skulle kräva många, många inlägg. Om du är intreserad av Object Thinking så skulle jag rekommendera boken.

Mvh Fredrik Normén NSQUARED2
http://normen.mine.nu/myblog

Johan,

Bara för att runda av så tråden inte blir ett monster, så sa jag att XP är en metodik inte ett OS, du läste nog lite fel och nej **** behöver man inte fylla i själv, det finns plugins som man kan konfigurera så de autoamtiskt generera properties av fält t.ex .. men det är utanför denna tråd =)

Andreas:

" Du snackar om XP som om det vore en komponent " sorry. tänkte att du syftade på Win XP där...
XP är egentligen ingen metod, eller det är både och. Och visst kan man se det som en komponent i sin verksamhet så varför inte kunna förklara det så? om det nu är så man uppfattar mina förklaringar då jag sälv inte direkt anser att jag pratade om XP som om det vore en komponent.

Jo men även om de automatiseras så måste du ange Typ Namn och Variabel för varje property trotts app som hjälper dig. Med app som hjälper dig går det ju då ännu fortare med en property ;-) sedan är det fortfarande så att Unittesting är en del i XP, vilket utgör tester av det mesta så som properties.
Som sagt XP går ut på att bygga kod så fort som möjligt strukturerat och fungerande efter dess verklighet. Där OO, OOP är viktiga ingridienser, där Refacotoring och Unittesting utgör stora tekniksa delar och där YDGNI är en regel. Detta är ett ypperligt sätt att snabba upp kod processen för något man egentlgien inte behöver.
Metafor bokhylla:
"Det är ju onödigt att skapa 30 Lådor i en bokhylla för onödiga ting då du kan få plats med allt det onödiga i en."

Mvh Johan

>Detta är ett designmönster, jag tycker jag tydligt säger att jag inte bygger på detta sätt, och sedan syftar jag faktiskt på XP som handlar om Exptreme Programming.

Min kommentar syftade på ditt kodexempel, inte designmönstret som sådant. Det kan säkert vara användbart vid rätt tillfälle, men exemplet du presenterade tyckte jag inte var ett sånt.


>Tänk dig den tid det tar att skriva alla properties,

Just det, och jag använder inte heller properties så ofta.

http://weblogs.asp.net/jaybaz_ms/archive/2004/04/29/123333.aspx

stämmer ganska bra med mitt eget resonemang.


>testa all properties med Unittesting, vs Testa endast denna property...

Jag ser inte hur exemplet du skrev skulle kräva mindre testning. Snarare mer, eftersom du utan stark typning kan göra många fler fel som inte fångas av kompilatorn. Exempelvis att du stavar fel i nyckelsträngen.


MS

Hej,

Jo man kan stava fel. Men det kan du ju med datan du puttar in oxå. I detta fall så ittererar du genom alla data och presenterar den, så är nycklarna felstavade syns det i Presentationen.

Sedan vet du ju att exempelvis en Hybrid fungerar så du måste aldrig testa dess Add, Remove metoder.

Det exemplet du skickade där man oftast nyttjar constructorn istället för properties är faktiskt oxå ett lika gammalt mönster eller vad vi skall kalla det. Vet många som gör på det viset och endast använder
properties då de skall utgöra någon funktionalitet. Det händer ibland att jag gör så, beror ju lite på vad det är för object jag vill ha fram dock. En entitet skall ha publica properties, hur gör du då? lite nyfiken?

Jag skrev om David West idé för att jag tykte den var intressant. Inte för att starta lite reaktioner m.m. Själv diggar jag den inte... Men jag vågar inte säga att jag aldrig kommer bygga en sådan hantering. I vår värld är aldrgi för starkt :-) Vem vet, till nått kan den passa...

mvh Johan