Интернет-журнал "Домашняя лаборатория", 2007 №9 - Журнал «Домашняя лаборатория»

class="cite">

public class ClassA

{

    public ClassA(string f1, int f2)

    {

        fieldA1 = f1; fieldA2 = f2;

    }

    public string fieldA1;

    public int fieldA2;

    public void MethodA()

    {

        Console.WriteLine ("Это класс A");

        Console.WriteLine ("поле1 = {0}, поле2 = {1}",

            fieldA1, fieldA2);

    }

    public static void StatMethodA()

    {

         string s1 = "Статический метод класса A";

         string s2 = "Помните: 2*2 = 4";

         Console.WriteLine(s1 + " ***** " + s2);

     }

}

Построим теперь класс B — клиента класса A. Класс будет устроен похожим образом, но в дополнение будет иметь одним из своих полей объект inner класса А;

public class ClassB

{

     public ClassB(string f1A, int f2A, string f1B, int f2B)

     {

         inner = new ClassA(f1A, f2A);

         fieldB1 = f1B; fieldB2 = f2B;

      }

      ClassA inner;

      public string fieldB1;

      public int fieldB2;

      public void MethodBl()

      {

          inner.MethodA ();

          Console.WriteLine("Это класс В");

          Console.WriteLine ("поле1 = {0}, поле2 = {1}", fieldB1, fieldB2);

      }

}

Обратите внимание: конструктор клиента (класса B) отвечает за инициализацию полей класса, поэтому он должен создать объект поставщика (класса A), вызывая, как правило, конструктор поставщика. Если для создания объектов поставщика требуются аргументы, то они должны передаваться конструктору клиента, как это сделано в нашем примере.

После того как конструктор создал поле — объект поставщика — методы класса могут использовать этот объект, вызывая доступные клиенту методы и поля класса поставщика. Метод класса B — MethodB1 начинает свою работу с вызова: inner.MethodA, используя сервис, поставляемый методом класса а.

Расширение определения клиента класса

До сих пор мы говорили, что клиент содержит поле, представляющее объект класса поставщика. Это частая, но не единственная ситуация, когда класс является клиентом другого класса. Возможна ситуация, когда метод клиентского класса локально создает объект поставщика, вызывает его методы в собственных целях, но по завершении метода локальный объект заканчивает свою жизнь. Еще одна возможная ситуация — когда объекты поставщика вообще не создаются ни конструктором, ни методами класса клиента, но клиент вызывает статические методы класса поставщика. Оба эти варианта демонстрируют следующие два метода класса B;

public void MethodB2()

{

     ClassA loc = new ClassA("локальный объект A",11);

     loc.MethodA ();

}

public void MethodB3()

{

      ClassA.StatMethodA();

}

Дадим теперь расширенное определение клиента.

Определение 3. Класс B называется клиентом класса A, если в классе B создаются объекты класса A — поля или локальные переменные — или вызываются статические поля или методы класса A.

Отношения между клиентами и поставщиками

Что могут делать клиенты и что могут делать поставщики? Класс-поставщик создает свойства (поля) и сервисы (методы), предоставляемые своим клиентам. Клиенты создают объекты поставщика. Вызывая доступные им методы и поля объектов, они управляют работой созданных объектов поставщика. Клиенты не могут ни повлиять на поведение методов поставщика, ни изменить состав предоставляемых им полей и методов, они не могут вызывать закрытые поставщиком поля и методы класса.

Класс-поставщик интересен клиентам своей открытой частью, составляющей интерфейс класса. Но большая часть класса может быть закрыта для клиентов — им незачем вникать в детали представления и в детали реализации. Сокрытие информации вовсе не означает, что разработчики класса не должны быть знакомы с тем, как все реализовано, хотя иногда и такая цель преследуется. В общем случае сокрытие означает, что классы-клиенты строят свою реализацию, основываясь только на интерфейсной части класса-поставщика. Поставщик закрывает поля и часть методов класса от клиентов, задавая для них атрибут доступа private или protected. Он может некоторые классы считать привилегированными, предоставляя им методы и поля, недоступные другим классам. В этом случае поля и методы, предназначенные для таких vip-персон, снабжаются атрибутом доступа internal, а классы с привилегиями должны принадлежать одной сборке.

В заключение построим тест, проверяющий работу с объектами классов а и в;

public void TestClientSupplier ()

{

   ClassB objB = new ClassB("AA",22, "BB",33);

   objB.MethodB1 ();

   objВ.MethodB2();

   objВ.MethodB3 ();

}

Результаты работы этого теста показаны на рис. 18.1.

Рис. 18.1. Клиенты и поставщики

Сам себе клиент

Зададимся вопросом, может ли класс быть сам себе клиентом, другими словами, может ли поле класса быть объектом описываемого класса? Другой, не менее интересный вопрос — могут ли два класса быть одновременно клиентами и поставщиками друг для друга? Ответы на оба вопросы положительны, и подобные ситуации типичны и не являются какой-либо экзотикой.

Первая ситуация характерна для динамических структур данных. Элемент односвязного списка имеет поле, представляющее элемент односвязного списка; элемент двусвязного списка имеет два таких поля; узел двоичного дерева имеет два поля, представляющих узлы двоичного дерева. Эта ситуация характерна не только для рекурсивно определяемых структур данных. Вот еще один типичный пример.

В классе Person могут быть заданы два поля — Father и Mother, задающие родителей персоны, и массив children. Понятно, что все эти объекты могут быть того же класса Person.

Не менее часто встречается ситуация, когда классы имеют поля, взаимно ссылающиеся друг на друга. Типичным примером могут служить классы Man и woman, первый из которых имеет поле wife класса Woman, а второй — поле husband класса Man.

Заметьте, классы устроены довольно просто — их тексты понятны, отношения между классами очевидны. А вот динамический мир объектов этих классов может быть довольно сложным, отношения между объектами могут быть запутанными; для объектов характерны не только любовные треугольники, но и куда более сложные фигуры.

Наследование

Мощь ООП основана на наследовании. Когда построен полезный класс, то он может многократно использоваться. Повторное использование — это одна из главных целей ООП. Но и для хороших классов неизбежно наступает момент, когда необходимо расширить возможности класса, придать ему новую функциональность, изменить интерфейс. Всякая попытка изменять сам работающий класс чревата большими неприятностями — могут перестать работать прекрасно работавшие программы, многим клиентам класса вовсе не нужен новый интерфейс и новые возможности. Здесь-то и приходит на выручку наследование. Существующий класс не меняется, но создается его