Å finne ut samtalekjeden [lukket]

Jeg er ikke kjent med noen generisk eller vanlige mønstre på tvers av programmeringsspråk. De fleste håndterer det ved dedikerte refleksjon-APIer.

I .Net bruker du System.Diagnostics.StackFrame og System.Diagnostics.StackTrace klasser. Se https://stackoverflow.com/questions/12556767/how-to-get-current-line-number-for-example-use-at-messagebox-show/12556789#12556789 for et eksempel. Andre språk og miljøer kan ha ekvivalenter.

Kommentarer

• Jepp, men er det en objektorientert måte å løse dette på? så for å unngå StackTrace
• @BDotA: Hvis du bryr deg om hvem som ringte deg, gjør du ' ikke OOP. Tenk på hva du er prøver å gjøre. (Jeg innrømmer at. NET ofte ikke er OO, og at vi må legge OO noen ganger når vi bruker det, men det lønner seg å vite at vi ' gjør dette, selv om vi uansett må gjøre det.)

Jeg skal ut på et lem her og gjetter at du leter etter objektorienterte teknikker for å implementere instrumentering.

Det er to umiddelbare måter du kommer til å tenke på, mest brukte ville være det første jeg gjetter:

1. Ha en global (singleton eller hva har du) stabelen et sted som hver metode som kjøres umiddelbart legger til seg. effektivt opprettholder en global samtalekjede. Du kan bare slippe å komme slutten av hver metode du prøver å instrumentere, er vanlig annen instrumenteringspraksis å starte et stoppeklokke i begynnelsen av metoden og stoppe på slutten for å registrere lengden osv.

2. Ha et DI-rammeverk som er en ruter for alle metodeanrop, som kan oppføre seg mer i likhet med sending av meldinger, og inne i dette rammeverket vil du notere i en stabel hver metodekall som forekommer som ovenfor, bortsett fra at den ville være sentralisert til dette ene stedet.

Jeg kan ikke si at jeg foreslår nr. 2 uten kanskje å bruke noe AOP-rammeverk eller noe, men i det hele tatt er det litt av en ekstrem instrumentering i mine øyne å opprettholde ditt eget stack-spor på 100% av metodeanrop. Flott for feilsøking av ting og kanskje nødvendig hvis du ikke jobber i et refleksivt språk, men jeg vil være sikker på at jeg lett kan slå av noe slikt for produksjon og gjøre mitt beste for å holde det utenfor veien, det er derfor jeg liker ikke # 2 ovenfor.

Ingen av disse er nødvendige i et refleksivt språk og bør derfor ikke implementeres i C # bortsett fra for å illustrere kryssingsprosessen grenser. (advarsel: de kan være raskere enn refleksjon hvis de gjøres riktig, men vedlikeholdskostnadene gjør dem fortsatt ikke verdt det)

Kommentarer

• Takk for ideene, så i C # hvordan kan jeg gjøre det med Reflection? Jeg vet ikke om jeg kan flytte dette innlegget til SÅ? eller kopier lim og opprett et nytt innlegg på SÅ en god ide … så hvis du kan hjelpe meg med refleksjon, ville det vært bra.
• @BDotA Se på stackoverflow.com/questions/171970/ … selv om jeg trodde jeg husket en måte uten å påkalle StackFrame objektet har ikke ' ikke funnet det. Likevel bør ikke teknikkene ovenfor gjøres i C #, men du bør bruke StackFrame om nødvendig.

IMHO, du bør spørre deg selv på alvor hvorfor du tror du trenger dette.

Hvis MethodFoo() oppfører seg annerledes hvis det blir kalt fra forsamling A eller B, er den anropende enheten omtrent som en skjult inngangsparameter til MethodFoo() og kan trolig bli årsaken til uventet eller feil oppførsel.Så som et alternativ, gjør den inngangsparameteren eksplisitt: legg til en ekstra parameter til MethodFoo() som indikerer konteksten eller innringeren. Dette kan være en enum, en string -parameter eller en referanse til selve den anropende enheten, avhengig av den tiltenkte atferdsendringen til MethodFoo().

Kommentarer

• Å kjære jeg gjorde ikke ' t forestill deg til og med at han prøvde å kontrollere flyt, at ' er en veldig skummel tanke … Tydeligvis er du mye mer pessimistisk enn meg for å ha kommet med den konklusjonen, men kan ha rett ..
• @JimmyHoffa: hvis noen stiller et spørsmål som dette uten å nevne noe om intensjonen hans, blir jeg mistenksom 😉