15. januar 2014 - 13:07Der er
41 kommentarer og 1 løsning
At lave et "Bill of Materials" objekt
Hejsa
I næste skridt i følgetonen om min bysamfundssimulator, prøver jeg nu at finde en smart måde, at holde styr på hvilke materialer og mængder af disse jeg skal bruge.
Eksempel:
Jeg skal bygge et hus. Dette hus består af 3 bygningselementer(fundament, bærende konstruktion og forskalling). Hvert element har nogle dimensioner og et eller flere materialer.
Så langt så godt.
Nu kunne jeg så godt tænke mig, at lave en samlet liste over de materialer(og mængder) jeg skal bruge til hele bygningen.
Det skal dertil siges, at jeg også har en lignende struktur for at lave værktøjer. Her er elementerne bare Håndtag, Forlænger og Redskabsdel.
Som en lille krølle på problemet, er det IKKE givet, at er altid er 3 elementer - nogle gange kan der godt bare være 2. Det gælder både bygninger og værktøjer.
Materialerne er pt. delt op som dels klasser, dels nogle enums(ja, jeg er tosset med dem! ;D).
Eksempel:
Jeg har klassen Plant som har subklasserne Tree og Seed. Dertil har jeg så en Enum WoodType som indeholder træsorterne
Min Forester bruger så et Seed til at plante et Tree.
Træet vokser sig stort, og min WoodChopper kommer så og fælder det, og laver det til Boards.
Nu har jeg så et klart byggemateriale.
Jeg har så lavet mig en klasse BillOfSingleMaterial som jeg laver mig en liste af:
public class BillOfSingleMaterial { private string _ElementName; private string _MaterialType; private string _MaterialSubType; private double _Amount;
"En ting der skal bygges må have en "GetRequierements()" ..."
Hmm...joh...men det ved jeg faktisk heller ikke - der er ikke noget fast at forholde sig til. En bygning kan jo laves af..jah, alt. :) Selv Jord. ;)
"Jeg kan ikke lige helt se problemet her"
Nej, men så er det nok fordi du er bedre end mig. ;)
"Alt i min verden ville være det samme. Da de jo skal have nogen fælles træk for at gøre det hele lidt nemmere." Det er jeg så ikke heelt enig i. ;) Frø og træer er jo planter og dermed levende. De to andre er jo pænt døde. ;)
Ved Arne_v har skrevet om det før. Der er ikke den store forskel kun at abstract kan have en default implementering og interface skal du altid implementere det hele i den konkrete klasse.
For at plante et træ skal du bruge et frø. For at lave en stamme skal du bruge et træ. For at bygge et hus skal du bruge XXX.
Sætningerne synes jeg nu passer meget godt sammen.
Men om det hedder A eller B er vel som sådan lige meget bare det bliver perfekt i en udviklers øjne hvor det giver god mening.
Men uden at kende hele dit projekt tror jeg det bliver svært at bliver mere konkret, eller beskrive ting som allerede er blevet skrevet i tidligere spørgsmål.
Men du kan jo også godt have 2 forskellige ting.
Døde og levende ting.
Men til sement, skal du jo bruges vand(levende) og mørtel(dødt) som så må give et output af en død ting.
Hvor frø og vand vil kunne give mange levende ting ... og her kommer så endnu et problem at noget er levende bliver til en død ting.
Jeg kan ikke lige gennemskue hvordan det hele kommer til at virke hvis du ikke kan behandle alle dine ting på samme måde.
...for at bygge et hus, skal jeg A) have en byggeplan, B) som har nogle bygningelementer og C) som er af nogle forskellige materialer. Altså, JEG synes ikke det er det samme... :)
Det kan godt være jeg er lidt(meget?) dårlig til at beskrive mine problemer ordenligt, så jeg prøver lige igen:
Helt konkret har jeg flere forskellige objekter jeg skal samle uden på forhånd at vide hvilken type de er.
Det kunne eksempelvis være et bygningselement som har et materiale, brædder, som er af træsorten eg.
Bygningselementet har jeg her: public BuildingElement(BuildingElementType type, BasicMaterialType materialtype, int height, int length, int width, Strength strength) {...}
Brædderne har jeg - med træsort som en enum property: public Boards(int amount, LifeLength lifespan, bool israwmaterial, int quality, WoodType woodspecies) {...}
"BasicMaterialType materialtype" i BuildingElement skal så udskiftes med noget "Bill of Materials".
Den BoM skal så kunne indeholde brædder, men også alle mulige andre typer.
Giver det mere mening nu, eller er det bare mig der er fat svag? :)
Det giver fin mening, men som du selv slutter af med:
Den BoM skal så kunne indeholde brædder, men også alle mulige andre typer.
"men også alle mulige andre typer."
Eneste måde at kunne håndtere alle typer på er via et eller andet som er fælles.
Lige nu har du intet som er fælles for alle dine ting og kan derfor ikke lave det.
Man kan som du tidligere har gjort lave en stor swtich/case for at finde ud af hvad type det er og så håndtere dem forskelligt. Man tager så bare imod en liste aftype "object".
Men du kan jo lave din BoM så den har en metode for hvert eneste ting den skal kunne tage imod.
Men hvis du tænker på dine objecter ... hvad er så fælles for alle i din BoM? Der må være et eller andet de har til fælles for at kunne lave en retning.
IBill interface hvor ting skal implementere en speciel property som kunne være pris.
Element navn (dvs. navnet på (ConstructableObject's sub-klasserne)klassen) Materiale navn (dvs. navnet på (Goods/sub-klasserne)klassen) Materiale type (dvs. værdien af den tilhørende enum ) Material mængde (bare et tal(double))
UDEN at jeg skal lave 1000(een pr. klasse) interfaces eller lign. ;)
DataSource? Er det ikke kun til database brug? Det påtænker jeg ikke at lave endnu.
Nej, BoM er "Bill of materials", og ikke BillING. ;) Det er KUN en liste over materialer og mængder, der er ikke noget med pris ind over.
Det kan godt være jeg har misforstået dig, men jeg kommer til at have omkring 1000 materiale klasser, og jeg forstod det som om du mente, jeg skulle implementere BoM interfaces i dem alle - eller var det omvendt?? :D
Udover opløsningen er så ringe på det billede at jeg knap kan læse det så er jeg ikke blevet meget klogere.
DataSource er bare et sted der kan komme data fra ...
Ved ikke rigtig om jeg er blevet meget klogere ... jeg er stadig lidt i tvivl om hvad dit mål er.
Det jeg læser fra dit oprindelig spørgsmål er linjen: Nu kunne jeg så godt tænke mig, at lave en samlet liste over de materialer(og mængder) jeg skal bruge til hele bygningen.
Er det ikke bygningen der ved hvad den er lavet af? Burde den ikke indeholde de informationer?
Korretk, bygningen ved ikke hvad den lavet af, da bygningen faktisk ikke eksistere som en enhed. :)
Den består, som nævnt, af 3 bygningselementer som hver især består af nogle materialer <- det er disse materialer jeg gerne vil have en samlet liste over.
Altså, jeg forstiller mig, at jeg kan lave et kald til bygningsobjektet's BillOfMaterials og dermed se hvad der skal bruges...så BoM objektet skal vel bruges i den klasse.
Måske, det hele giver meget mere mening, hvis jeg skitsere forskellen mellem et normalt bygnings objekt i spil:
Normalt: Du vælger bygning, som så "smides" ind på kortet - og bygningen anses for at eet objekt - hvis det er HEELT vildt, kan man se en animation af byggeprocessen i flere faser.
I min sim: Der bygges hvert element hver for sig, og sameksistere i hele bygningens levetid. Også selvom et eller flere af elementerne fjernes(taget f.eks.). Det betyder bla. at du kan fjerne en væg fra en bygning og montere den samme væg på en anden.
Kort sagt: I min sim ser man verdenen fra håndværkersjakkets side, hvorimod man normalt ser det fra arkitektens side. :)
Vil du så mener, at det dersens interface-ting skulle forbinde til(==have en liste af) Goods klassen? :) Og derefter bruges af ConstructableObjects klassens underklasser?
Hvis du læser dem begge er der faktisk forskel som de skriver det på siden.
Så BOM er nok det rigtige ... da MOQ bliver beskrevet som den mængde det kræver at bygge et "proposed construction" ... og så igen ... dette kan jo også være en foreslået konstruktion.
Jeg tror i hvert fald sådan lige nu at det var sådan jeg ville starte ... så man kan jo altid senere lave det om hvis man finder ud af det er en mærkelig/dum/træls måde at lave det på.
Men ... de bliver i hvert fald nød til at kunne håndteres på samme måde ... da tingen der skal bygges er ret ligeglad med det er lavet af, men bare at det skal laves af X ting som jo på BOM bare er en linje.
Jeg får knupper af alle dine this. Det er helt tydeligt at der arbejdes på et object på klassen da du har navngivet den med "_" ... dvs private/protected member field. Så fjern "this", det er bare ren støj.
Udover det så synes jeg du har frygteligt mange strings i spil der ... kan ikke lige helt gennemskue det, men var du ikke på vej mod noget type stærkt?
For mig betyder "_" ikke et bare et objekt, men et internt(private) navn(om det så er en variabel, eller et objekt).
Jeg kan godt følge dig så langt, at det virker overflødigt, at bruge this, men jeg gør det for at holde konsistens og være sikker på, at koden gøre som jeg tror den gør. :) Det kan godt være lidt svært at holde styr på, når det hele ændre sig så meget.
Og jo, der er ALT ALT for mange strings. :( Men det håber jeg at ændre inden ikke alt for længe. Præcist hvordan har jeg dog ikke fundet ud af endnu.
Jeg takker og bukker for hjælpen - og ikke mindst tålmodigheden! ;D
parameter er "myString" ... ligesom interne variabler oprettet i en metode. member field variable er "_myString" ( Kan også være _MyString, gør ikke den store forskel ) properties er "MyString" const variable er "MY_STRING"
Det er MS der har de guide lines et eller andet sted på deres side.
På denne måde er man aldrig i tvivl om hvor meget kommer fra ved at kigge på dens navn.
En metode bør ikke fylde mere end den kan være på en skærm, fylder den mere kan det være et tegn på de bør smide ud i methods.
Og NARJ, du får mig IKKE til at fjerne this'erne!! ;p
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
