title: Assigning proper modifiers correctly in C# when it comes to abstract classes
body: <p>I have run into this situation many times, and have 'hacked' my way around the situation, but it seems it's a gap in my understanding.</p>
  
  <p>Given the following code:</p>
  
  <pre><code>public class Foo
  {
      Bar barA = new BarA();
  
      private void Bat() =&gt; barA.Baz();
  }
  
  public abstract class Bar
  {
      // Obviously this *can't* be private
      private abstract Baz();
  }
  
  public class BarA : Bar
  {
      public void Run() =&gt; Baz();
  
      // Again this can't be private 
      private override Baz() =&gt; DoSomething();
  }
  </code></pre>
  
  <p>(caveat: I used expression bodied methods for sake of brevity in the example.  Normally I would not unless there was a good reason to.)</p>
  
  <p>Now, in the above example, my logic is that the <code>Baz</code> method needs to be defined by the concrete class, however the reason I want it private (and yes, I understand WHY it can't be, because it would be completely invisible/inaccessible to the concrete class), is logically, I do not want the concrete class to be able to call the method, merely define it.</p>
  
  <p>The way to fix the code is to make the method <code>protected</code>, however, then the method becomes available to executable from within the concrete class.</p>
  
  <p>Ultimately, I want an abstract/base class that handles internals of executing some code that is defined by the concrete class, however never available for the concrete class itself to call/execute.  What is the flaw with that logic, or how should I be implementing that logic properly.</p>
  
  <p>** EDIT: A concrete implementation **</p>
  
  <p>Let's say for example this is part of a plugin system within a library (that I am creating, and another developer is implementing).  Another part of the library uses derived classes that implement this abstract class (say it's a filter in image processing).  The developer define's the method on what the filter does, however the abstract class (essentially handles the only processing that the defined filter provides), and yes the contract (interface) is made for the image processor so it doesn't (need to) know/care about implementation anyhow.</p>