[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Наследование VS Композиция
gidrosoldat
Доброе время суток, как жизнь? )
Изучая ООП, но пока не используя его на практике появляются глупые вопросы!
Вот например один из них: в каких случаюх использовать наследование, а в каких делать композицию (создавать объект класса в другом классе, например Strategy pattern) ?
В обоих случаях я буду иметь доступ к методам и свойствам.
В наследовании:
- одноименные методы и свойства перезапишутся (но можно же использовать parent::).
- сработает только один конструктор/деструктор (в композиции оба).
При использовании композиции создаются два объекта, видимо и ресурсов больше кушается, но где то читал, что этот способ более гибкий.
Кто нибудь может этот момент популярно объянить? (ссылку на книги давать надо и так их читаю).

И еще не по теме.
Чем отличается (интерфейс и использование абстрактного класса с такой же целью):
abstract class One {
abstract function showOne();
abstract function showTwo();
}
class Two extends One {
public function showOne() {
echo '1<br>';
}
}

от:
interface One {
function showOne();
function showTwo();
}

class Two implements One {
public function showOne() {
echo '1<br>';
}
}

В обоих случаях PHP потребует создать метод showTwo().



Спустя 1 час, 18 минут, 4 секунды (12.07.2011 - 18:25) Winston написал(а):
Цитата (gidrosoldat @ 12.07.2011 - 17:07)
Чем отличается (интерфейс и использование абстрактного класса с такой же целью):

Тоже хотел бы узнать.
Мне кажется тем, что в интерфейсе нельзя объявить свойства? huh.gif

Спустя 9 минут, 58 секунд (12.07.2011 - 18:35) tatti написал(а):
абстрактные классы нельзя обьединять по несколько штук и использовать, как интерфейсы

Спустя 3 часа, 5 минут, 7 секунд (12.07.2011 - 21:40) Gradus написал(а):
PHPprogramer, и не только, в интерфейсе ничего не должно быть кроме прототипов в отличие от абстрактных классов.
Цитата
В наследовании:
- сработает только один конструктор/деструктор (в композиции оба).

такой же ответ
Цитата
(но можно же использовать parent:smile.gif.

Спустя 1 час, 20 минут, 8 секунд (12.07.2011 - 23:00) gidrosoldat написал(а):
Цитата (tatti @ 12.07.2011 - 15:35)
абстрактные классы нельзя обьединять по несколько штук и использовать, как интерфейсы

А как интерфейсы объеденять можно и зачем?

Спустя 4 минуты, 35 секунд (12.07.2011 - 23:05) Invis1ble написал(а):
имеется ввиду, насколько я понимаю, что класс может реализовывать более одного интерфейса:
class someClass implements interface1, interface2 {
// ......
}

Спустя 55 минут, 32 секунды (13.07.2011 - 00:00) tatti написал(а):
Цитата (Invis1ble @ 12.07.2011 - 20:05)
имеется ввиду, насколько я понимаю, что класс может реализовывать более одного интерфейса:
<pre class="sh_sourceCode" rel="php"><span class="sh_keyword">class</span> someClass <span class="sh_keyword">implements</span> interface1<span class="sh_symbol">,</span> interface2 <span class="sh_cbracket">{</span>
    <span class="sh_comment">// ......</span>
<span class="sh_cbracket">}</span></pre>

именно. одна из причин - ПХП не поддерживает множественное наследование
interface Inter
{
const a = "This is constant value";

public function disp();
}

class A implements Inter
{
function show()
{
echo self::a."<br/>";
}

public function disp()
{
echo "Inside the disp function";
}
}


$a = new A();
$a->show();
$a->disp();
если остались вопросы, советую почитать это

Спустя 7 часов, 58 минут, 19 секунд (13.07.2011 - 07:58) linker написал(а):
gidrosoldat
Например есть класс который работает с файлами
class File 
{
}
Что такое файл - это банальный поток информации, в поток можно писать, можно читать из него. Но у файла есть другие важные параметры: размер, права и т.д. Это разные составляющие, поэтому должны описывать в разных местах. Т.к. множественного наследования нет, то приходится использовать интерфейсы
interface Io
{
public function wtite($buffer);
public function read();
}

interface Filesystem
{
public function chmod($access);
public function size();
}

class File implements Io, Filesystem
{
...
}
Это так, для примера.

Спустя 3 часа, 45 минут, 49 секунд (13.07.2011 - 11:44) gidrosoldat написал(а):
linker, разве это полноценная замена множественному наследованию? Таким образом мы максимум что можем это унаследовать список методов, но никак не сами методы!
Если уж говорить о суррогате множественного наследования - так это композиция. В одном объекте класса вызываем объекты других классов (количество неограниченно) и делаем с ними что хотим. Или я не так все понял?
Invis1ble, tatti сэнкс

Спустя 2 часа, 45 минут, 41 секунда (13.07.2011 - 14:30) linker написал(а):
gidrosoldat
Это было к вопросу
Цитата
А как интерфейсы объеденять можно и зачем?

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

Спустя 2 часа, 14 минут, 8 секунд (13.07.2011 - 16:44) gidrosoldat написал(а):
linker
... Если уж говорить о суррогате множественного наследования - так это композиция. ...

Спустя 16 часов, 10 минут, 21 секунда (14.07.2011 - 08:54) linker написал(а):
Я бы это вообще никак не называл, ни суррогат, ни подобие. Пока я не могу написать так:
class OneClass
{
public $oneProp = 0;
public function oneFunc() {}
}


class TwoClass
{
public $twoProp = 0;
public function twoFunc() {}
}


class MyClass extends OneClass, TwoClass
{
public function func()
{
$this->oneProperty = 1;
$this->twoProperty = 2;
$this->oneFunc();
$this->twoFunc();
}
}
все извраты с паттернами не представляют собой никакой ценности.

Спустя 4 часа, 55 минут, 36 секунд (14.07.2011 - 13:50) gidrosoldat написал(а):
linker, то есть сам ты паттернов не используешь?

Спустя 1 час, 2 минуты, 27 секунд (14.07.2011 - 14:52) linker написал(а):
Использую, но без излишеств.

Спустя 2 минуты, 18 секунд (14.07.2011 - 14:55) gidrosoldat написал(а):
linker, какие если не секрет?

Спустя 16 часов, 22 минуты, 6 секунд (15.07.2011 - 07:17) linker написал(а):
Singletone, Observer, есть ещё фишки, возможно они тоже являются паттернами.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.