c# - Confused with SOLID and Dependecy Injection -

so trying learn solid principles , dependency injection. have read blog posts on subject , starting understand bit. however, there 1 case can't find answer , try explain here.

i have developed library text matching, contains class matcher has function called match returns result in matchresult object. object contains information percentage, time elapsed, whether success or not , on. understand in dependency injection high level class should not "know" low level class or module. have set library , matcher class use interface matcher class, allow me register using ioc container. however, because function returning matchresult object, "high level class" have know matchresult object breaks rules of di.

how should go solving problem , recommended way so?

"high level" , "low level" terms associated dependency inversion has relation dependency injection different concept. both have initials "di", , "d" in both stands "dependency," can create confusion.

(i think of way - dependency injection way of implementing dependency inversion.)

but in opinion terminology used when defining dependency inversion can confusing .net programmers trying understand concept. it's applicable, of terminology isn't used among .net developers.

from robert martin's definition, quoted on wikipedia,

high-level modules should not depend on low-level modules. both should depend on abstractions. abstractions should not depend on details. details should depend on abstractions.

what "high level module" , "low level module?" if find confusing you're not alone. don't use terms. part can understand , apply should depend on abstractions.

in case of matchresult, if it's container few properties it's abstract enough. dtos have been common practice time, if time had revealed needed wrap them in interfaces pattern have emerged now. doesn't hurt, it's not necessary.

going dependency inversion - real confusion comes name itself. getting inverted? when see diagrams what's on wikipedia page, recommendation away blinding diagrams.

martin explains use of word "inversion" way (going original paper on subject)

one might question why use word “inversion”. frankly, it is because more traditional software development methods, such structured analysis , design, tend create software structures in high level modules depend upon low level modules, , in abstractions depend upon details. indeed 1 of goals of these methods define subprogram hierarchy describes how high level modules make calls low level modules. figure 1 example of such hierarchy. thus, the dependency structure of designed object oriented program “inverted” respect dependency structure results traditional procedural methods.

in other words, inversion contrast between applying dependency inversion, , "traditional" style of not applying dependency inversion. might clearer if you're coming background in 'high level modules depend upon low level modules,' (and use term "module.") if not 'tradition' 'inverting?' nothing.

all of details still have meaning, extremely confusing when you're trying learn these concepts first time. suggestion apply part, are: depend on abstractions.

if you're applying principle because whatever "high-level modules" , "low-level modules" are, classes won't dependent on other classes - high-level, low-level, or otherwise.