Program to implementation супротив Program to interface

[Nemo_c]

В книге ActionScript 3 Design Patterns автор рассматривает два подхода к ????, я пока не понял к чему эти два подхода (видимо к составлению композиции).

В общем Автор рассматривает два подхода Program to implementation и Program to interface

Иллюстрируется это дело таким кодом

//SpaceWarrior.as
package {

	interface SpaceWarrior {

		function useWeapon():void;

	}
}

//Alien.as
package {

	public class Alien implements SpaceWarrior {

		function Alien() {

			//Constructor
		}

		public function useWeapon():void {
			trace("Zaaaapp!!!");
		}
	}
}

//Earthling.as
package {

	public class Earthling implements SpaceWarrior {

		function Earthling() {
			//Constructor
		}

		public function useWeapon():void {
			trace("Ka Boom!!!");
		}
	}
}

//Main.as
package {

	import flash.display.Sprite;

	public class Main extends Sprite {

		public function Main() {

			//Program to implementation

			var alien:Alien=new Alien  ;
			alien.useWeapon();

			//Program to interface

			var spaceWarrior:SpaceWarrior=new Earthling  ;
			spaceWarrior.useWeapon();
		}
	}
}

Так же автор говорит что в сферическом вакууме Program to implementation хуже чем Program to interface.

вопросы

1. Чем подход Program to interface лучше другого.
2. В чём фишка каждого подхода ?
3. Чем чревато на практике использование каждого из подходов?
4. Кто из форумчан что предпочитает и почему.

(мнение автора книги мне понятно, хотелось бы услышать альтернативные мнения)

[BlooDHounD]

1. а в чём разница?
2. а в чём разница?
3. а в чём разница?
4. запретить автору книги писать книги.

[etc]

1. Ничем, они просто разные, зависит от конкретной задачи;
2. Второй позволяет в одной переменной хранить ссылки на любой объект, реализующий соответствующий интерфейс. Зато первый делает доступными остальные свойства конкретного экземпляра без обязательного каста;
3. Ничем;
4. И то и другое именно там, где оно подходит лучше.

з. Ы. Я бы не стал читать книгу автора, который поленился поставить скобки при вызове конструкторов объектов. Да, можно опустить скобки, но лучше так не делать.

[BlooDHounD]

__etc, ну да .. это болие развёрнуто особенно тонко подметил ЗЫ мой 4й пункт

[terbooter]

Автора зовут William B. Sanders.
Он довольно много книг наваял. В часности еще книги про FMS2 и FMS3. У меня к его книжному творчеству двоякое отношение. С одной стороны, мне близок его способ мышления и желание объяснить все на простых примерах (это его фишка minimalist example, кстати на его блоге лучший такой экзэмпл по pureMVC). C другой стороны,
книгу то тоже надо писать , контракты с издательствами, сроки и тд. И получается что 50-80 процентов его книг набиты гольной коньюктурой - пустое пересказывание очевидных вещей.

Завтра посмотрю к чему эти два подхода, дома книжки нет.

[Fernando Costa]

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

Вот это очень полезный момент

[Gaen]

Всё разбивается, когда нужно одновременно наследоваться от кого-то, и реализовывать дополнительный интерфейс. Единственный выход - самому прописать интерфейс того, от кого наследуешься. Я про Sprite говорю.

Если хочется унаследовать несколько классов от спрайта, и потом навесить на них общий интерфейс, то нифига не получится. Или получится, но на костылях.

http://flasher.ru/forum/showthread.php?t=115336

[Nemo_c]

Сообщение от Fernando Costa

Вот это очень полезный момент

Полезный момент для чего?, и при каких обстоятельствах?