Как красиво решить это с помощью ООП?

Question

[m0Hze]

Ребзи, подскажите как это красиво решить, с точки зрения ООП.
Дан исходный класс, в котором есть 2 метода: save, delete.
Есть 2-N "типа" материалов, с которыми этот класс может работать. С каждым материалом можно проводить все эти действия, но с каждым нужно делать это по разному. Если подойти к задаче с точки зрения: вот так вот это будет работать, то можно сделать это так:

public function save($one,$type){
if($type == 'type_1'){
//some actions
}elseif($type == 'type_2'){
//else actions
}
}
..

Вполне логично, что это простой и действенный способ, и он долгие годы служил верой и правдой, но(!).
Теперь задача немного расширилась, и "типов" может быть больше чем 2, а следовательно допиливать код таким способом - не комельфо.
Вопрос: Как решить эту задачу с помощью современных техник ООП (интерфейсы, наследование, етц). Что бы для каждого типа можно было просто и легко делать расширение ф-ционала, скажем, добавлением нового класса.
Если вам не сложно, то можно с примерами кода.
// Забыл уточнить. Операции с методами происходят по одному и тому же алгоритму, меняются некоторые данные нужные для записи/чтения, работы по сети (разные параметры post' запроса).

Answer 1

[Павел Соловьёв]

наверно в вашем случае нужен паттерн проектирования Фабричный метод.

class MaterialFactory 
{
    public static function build($type)
    {
        // тут генерим путь до класса на основе его типа
        return new $className();
    }
}

class Material
{
    public function save()
    {
        // тут свои действия
    }
}

class SuperMaterial
{
    public function save()
    {
        // тут другие действия
    }
}

потом в вашем методе

public function save($one,$type){
     $obj = MaterialFactory::build($type);
     $obj->save();
}

но схему можно ещё улучшить, всё зависит от текущего вашего кода

Comments

[m0Hze]

Спасибо, на первый взгляд - то что нужно. Правда, я считал, что будет что-то вроде: Один класс общий для всех, MainClass, и его наследуют классы-типы, только вот не мог понять, как же будет производиться подбр нужного типа. А в вашем коде все ясно и понятно.

[Павел Соловьёв]

ну я и дописал, что можно реально расширяемую структуру сделать просто надо видеть ваш код, а ток то незачто, обращайтесь.

Можете подробнее почитать - devacademy.ru/posts/shablonyi-proektirovaniya-v-ph...

Answer 2

[andfadeev]

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

class A {
	void save(Material m) {
		m.save();
	}
	void delete(Material m) {
		m.delete();
	}
}


interface Material {
	void save();
	void delete();
}

class MaterialNumberOne  implements Material  {
	void save() {
		//делаем что нужно для первого материала
	}
	void delete() {
		//делаем что нужно для первого материала
	}
}

class MaterialNumberTwo  implements Material  {
	void save() {
		//делаем что нужно для второго материала
	}
	void delete() {
		//делаем что нужно для второго материала
	}
}


// юзаем так
public static void main(String[] args) {
	Material m1 = new MaterialNumberOne();
	Material m2 = new MaterialNumberTwo();

	A a = new A();
	a.save(m1);
	a.delete(m1);
	a.save(m2);
	a.delete(m2);
}

Comments

[m0Hze]

Спасибо. Но как по мне (нот а профф), как-то не красиво. Вариант с Фабричным методом понрвился больше. Но все равно, большое спасибо за уделенное время :)

Answer 3

[Александр Кубинцев]

interface StorableMaterial
{
    public function save();
}

class Material implements StorableMaterial
{
    public function save()
    {
        // ...
    }
}

class SuperMaterial implements StorableMaterial
{
    public function save()
    {
        // ...
    }
}

А затем в нужно смотреть тот класс, откуда дергается метод save() и работать там с абстракцией в виде интерфейса SavableMaterial, а не конкретным классом

Comments

[m0Hze]

Простите, можно более подробный пример, или же ссылку где о конкретно таком подходе можно быстренько почитать и вникнуть? Из вашего кода понятна логика работы с разными типами, но для меня пока что осталось загадкой, каким образом происходит "типизация"? Простите за тавтологию.

[Александр Кубинцев]

@m0Hze все зависит от конкретной задачи. Но допустим вы делаете классы для работы с кешем. Один для хранения в файлах, другой для memcached, третий для APC. Что их все объединяет? Один интерфейс. Допустим, что достаточно методов store и get.
Соответственно, использование кеша дальше можно делать через интерфейс. Например, пусть будет класс с методом делающий выборку статей для главной страницы сайта. Тогда можно используя DI-контейнер сперва с помощью фабричного метода установить конкретную реализацию кеша (скажем, исходя из параметров в конфигурационном файле), а далее в коде либо получать его напрямую, либо внедрять в методы или классы как интерфейс. Например:

class MainPage
{
.....
public function getRSSContent()
{
$cache = DI::get('cache');
$content = new FetchRSSFeed($cache);
}
}

class FetchRSSFeed
{
public function __construct(CacheInterface $cache)
{
....
if ($cache->read('something')) {
....
}
}
}

[Александр Кубинцев]

Описанное ближе всего к шаблону Composite, а про шаблоны вообще почитать можно тут https://github.com/domnikl/DesignPatternsPHP