.NET Interface opbygget layout spørgsmål

Tags:    programmering

Så er jeg på den igen!

Nu har jeg kodet hele basen i mit nye system op med interfaces, og jeg må sige at jeg elsker det! Jeg kan godt se idéen i at lave struktur uden at kode det bagvedliggende system. Og jeg har da også anvendt at spotte gennem en interface definition, i stedet for at læse gennem selve class filen, når jeg lige skal finde et eller andet.


Men nu begynder jeg at nærme mig "kontrol laget" i mit system. Jeg har bygget lidt fra hist og her, nok aller mest for at få styr på de interfaces, og nogle ande gode vaner jeg er ved at arbejde ind på rygraden.

Jeg tænkte på følgende: Hvordan skal jeg "forbinde" alle lagene?

Jeg er nød til at have noget logik. Fx som "Hvert minut, tjek om solnedgang, hvis solnedgang, rul persienner for" eller "hvis RFID tag modtaget, tjek mod database, hvis bruger findes og korrekt sikkerhedsniveau, lås dør op"


De to "simple" opgaver her kræver henholdsvis adgang til DMI, brug af en timer, adgang til hardwareinterfacet, og faktisk også adgang til databasen (for at game persienne state).

Det andet eksempel kræver adgang til hardware, database, talesyntese (velkomstbesked) og netværk (notificere touchskærm om adgang da den sidde lige ved siden af, og det er SÅ Sexy når den selv tænder! :D )



I det eksempel jeg fik her inde fra (kan ikke helt huske hvem af jer der gav mig det) der har hvert interface en "Notify" event som lader deres "parent class" Eller hvad man nu kalder det, koble sig til deres event og så får parenten besked om alt hvad der sker i class'en.

Jeg tænkte, er det den bedste måde at gøre det på? Have en fælles INotifyEvent med et INotifyObject som så kan køres op til mit logiclayer?


Eller hvordan vil i ligge det ud?

For lidt flere detaljer.

Fx kan IHardwareManager have "DoorOpen" "DoorClosed" "RFIDScanned" eventsne
og der er functions til at "OpenDoor", "UnlockDrawer" "TurnDevice" (Lys og andet 220v)


Mit IDatabase har så fx "GetPersonByRFID", "AddPerson", "DeletePerson" osv.

Så har jeg mit netværks modul med følgende events:
"ClientConnected", "MessageRecieved", "ClientDisconnected"
og følgende funktion
"Send", "Broadcast", "Disconnect" osv.


Og sådan kan jeg blive ved. Hvordan stykker jeg dem sammen? Og ville i fx flytte "logikken" til netværksdelen (Altså at håndtere beskederne der kommer ind) over i en anden class og så lade den notifye LogigLayer på en eller anden måde? (muligvis med forrige forslag)


Jeg sætter virkelig pris på jeres input, det er første gang jeg programmerer sådan her!




6 svar postet i denne tråd vises herunder
4 indlæg har modtaget i alt 12 karma
Sorter efter stemmer Sorter efter dato
Det kommer lidt an på hvordan du vil tilgå problemet. Vil du have een central "hjerne" der hvert minut udfører alle kontrollerne (vejr, varme, lys, etc). Eller vil du have at hvert "modul" selv skal kunne bestemme hvornår og hvad der skal gøres?

Det eksempel jeg lavede til dig i en anden tråd. Den har det hele til den sidste tilgang.

Fold kodeboks ind/udCSharp kode 


Du skal bare lave alle dine checks inde i worker_DoWork metoden, den kører i sin egen tråd. Når den så finder ud af at solen eks. er gået ned, kalder den bare "notify" og en anden klasse skal tage sig af det ELLER den skal selv gøre det. (rulle persiennerne ned og gemme i databasen) - til dette skulle du tage og sende interfaces til henholdsvis database klasse og automation klasse med ind i den viste klasse.

Giver det mening?



Egentlig kan jeg godt li' at overføre hverdag til kode. Altså synes jeg at du skal bruge events, subjects og observers.
I hverdagen sker mange ting jo som et respons til en anden ting der er sket:
Er der en der snakker, så svarer en anden - men kun hvis vedkommende lytter efter.
Er der en tredje som lytter efter hvad de to andre siger, så kan det være vedkommende griner.
En hund kan være i rummet, den lytter automatisk til dem der er der. Når en griner kan det være at hunden gør.
Den kat der så er i rummet løber ad h. som respons til at hunden gør. Katten vælter en vase.

osv... :)

piller jeg katten ud af loopet, så står vasen der stadig selv om hunden gør. :)

