Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Using events for this is probably not the best design approach.</p> <p>Since it is an inheriting class that would be overriding this behavior, the method should be marked as protected and virtual:</p> <pre><code>protected virtual bool Validate(object item); </code></pre> <p>I too do not like using <code>out</code> on parameters, so following your initial instincts to use <code>EventArgs</code>, you should probably create a class to encapsulate the results of your validation.</p> <p>Example:</p> <pre><code>class ValidationResult { public string ResultMessage{get;set;} public bool IsValid {get;set;} } </code></pre> <p>Your method would then be:</p> <pre><code>protected virtual ValidationResult Validate(object item) { ValidationResult result = new ValidationResult(); // validate and set results values accordingly return result; } </code></pre> <p>The pros and cons of using this over events are that events are intended to be used when you want to publish an action or information to multiple subscribers. The subscribers are classes that you know nothing about. You do not care who they are or what they do. They should never really pass information back to the notifying class either. They should just process the event information given to them.</p> <p>In your instance, your inherited class is your only subscriber. On top of that you want to be able pass useful information back to the parent class. Inheritance fits this desired behavior much better, and also allows you to easily implement different types of validation class. With events, you would have to keep typing code to attach event handlers over and over again (very ugly IMO).</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