Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There's no way to relate method overloading and generics: although they look similar, they are very different. Specifically, overloading lets you do <strong>different things</strong> based on the type of arguments used; while generics allows you to do <strong>the exact same thing</strong> regardless of the type used. </p> <p>If your BuildClause method is overloaded and every overload is doing something different (not just different by the type used, but really different logic, in this case - choosing whether or not to add quotes) then somewhere, ultimately, you're gonna have to say something like "if type is this do this, if type is that do that" (I call that "switch-on-type"). </p> <p>Another approach is to avoid that "switch-on-type" logic and replace it with polymorphism. Suppose you had a <code>StringColFilter : ColFilter&lt;string&gt;</code> and a <code>IntColFilter : ColFilter&lt;int&gt;</code>, then each of them could override a virtual method from <code>ColFilter&lt;T&gt;</code> and provide its own BuildClause implementation (or just some piece of data that would help BuildClause process it). But then you'd need to explicitly create the correct subtype of ColFilter, which just moves the "switch-on-type" logic to another place in your application. If you're lucky, it'll move that logic to a place in your application where you have the knowledge of which type you're dealing with, and then you could explicitly create different ColFilters at different places in your application and process them generically later on.</p> <p>Consider something like this:</p> <pre><code>abstract class ColFilter&lt;T&gt; { abstract bool AddSingleQuotes { get; } List&lt;T&gt; Values { get; } } class IntColFilter&lt;T&gt; { override bool AddSingleQuotes { get { return false; } } } class StringColFilter&lt;T&gt; { override bool AddSingleQuotes { get { return true; } } } class SomeOtherClass { public static string BuildClause&lt;T&gt;(string prefix, ColFilter&lt;T&gt; filter) { return BuildClause(prefix, filter.Values, filter.AddSingleQuotes); } public static string BuildClause&lt;T&gt;(string prefix, IList&lt;T&gt; values, bool addSingleQuotes) { // use your existing implementation, since here we don't care about types anymore -- // all we do is call ToString() on them. // in fact, we don't need this method to be generic at all! } } </code></pre> <p>Of course this also gets you to the problem of whether ColFilter should know about quotes or not, but that's a design issue and deserves another question :)</p> <p>I also stand by the other posters in saying that if you're trying to build something that creates SQL statements by joining strings together, you should probably stop doing it and move over to parameterized queries which are easier and, more importantly, safer.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

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