Почему частная часть класса рассматривается как интерфейс?

Question

Я читаю книгу Грэди Буча Объектно-ориентированный анализ и дизайн с приложениями, третье издание. В странице 94, Буча сказала, что:

Мы можем Furthur разделит интерфейс класса на четыре части:

1. публика: декларации, которая доступна для всех клиентов
2. защиты: объявление который доступен только для самого класса и его подклассов
3. Закрыто: объявление, доступное только для самого класса
4. Пакет: объявление, доступное только классам в одном пакете

Я могу понять, почему защищенное заявление можно рассматривать как интерфейс, becuase подклассов класса клиент этого класса, тоже.

Но я не понимаю, почему заявление private можно рассматривать как интерфейс. Пожалуйста, просветите меня.

Answer 1

Я прочитал его еще раз, и это очень просто, это просто сказать это, что интерфейс может быть частным, защищенный, пакет и общественности и после того, что он говорит вам, за то, что вам это нужно, и как вы их используете :)

пример для частного интерфейса: интерфейс, который может быть реализован только внутри класса!

public class MyClass 
{ 
    private interface IFoo 
    { 
     int MyProp { get; } 
    } 

    private class Foo : IFoo 
    { 
     int _mamboNumber = 5; 
     public int MyProp { get { return _mamboNumber; } set { _mamboNumber = value; } } 
    } 

    private class FooSec : IFoo 
    { 
     int _mamboNumber = 10; 
     public int MyProp { get { return _mamboNumber; } set { _mamboNumber = value; } } 
    } 

    public static void Main(string[] args) 
    { 
     IFoo foo = new Foo(); 
     int fooProp = foo.MyProp; // return 5 
     IFoo foo2 = new FooSec(); 
     int foo2Prop = foo2.MyProp; // return 10 
    } 
} 

Answer 2

Но я не понимаю, почему private заявление можно рассматривать как интерфейс.

Частные объявления, как говорят, образуют интерфейс, поскольку у них есть свои собственные клиенты, хотя и не так много, как защищенный или открытый интерфейс класса.

Эти клиенты:

1. Сам класс. Очевидно, что вы можете получить доступ к своим членам класса «private» из любого статического или нестатического метода любого экземпляра вашего класса.
2. Внутренние классы вашего класса. Помните, что внутренние классы вашего класса имеют доступ ко всем членам вашего класса, включая private.
3. (In C++)Друзья вашего класса.Хотя из цитаты в вашем вопросе, я вижу, что в книге, о которой вы говорите, речь идет о Java, я все равно добавлю этот элемент для полноты, так как ваш вопрос не помечен java. В C++ есть ключевое слово friend, которое позволяет программисту класса назначать некоторые другие классы и/или функции в качестве друзей этого класса. Такие «дружественные» классы и функции имеют доступ ко всем членам класса, включая private, и поэтому они также являются клиентами частного интерфейса класса.

Таким образом, может быть полезно иметь четко определенный частный интерфейс, поскольку он упрощает и упрощает реализацию методов в вашем классе, его друзьях и внутренних классах для других разработчиков, которые могут работать на вашем классе.

---

Но все-таки, я нахожу «интерфейс для себя» довольно странно.

Интерфейс сам по себе может быть важен. Вот небольшой мысленный эксперимент.

Представьте, что два разработчика, Алиса и Боб, работают над тем же классом, который называется MissileLauncher. Боб несет ответственность за реализацию логики для очистки стартовой площадки после запуска ракеты. (Это частный механизм, клиенты открытого или защищенного интерфейса могут не запрашивать очистку пэда - это просто деталь реализации этого класса).

Так, Боб знает, что, чтобы очистить стартовую площадку один имеет декрементировать missleCounter, установите currentMissle в null и вызвать pendingOperations.remove(this.currentOp). В коде класса есть только одно место, где это нужно сделать. Боб мог инкапсулировать все это в частный метод под названием clearLaunchingPad(), но он решил, что логика слишком проста, поэтому он не беспокоился.

Несколько месяцев спустя Алиса обнаруживает, что есть еще один сценарий, в котором необходимо очистить стартовую площадку. Если бы Боб подумал о надлежащем «интерфейсе к себе», Алиса могла бы просто написать вызов this.clearLaunchingPad() и сделать это через несколько секунд. Но, как мы знаем, Боб не сделал этого. Теперь Алисе нужно пойти и спросить Боб, что ей нужно сделать, чтобы очистить площадку. Но прошло уже несколько месяцев, Боб больше не помнит детали реализации, или, что еще хуже, он может быть уволен с тех пор (и не удивительно, учитывая его культуру кодирования).

Итак, теперь Алисе нужно копать код MissileLauncher и попытаться выяснить, что ей нужно сделать, надеясь, что у Боба хотя бы порядочность, чтобы прокомментировать его код.

Таким образом, несколько секунд превращаются в несколько часов и несколько возможных ошибок (Алиса может забыть позвонить pendingOperations.remove(this.currentOp) в конце), так как Боб не обратил внимания на дизайн интерфейса этого класса.