[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: SOLID
Страницы: 1, 2, 3, 4
Arh
Как раз вчера класс DIC запилил =)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
bestxp
ну я же говорю в идеале) и AR вообще не должен иметь GRUD опций =) это как раз таки нарушение принципа единой ответственности =)

просто это уже копаеться глубже и когда начинаешь проектировать по модели DDD понимаешь этот косяк. когда тебе нужно разделить предметную область от инфраструктуры

Как пример можешь посмотреть Doctrine по сути модель не связана с инфраструктурой, хоть через репозиторий и сохраняеться в бд, и являеться отображением таблицы на модель, тот самый ORM , но из-за того что ответственности разделены он выглядет более правильным =)

и опять же я привел пример ножик - резать, если у тебя НожОткрывашка - тогда резать и открывать, это его ответственность залежнная предметной областью применения

как-то так, там чем глубже копаешь тем больше пздца местами =) но DDD в которое все выливаеться, позволяет уже говорить на одном языке с "заказчиком" не оперируя всякими программисткими терминами =) но это из другой песни =)

как и говорил в идеале одна ответственность которая заложена объекту, если ты от этого ножа захочешь что бы он сохранялся в бд или сам себя ложил в ножны это уже грубое нарушение принципа единой ответственности
twin
Цитата (bestxp @ 2.10.2015 - 09:07)
если у тебя НожОткрывашка - тогда резать и открывать, это его ответственность залежнная предметной областью применения

Ну я это и имел ввиду, когда писал название класса Складной Нож. Это для DDD норма мне кажется. Если заказчику нужен именно складной ножик для пикника, как то глуповато делать еще отдельно открывашку и штопор. Все равно он их всегда будет вместе носить.

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Arh
twin
Тут какая то путаница с запятыми.
Цитата
Нельзя заставлять подкласс, а клиента просить подкласс, делать то, что не умеет суперкласс.


Если прочитать так.
Цитата
Нельзя заставлять подкласс, ... делать то, что не умеет суперкласс.

То получается что мы не можем расширять классы.
На примере PDO.
Есть класс, который наследует PDO, подключает конфиг с настройками и возвращает настроенный объект PDO.
Получается при наследовании, мы не можем добавить какой то метод, например метод, который возвращает конфиг, потому что главный класс этого не умеет.

$db->getConfig('password'); //получается так нельзя?
$db->query("SELECT ...");


_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Arh
twin
Цитата
$man = new Kolya();
$man->selectWife(new Tania);


А как быть, если Таня не может сварить суп без помощи Коли, а Коля не может помогать Тане варить суп без наличия Тани?)
Грубо говоря класс кэшеширования использует класс настроек что бы понимать куда и как кэшировать, но при этом класс настроек кэширует свои настройки с помощью класса кэша.


class Config {

function __construct(Cache $cache){}

}


class Cache {

function __construct(Config $config){}

}


Для этого есть какие то паттерны?)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
twin
Цитата (Arh @ 4.10.2015 - 19:45)
Тут какая то путаница с запятыми.

Да, сложноватая для восприятия фраза получилась. Просто попытался запихать все в одно предложение.

Вот так перефразировал:
Цитата
Нельзя подкласс заставлять делать то, что не умеет суперкласс.
А клиента просить подкласс делать то, что не умеет суперкласс.


Цитата (Arh @ 4.10.2015 - 19:45)
То получается что мы не можем расширять классы.

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

По этим двум строчкам слжно понять, что ты имеешь ввиду. Кроме того, у тебя геттер ничего не возвращает.

Но примерно понятно, где ты заблудился.

Расширять класс нельзя, меняя тип. Если ты отнаследуешься от PDO, а в наследнике переопределишь тип подключения на msqli_, то при всех равных прочих этот объект будет сложно использовать дальше.

Конечный объект сможет выполнить простой запрос, но с именнованными плэйсхолдерами уже нет, потому что тип был изменен.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Цитата (Arh @ 4.10.2015 - 20:13)
Грубо говоря класс кэшеширования использует класс настроек что бы понимать куда и как кэшировать, но при этом класс настроек кэширует свои настройки с помощью класса кэша.

Чет не понял. У тебя рекурсия получается) Змея, которая ест сама себя.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Игорь_Vasinsky
так... теперь я не понял - согласно принципу Лискоу - подкласс может быть расширен или нет?

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
twin
Конечно может. Не может быть использован другой тип обработки данных.

Вот с PDO я же написал. Только наверное лучше наоборот было. Если базовый класс использует драйвер mysqli_, то в наследнике нельзя делать возможность использования именнованных плэйсхолдеров. Потому что mysqli_ их не поддерживает. И если исключить посредника, то работать ничего не станет.

Если хочется использовать именнованные плэйсхолдеры, нужно и базовый класс выбирать или разрабатывать с такой возможностью. А конфигу там получить или еще чего натворить - дело десятое. Это дело наследника.

