Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A unit test would test <code>SomeClass</code> at most. Therefore you would typically mock classWithEvent. Using some kind of injection for classWithEvent in ctor is fine. Just as Thomas Weller said wiring is field assignment.</p> <p>Option 2 is actually bad IMHO. As if you omit a call to <code>ActivateEventHandling</code> you end up with a improperly initialized class and need to transport knowledge of the requirement to call <code>ActivateEventHandling</code> in comments or somehow else, which make the class harder to use and probably results in a class-usage that was not even tested by you, as you have called <code>ActivateEventHandling</code> and tested it but an uninformed user omitting the activation didn't, and you have certainly not tested your class when <code>ActivateEventHandling</code> was not called, right? :)</p> <p><strong>Edit: There may be alternative approaches here which are worth mentioning it</strong></p> <p>Depending on the paradigm it may be wise to avoid wiring events in the class at all. I need to relativize my comment on Stephen Byrne's answer.</p> <p>Wiring can be regarded as context knowledge. The <a href="http://en.wikipedia.org/wiki/Single_responsibility_principle" rel="nofollow">single responsibility principle</a> says a class should do only one task. Furthermore a class can be used more versatile if it does not have a dependency to something else. A very loosely coupled system would provide many classes witch have events and handlers and do not know other classes.</p> <p>The environment is then responsible for wiring all the classes together to connect events properly with handlers. The environment would create the context in which the classes interact with each-other in a meaningful way. A class in this case does therefore not know to whom it will be bound and it actually does not care. If it requires a value, it asks for it, whom it asks should be unknown to it. In that case there wouldn't even be an interface injected into the ctor to avoid a dependency. This concept is similar to neurons in a brain as they also emit messages to the environment and expect answer not knowing neighbouring neurons.</p> <p>However I regard a dependency to an interface, if it is injected by some means of a dependency injection container just another paradigm and not less wrong.</p> <p>The non trivial task of the environment to wire up all classes on start may lead to runtime errors (which are mitigated by a very good test coverage of functional and integration tests, which may be a hard task for large projects) and it gets very annoying if you need to wire dozens of classes and probably hundreds of events on startup manually. While I agree that wiring in an environment and not in the class itself can be nice, it is not practical for large scale code.</p> <p>Ralf Westphal (one of the founders of the <a href="http://www.clean-code-developer.de/" rel="nofollow" title="CCD in German;">clean code developer initiative (sorry german only)</a>) has written a software that performs the wiring automatically in a concept called "event based components" (not necessarily coined by himself). It uses naming conventions and signature matching with reflection to bind events and handlers together.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload