))Безусловно маркеры - НЕ главное, скорее даже одиозное применение интерфейсов (впрочем же адобовцы его не чураются). Может быть, их прямое назначение не вызывате у меня вопросов, поэтому заострил внимание на маркерах - автор спрашивал "зачем надо".
Цитата:
|
но ведь мне по аналогии придется во все 15 классов дописывать конструкцию типа "implements IClass".
|
Вы не поняли. В том то и дело, что Вам надо будет только пометить 4 класса, что они "могут расширяться по горизонтали", а с остальными 11 делать ничего не нужно. Точно также как два адобовских класса имплементят IBitmapDrawable и только их (и их наследников) можно передавать в BitmapData::draw(). Все остальные классы вовсе не помечены каким-нибудь IDontBitmapDrawable. Их "НЕ" содержится в том что они НЕ реализуют IBitmapDrawable. Вот если бы Вы заводили поле - то да, у всех 15-ти, иначе как спросить?)) Через hasOwnProperty? Куда уж кривее - заводить поле, чтобы спрашивать не его значение, а - есть ли само поле))).
Основная задача интерфейсов, кроме собственно гарантии наличия методов - объединение того, что не может наследоваться от одного предка, как в случае с DisplayObject и BitmapData. В нередких случаях, когда есть какой-то контейнер (пакер), в который могут добавляться РАЗНЫЕ объекты (виджеты), имеющие интерфейс - т.е. методы - для работы в этом контейнере, Интерфейсы незаменимы. Многоуровневое меню, где пунктом может быть как кнопка, так и другое меню; статусБар - эта панелька внизу многих приложений, в которой помещается несколько Информеров - координаты мыши, подсказка к инструменту, индикатор прогресса, иконки дополнительных служб. Вы стали бы писать отдельный класс, чтобы все это унаследовать от него? А если таких интерфейсов понадобится пять - создавать цепочку из пяти суперклассов? Прелесть Интерфейсов в том что один Класс может реализовывать их несколько сразу, плюс наследовать.