Композиция во многих случаях может служить альтернативой множественному наследованию, причём именно в тех ситуациях, когда наследование интерфейсов “не работает”. Это бывает в случаях, когда надо унаследовать от двух или более классов их поля и методы.
Приведём пример. Пусть у нас имеются классы Car (“Автомобиль”) , класс Driver (“Шофёр”) и класс Speed (“Скорость”). И пусть это совершенно независимые классы. Зададим класс MovingCar (“движущийся автомобиль”) как
public class MovingCar extends Car{
Driver driver;
Speed speed;
…
}
Особенностью объектов MovingCar будет то, что они включают в себя не только особенности поведения автомобиля , но и все особенности объектов типа Driver и Speed. Например, автомобиль “знает” своего водителя: если у нас имеется объект movingCar, то movingCar.driver обеспечит доступ к объекту “водитель” (если, конечно, ссылка не равна null). В результате чего можно будет пользоваться общедоступными (и только!) методами этого объекта. То же относится к полю speed. И нам не надо строить гибридный класс-монстр, в котором от родителей Car, Driver и Speed унаследовано по механизму множественного наследования нечто вроде машино-кентавра, где шофёра скрестили с автомобилем. Или заниматься реализацией в классе-наследнике интерфейсов, описывающих взаимодействие автомобиля с шофёром и измерение/задание скорости.
Но у композиции имеется заметный недостаток: для получившегося класса имеется существенное ограничение при использовании полиморфизма. Ведь он не является наследником классов Driver и Speed. Поэтому полиморфный код, написанный для объектов типа Driver и Speed, для объектов типа MovingCar работать не будет. И хотя он будет работать для соответствующих полей movingCar.driver и movingCar.speed, это не всегда помогает. Например, если объект должен помещаться в список. Тем не менее часто использование композиции является гораздо более удачным решением, чем множественное наследование.
Таким образом, сочетание множественного наследования интерфейсов и композиции в подавляющем большинстве случаев является полноценной альтернативой множественному наследованию классов.
- Интерфейсы используются для написания полиморфного кода для классов, лежащих в различных, никак не связанных друг с другом иерархиях.
- Интерфейсы описываются аналогично абстрактным классам. Так же, как абстрактные классы, они не могут иметь экземпляров. Но, в отличие от абстрактных классов, интерфейсы не могут иметь полей данных (за исключением констант), а также реализации никаких своих методов.
- Интерфейс определяет методы, которые должны быть реализованы классом-наследником этого интерфейса.
- Хотя экземпляров типа интерфейс не бывает, могут существовать переменные типа интерфейс. Такая переменная - это ссылка. Она дает возможность ссылаться на объект, чей класс реализует данный интерфейс.
- С помощью переменной типа интерфейс разрешается вызывать только методы, декларированные в данном интерфейсе, а не любые методы данного объекта.
- Композиция – это описание объекта как состоящего из других объектов (отношение агрегации, или включения как составной части) или находящегося с ними в отношении ассоциации (объединения независимых объектов). Композиция позволяет объединять отдельные части в единую более сложную систему.
- Наследование характеризуется отношением “is-a” (“это есть”, “является”), а композиция - отношением “has-a” (“имеет в своём составе”, “состоит из”) и “use-a” (“использует”).
- Сочетание множественного наследования интерфейсов и композиции в подавляющем большинстве случаев является полноценной альтернативой множественному наследованию классов.
Типичные ошибки:
Глава 9. Дополнительные элементы объектного программирования на языке Java
Потоки выполнения (threads) и синхронизация
В многозадачных операционных системах (MS Windows, Linux и др.) программу, выполняющуюся под управлением операционной системы (ОС), принято называть приложением операционной системы (application), либо, что то же, процессом (process). Обычно в ОС паралельно (или псевдопаралельно, в режиме разделения процессорного времени) выполняется большое число процессов. Для выполнения процесса на аппаратном уровне поддерживается независимое от других процессов виртуальное адресное пространство. Попытки процесса выйти за пределы адресов этого пространства отслеживаются аппаратно.
Такая модель удобна для разграничения независимых программ. Однако во многих случаях она не подходит, и приходится использовать подпроцессы (subprocesses), или, более употребительное название, threads . Дословный перевод слова threads - “нити”. Иногда их называют легковесными процессами (lightweight processes), так как при прочих равных условиях они потребляют гораздо меньше ресурсов, чем процессы. Мы будем употреблять термин “потоки выполнения”, поскольку термин multithreading – работу в условиях существования нескольких потоков,- на русский язык гораздо лучше переводится как многопоточность. Следует соблюдать аккуратность, чтобы не путать threads с потоками ввода-вывода (streams).
Потоки выполнения отличаются от процессов тем, что находятся в адресном пространстве своего родительского процесса. Они выполняются параллельно (псевдопараллельно), но, в отличие от процессов, легко могут обмениваться данными в пределах общего виртуального адресного пространства. То есть у них могут иметься общие переменные, в том числе – массивы и объекты.
В приложении всегда имеется главный (основной) поток выполнения. Если он закрывается – закрываются все остальные пользовательские потоки приложения. Кроме них возможно создание потоков-демонов (daemons), которые могут продолжать работу и после окончания работы главного потока выполнения.
Любая программа Java неявно использует потоки выполнения. В главном потоке виртуальная Java-машина (JVM) запускает метод main приложения, а также все методы, вызываемые из него. Главному потоку автоматически даётся имя ”main”. Кроме главного потока в фоновом режиме (с малым приоритетом) запускается дочерний поток, занимающийся сборкой мусора. Виртуальная Java-машина автоматически стартует при запуске на компьютере хотя бы одного приложения Java, и завершает работу в случае, когда у неё на выполнении остаются только потоки-демоны.
В Java каждый поток выполнения рассматривается как объект. Но интересно то, что в Java каждый объект, даже не имеющий никакого отношения к классу Thread, может работать в условиях многопоточности, поскольку в классе Object определены методы объектов, предназначенные для взаимодействия объектов в таких условиях. Это notify(), notifyAll(), wait(), wait(timeout) –“оповестить”, “оповестить всех”,“ждать”, “ждать до истечения таймаута”. Об этих методах будет рассказано далее.
Почему бывают нужны потоки выполнения? Представьте себе программу управления спектрометром, в которой одно табло должно показывать время, прошедшее с начала измерений, второе – число импульсов со счётчика установки, третье – длину волны, для которой в данный момент идут измерения. Кроме того, в фоновом режиме должен отрисовываться получающийся после обработки данных спектр. Возможны две идеологии работы программы – последовательная и параллельная. При последовательном подходе во время выполнения алгоритмов, связанных с показом информации на экране, следует время от времени проверять, не пришли ли новые импульсы со счётчиков, и не надо ли установить спектрометр на очередную длину волны. Кроме того, во время обработки данных и отрисовки спектра следует через определённые промежутки обновлять табло времени и счётчиков.