Når man laver BDD, bliver det mange gange en trivialtet når man skal udvide sin kodebase. Årsagen er at man laver kontrakt mellem kodestumper der kun handler udfra enkelte kommandoer.

Selvfølgelig bliver det også meget mere uoverskueligt at se konsekvensen af en handling. F.eks. hvem vidste at vasen ville vælte fordi den første person sagde noget sjovt? :)


Analogier er nu også meget sjovt... ;)



Indlæg senest redigeret d. 17.10.2011 10:17 af Bruger #10216
Du kan sagtens lave en generel struktur der kan lave alle dine "notifys". Der er dog et par ting du skal overveje. Du skal have lavet en generel notify struktur der kan sende en besked til alle den der er interesseret i det - sådan lidt abonnementsagtigt. Inden du går i gang så kig lidt på Single Responsibility Principle du skal passe på ikke at komme for meget på tværs af dette princip, da du så vil ende op med at have en stor klasse der kan lidt af alt. Det er meget bedre at have mange små klasser der hver især har et klart ansvar end een stor klasse der fungerer som en schweizer-kniv(Læs evt: min tidligere artikel om antipatterns).

Min indledende arkitektur hvor der laves små "følere" i klasser, dvs. der er faktisk en 1:1 sammenhæng mellem din hardware føler og din implementering. Hver enkelt klasse vil således kunne fungere selvstændigt, ganske som "virkeligheden" - det er lidt det Michael også kommenterer. Du kan kalde dette design "en klasse - en føler" arkitekturen.

Nå, med det på plads er der flere måder at gøre det anderledes på. Det kan godt være lidt svært at finde den bedste arkitektur til dette. Problemet består i at du har en form for "action" det vil sige en handling der skal udføres, fx. kontakt DMI, læs luftfugtighed, mål varme, osv...) disse handlinger skal køre med forskelligt interval, nogle hvert minut, nogle hver time. Det betyder du skal lave en generel måde at sende en besked ud af din generelle klasse. Problemet er at hvert kald til en ekstern kilde er specifik. Det betyder du vil få en "generel" klasse der har "specifikke" metoder fx. CheckVarme(), CheckLys(), CheckDMI(), Check???(). Du kan allerede se at denne klasse arbejder imod single responsibility principle fra tidligere. Det har så en anden uheldig effekt. Det er at hver gang du skal tilføje noget nyt til din løsning skal du ind i eksisterende klasser og modificere i det, måske endda rete i den måde dine actions udføres på. Det er lidt uheldigt - det kan sagtens lade sig gøre, men det er lidt uheldigt. Du får så en klasse der vokser liniært i forhold til features i dit system. Her er du så på vej mod et andet antipattern feature envy, idet du har en masse metoder der kalder en hel masse funktionalitet på andre klasser...

Jeg tror jeg ville lave det som jeg først beskrev, specielt hvis du senere vil lave det som moduler.






Jeg er nød til at have noget logik. Fx som "Hvert minut, tjek om solnedgang, hvis solnedgang, rul persienner for" eller "hvis RFID tag modtaget, tjek mod database, hvis bruger findes og korrekt sikkerhedsniveau, lås dør op"

Umiddelbart finder jeg polling teknikken uhensigtsmæssig, gør som de andre siger og brug "notifiers"/events til det.
Hent DMI data een gang om dagen og kalkuler den data til at finde ud af hvornår der er solnedgang og brug så en scheduler til at eksekvere opgaven på det givne tidspunkt.

Jeg vil lige dele et andet Vejr API:
yr.no - API
Det er fantastisk detaljeret og gratis (og derved langt bedre end DMI's services, og mere effektivt end en scraper)



Nu ved jeg godt at i er "pro'erne" og jeg bare er en simpel discipel...


Men jeg kan bare ikke se det "smarte" i det der? Det gør i mine øjne netop at de er mere sammenkoblede? Er det ikke muligt at koble tingene så man fx har et logiklag der varetager alle den slags opgaver?

Eller noget i den retning. For jeg synes virkelig at det vil blive mærkeligt, nok lettere i vid udstrækning (i starten i hvert fald), at skulle lade klasserne "passe sig selv".


Men jeg vil prøve at lade en klasse tage sig af alle notifys så. Men tror jeg vil lave mere end en type notify, det er intet probelm i forhold til design princippet vel?



Nu fik jeg bare formuleret det forkert her i teksten. Jeg er skam ikke så dum. De anvender scheduling til solnedgangstider. Tingene kører allerede med events. Vejr info hentes en gang i timen (tror godt jeg kan spare de par KBit en gang i timen).

Men okay okay, jeg ser mig bøjet og må få skrevet mig sådan et system :D



t