Проектирование интерфейса и реализации

[kode]

а я разве говорил что их нельзя использовать вместе?

-~{}~ 30.05.08 13:50:

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

алсо, для группировки по реализации не обязательно использовать абстрактные классы, например:

interface Car {
	public function startEngine();
	public function stopEngine();
}

class PetrolEngine {

}

class DieselEngine {

}

class FordFocus extends PetrolEngine implements Car {

}

class OpelCorsa extends DieselEngine implements Car {

}

абстрактный класс нужен если нужно что-то получать от потомков (например получить год выпуска), те:

abstract class PetrolEngine {
	protected $lastCapitalRepair;

	public function isNeedCapitalRepair(){
		return ($lastCapitalRepair+5 < $this->getProductionYear());
	}

	abstract public function getProductionYear();
}

class FordFocus extends PetrolEngine implements Car {

	protected $buildYear;


	public function getProductionYear(){
		return $this->buildYear;
	}
}

хотя можно было просто передать год производства через конструктор

 

[atv]

а я разве говорил что из нельзя использовать вместе?

так и я не говорил что ты это говорил

Я как пример привёл...

 

[CRL]

В ходе осмысления работы Фабрики возник вопрос по типизации результата. Например, в прототипе (интерфейсе) описан метод query($data). Данный метод принимает запрос к стораджу и возвращает результат. Результат возвращается в специфичной для реализации форме: например, для SQL-запроса это ресурс, для запроса к текстовому файлу - это строка. Фабрика создает объект нужной реализации, который потом используется в программе; в ходе использования этого объекта я вызываю метод $obj->query($current_data) и получаю... что? То есть понятно, что я получаю некий сет-результат, но для того, чтобы понять, что именно это за сет, придется провести его анализ уже в приложении, чего делать не хотелось бы. Иыми словами, как и где должен описываться результат работы методов реализаций, чтобы с ним можно было работать, не выполняя проверки типа в самом приложении? Вопрос касается не столько моей ситуации со стороджами, сколько такой проблемы в целом - важно понять принцип.

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

interface IStorage
{
    public function query($data);
    ...
}

или

interface IStorage
{
    public function query(DataSet $data);
    ...
}

И в случае типизированного, и в случае нетипизированного описания параметров, они всё равно остаются формальными, т.е., в реализации я должен передавать в экземпляр реализации некую структуру, а уже сама реализация эту структруру распарсивает. Что-то типа такого:

$data = array();
$data["dbhost"] = "localhost";
...
$current_storage = new StorageFactory($data);

или, если формальный параметр типизирован:

$data = new DataSet;
$data->host = "localhost";
...
$current_storage = new StorageFactory($data);

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

-~{}~ 02.06.08 17:27:

Надеюсь, тема еще не закрыта и обсуждение продолжится...