Это паттерны проектирования. Их трудно понимать тем, кто пишет алгоритмы, а не системы. Ну по принципу Наполеона: сначала ввяжемся в драку, потом разберемся. Система сначала проектируется, выбирается то, что лучше подходит, потом только пишутся алгоритмы.

Расширить класс, это не значит дописать по ходу пьессы. Расширить, это значит добавить возможности. На этапе проектирования.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Игорь_Vasinsky
twin
Хорошо, на примере PDO

в 5.4 ввели трейты - это псевдо возможность множественного наследования

если мы будем дополнительно использовать класс с плейсхолдерами как дополнение к PDO - это будет противоречит принципу?

ничего сложного я не вижу в применение паттернов и принципов - главное правильно их понимать.

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
kaww
Цитата (twin @ 4.10.2015 - 23:41)
Расширять класс нельзя, меняя тип. Если ты отнаследуешься от PDO, а в наследнике переопределишь тип подключения на msqli_

Что значит изменить тип на msqli_? Расширим базовый класс:
class MyDb extends PDO

MyDb все так же имеет тип PDO:
if(MyDb implements PDO)
Цитата (twin @ 4.10.2015 - 23:41)
Конечный объект сможет выполнить простой запрос, но с именнованными плэйсхолдерами уже нет, потому что тип был изменен.

Строго говоря этого и PDO не сможет. Это делает PDOStatement. Т.е. чтобы MyDb не мог "с именнованными плэйсхолдерами", следует, например, изменить тип возвращаемого значения метода query (на не PDOStatement и не расширяющий его), что нарушает LSP
twin
Цитата (Игорь_Vasinsky @ 5.10.2015 - 03:09)
если мы будем дополнительно использовать класс с плейсхолдерами как дополнение к PDO - это будет противоречит принципу?

Нет, если не будешь использовать врапперы, которые изменяют типы данных. Допустим поменяешь местами константы PARAM_INT и PARAM_STR.
Цитата (kaww @ 5.10.2015 - 03:19)
Что значит изменить тип на msqli_? Расширим базовый класс:

Так смотря как расширишь. Если переопределишь метод коннекта и указатель, используя mysqli_, то кирдык.
Цитата
следует, например, изменить тип возвращаемого значения метода query (на не PDOStatement и не расширяющий его), что нарушает LSP
Вот это я и имел ввиду, только на уровне коннекта.

Я согласен, пример неудачный. Тут ближе к теме.
Цитата (twin @ 5.10.2015 - 02:47)
Вот с PDO я же написал. Только наверное лучше наоборот было. Если базовый класс использует драйвер mysqli_, то в наследнике нельзя делать возможность использования именнованных плэйсхолдеров. Потому что mysqli_ их не поддерживает. И если исключить посредника, то работать ничего не станет.

[/list]

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
Еще раз изменил формулировку вывода:

Нельзя подкласс заставлять исправлять то, что делает суперкласс.
И нельзя клиента просить подкласс делать то, что не умеет суперкласс.


Так понятнее должно быть.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Arh
twin
Цитата
Нельзя подкласс заставлять исправлять то, что делает суперкласс

Другими словами "Нельзя переопределить метод" =)

Цитата
А нельзя клиента просить подкласс делать то, что не умеет суперкласс.

А клиента нельзя или а нельзя клиента?
Я сто раз прочитал но так и не понял как построено предложение.

"нельзя просить клиента"
"нельзя просить подкласс что то делать"
"нельзя клиентУ просить подкласс, который..."

Цитата
Кроме того, у тебя геттер ничего не возвращает.

В примере возвращает пароль, echo забыл написать.

Цитата
Чет не понял. У тебя рекурсия получается) Змея, которая ест сама себя.

Это из реального примера =)
Написал класс настроек, написал класс кэширования, начал кэшировать настройки, потом спустя время захотел настраивать кэш, а тут рекурсия.
Получается класс кэш будет не настраиваемый, так же как и Коля не сможет помогать готовить суп.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
kaww
Цитата (Arh @ 5.10.2015 - 08:00)
Другими словами "Нельзя переопределить метод"

Нет, не так.
Цитата (Arh @ 5.10.2015 - 08:00)
В примере возвращает пароль, echo забыл написать.

Возврат - это return
Цитата (Arh @ 5.10.2015 - 08:00)
Получается класс кэш будет не настраиваемый

class Config{

/**
*
@var Cache
*/

private $_cache;

privat $_config;

public function setCache(Cache $cache)
{
$this->_cache = $cache;
}

public function getConfig()
{
if (null === $this->_config) {
if(!$this->_cache || ($this->_config = $this->_cache->load('key'))) {
$this->_config = $this->_load();
}
}

return $this->_config;
}
}


class Cache {

function __construct(Config $config){}

}
Быстрый ответ:

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