== Why is this an issue?

Changing an inherited member to ``++private++`` will not prevent access to the base class implementation.


This rule raises an issue when a ``++private++`` method in an unsealed type has a signature that is identical to a ``++public++`` method declared in a base type.


=== Noncompliant code example

[source,csharp]
----
using System;

namespace MyLibrary
{
  public class Foo
  {
    public void SomeMethod(int count) { }
  }
  public class Bar:Foo
  {
    private void SomeMethod(int count) { } // Noncompliant
  }
}
----


=== Compliant solution

[source,csharp]
----
using System;

namespace MyLibrary
{
  public class Foo
  {
    public void SomeMethod(int count) { }
  }
  public sealed class Bar : Foo
  {
    private void SomeMethod(int count) { }
  }
}
----


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

This member hides '{0}'. Make it non-private or seal the class.


=== Highlighting

member declaration


'''
== Comments And Links
(visible only on this page)

=== relates to: S3434

=== on 22 May 2017, 13:19:56 Ann Campbell wrote:
\[~jeanchristophe.collet] RSPEC-2387 is already covered by C#. On the face of it, these two rules overlap nearly completely.

=== on 22 May 2017, 13:59:50 Jean-Christophe Collet wrote:
\[~ann.campbell.2] RSPEC-2387 only covers fields, this rule covers only methods without an override.

=== on 22 May 2017, 15:10:29 Ann Campbell wrote:
Okay, then RSPEC-3434 is the related RSpec, altho it's scope is different. I've added it as 'related'

endif::env-github,rspecator-view[]