@oop_ru

Страница 27 из 785
Sergei
13.12.2016
05:38:53
гм

а интерфейс/поведение?

ожидается ли у них сколь-нибудь одинаковое поведение?

da horsie
13.12.2016
05:40:05
Т.е. в предке будет только конструктор и пара протектед членов

Google
da horsie
13.12.2016
05:40:13
интерфейс ваще разный

смысл примерно похожий

но интерфейс выделить нельзя

Sergei
13.12.2016
05:41:05
как-то не особо ясно, что мы получим хорошего, если отнаследуемся

da horsie
13.12.2016
05:41:13
но вот десяток строк кода будет одинаковый

то есть дублирование кода против неестественного наследования

что лучше?

в чат призывается @fes0r

походу лучше не наследоваться

но что делать с дублированием - хз

Sergei
13.12.2016
05:46:44
я не 100% улавливаю задачу, наверное, но положим у меня есть несто такое:

da horsie
13.12.2016
05:47:01
у меня превдомапперы

классы, аккаумулирующие набор методов для оперирования с одной таблицей в БД

Google
da horsie
13.12.2016
05:47:41
они каждый принимают db_connection как зависимость

Sergei
13.12.2016
05:48:24
покажи кода пример

da horsie
13.12.2016
05:48:26
но для них нет соответствующих моделей

Sergei
13.12.2016
05:48:29
не очень пока понимаю

da horsie
13.12.2016
05:49:05
class BookingMapper { /** * @var Connection */ private $connection; public function __construct(Connection $connection) { $this->connection = $connection; } /** * @param int $user_id * @param int $travel_id */ public function registerBooking(int $user_id, int $travel_id) { $insert = $this->connection->prepare( 'INSERT INTO bookings (user_id, travel_id) VALUES (:user_id, :travel_id) ON CONFLICT DO NOTHING' ); $insert->execute([ ':user_id' => $user_id, ':travel_id' => $travel_id, ]); }

Sergei
13.12.2016
05:49:59
и этот код нужно в нескольких классах иметь?

da horsie
13.12.2016
05:50:14
первые десять строчек одинаковые

в нескольких классах

Sergei
13.12.2016
05:55:15
можно их как-то выделить в метод или функцию?

по мне так оно довольно крепко похоже на вложенный объект или что-то вроде того , но не наследование

da horsie
13.12.2016
06:04:01
Ну я его убрал

Пусть будет дублирование

можно их как-то выделить в метод или функцию?
Ну это просто одинаковый конструктор и член класса. Больше ничего

Sergei
13.12.2016
06:06:51
в С++ я бы еще подумал нет ли там возможности применить template

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

da horsie
13.12.2016
06:09:15
а в дивном мире php есть трейты

можно их заюзать

Sergei
13.12.2016
06:09:32
подозреваю оно что-то похожее

da horsie
13.12.2016
06:10:08
только мне казалось странной идея иметь конструктор в трейте

но наверно ок

Google
Evgeniy
13.12.2016
06:10:55
в трейте можно абстрактный метод сделать

Sergei
13.12.2016
06:10:56
судя по тому что пишут в вашей документации (и как я это понял) - trait это прямо самое то для этого случая

Evgeniy
13.12.2016
06:11:00
getConnection()

и конструктор в трейте не придется описывать

da horsie
13.12.2016
06:11:57
getConnection()
ну так мне же так или иначе экхемпляр $connection надо передавать

все равно конструкто нужен получается

Evgeniy
13.12.2016
06:12:42
ну если все мапперы с одинаковыми зависямости

почему нет что то типо BaseMapper и там конструктор описанный ну или да трейты)

Evgeniy
13.12.2016
06:14:03
в трейте не будет конструктора

хотя да ничем)

da horsie
13.12.2016
06:14:07
ну будет protected function getConnection()

Evgeniy
13.12.2016
06:16:06
а чем это лучше?
у тебя допустим штук 10 маппперов с одинаковым конструктором и 2 маппера с одинаковым registerBook методом

тогда все 10 мапперов наследоваться от BaseMapper

а у 2 мапперов use RegisterBookTrait;

da horsie
13.12.2016
06:16:51
BaseMapper получается пустой

Evgeniy
13.12.2016
06:16:59
конструктор

da horsie
13.12.2016
06:17:01
он не определяет никакой интерфейс

интерфейс у него пустой

я не вижу смысла в наследовании, если интерфейс пустой

Google
Evgeniy
13.12.2016
06:17:41
ну не делай )

пиши конструктор в каждом классе

da horsie
13.12.2016
06:18:02
я сделал трейт с конструктором

Evgeniy
13.12.2016
06:18:10
ну сделай так)

но я бы сделал тогда 2 трейта

в одном конструктор в другом метод

и из 2 трейта включил бы 1

da horsie
13.12.2016
06:21:35
зачем метод?

Evgeniy
13.12.2016
06:21:39
чтобы там где надо только конструктор можно было юзать только его

и тогда метод getConnection абстрактный не нужен

da horsie
13.12.2016
06:22:02
чем плохо protected поле в классе?

Evgeniy
13.12.2016
06:22:22
сейчас покажу о чем я

http://pastebin.com/tdD0cxSG

da horsie
13.12.2016
06:26:04
понял

но это мне не подойдет, набор методов типа registerBooking разный у всех мапперов

Evgeniy
13.12.2016
06:26:44
а ну тогда да )

твой вариант лучше.

если что всегда сможешь к такому виду придти

da horsie
13.12.2016
06:29:04
Я продолжаю слушать Немчинского. Мое мение о нем улучшается. https://www.youtube.com/user/pro100fox2/playlists

Артур Евгеньевич
13.12.2016
15:16:50
а кто это такой вообще?

Google
Sergey
13.12.2016
15:17:11
Это - клевый дядька который публикует свои лекции

у него замечательные лекции по GRASP например, и в целом неплохие лекции по паттернам с разъяснениями откуда они появились и тд.

0x9d8e
14.12.2016
16:00:39
Люди. Есть mvc-фреймворк на php (yii2). Хочу логику моделей отделить от ActiveRecord. Допустим я создаю в app\models подкаталог (и подпространство) ActiveRecord и соответствующие классы моделей, наслеюущиеся от db\ActiveRecord располагаю там. Аналогичные классы с бизнес-логикой размещаю в app\models. То есть, допустим, есть у нас лягушки. И есть два класса: models\Frog и models\ActiveRecord\Frog. Экземпляры первого умеют прыгать, квакать и всё такое. А экземляры второго можно получать из базы и сохранять их туда-же. Внимание вопрос: стоит ли models\Frog унаследовать от models\ActveRecord\Frog или запилить что-то вроде декоратора/прокси (в смысле не наследоваться от ar\Frog а обращаться к нему из Frog)? В первом случае вроде всё проще, но насчёт отделения я не уверен. Во втором пользователь не сможет напрямую образаться к методам ActiveRecord (а значит если способ хранения изменится не придётся реализовывать весь интерфейс AR), но как-то всё усложняет.

da horsie
14.12.2016
18:50:54
Я бы вообще от AR отказался в пользу Data Mapper

0x9d8e
14.12.2016
18:55:18
Я бы вообще от AR отказался в пользу Data Mapper
В данном случае на AR будет быстрее сделать. При этом, разумеется, хотелось бы иметь возможность всё что касается хранения и персистентности безболезненно переделать полностью или для отдельных сущностей.

Aleh
14.12.2016
18:55:38
можно AR оставить, они организуют доступ к полям таблицы

Люди. Есть mvc-фреймворк на php (yii2). Хочу логику моделей отделить от ActiveRecord. Допустим я создаю в app\models подкаталог (и подпространство) ActiveRecord и соответствующие классы моделей, наслеюущиеся от db\ActiveRecord располагаю там. Аналогичные классы с бизнес-логикой размещаю в app\models. То есть, допустим, есть у нас лягушки. И есть два класса: models\Frog и models\ActiveRecord\Frog. Экземпляры первого умеют прыгать, квакать и всё такое. А экземляры второго можно получать из базы и сохранять их туда-же. Внимание вопрос: стоит ли models\Frog унаследовать от models\ActveRecord\Frog или запилить что-то вроде декоратора/прокси (в смысле не наследоваться от ar\Frog а обращаться к нему из Frog)? В первом случае вроде всё проще, но насчёт отделения я не уверен. Во втором пользователь не сможет напрямую образаться к методам ActiveRecord (а значит если способ хранения изменится не придётся реализовывать весь интерфейс AR), но как-то всё усложняет.
можешь сделать композицией class Frog { constructor(FrogDao $dao) { $this->dao = $dao; } } и дергать dao из твоего класса или вынести это вообще вне и потом мапить твой Frog на dao

0x9d8e
14.12.2016
20:45:16
можешь сделать композицией class Frog { constructor(FrogDao $dao) { $this->dao = $dao; } } и дергать dao из твоего класса или вынести это вообще вне и потом мапить твой Frog на dao
Вопрос в том как лучше: так или наследоваться? Несколько статей на эту тему прочёл, уже больше к твоему варианту склоняюсь.

Aleh
14.12.2016
20:45:29
наследоваться хуже

если ты передаешь в конструктор, то тестить легко

подсовывать разные реализации тоже легко

например запись в файл, в nosql

а зачем наследоваться? можешь прямо в AR писать все тогда )

ты все равно оооочень тесно свяжешь два класса

0x9d8e
14.12.2016
20:54:07
а зачем наследоваться? можешь прямо в AR писать все тогда )
не писать прямо в AR я решил ещё когда в прошлом проекте столкнулся с тем, что хранение стало негодным (там монструозный EAV был, по производительности протух), а заменить это дело никак: обращение к любому полю через эту хрень, всюду квери билде и т.д.

Aleh
14.12.2016
20:55:08
ага, вот видишь, ты хочешь ОТДЕЛИТЬ логику хранения от логики бизнеса

а наследование свяжет

Aleh
14.12.2016
20:55:53
0x9d8e
14.12.2016
20:56:47
В принципе да, лучше вообще спрятать AR поглубже и в работать по-максимуму в терминах бизнес-логики, а не всяких полей в базе.

Так пожалуй и сделаю. Потом если что будет просто как-то переделать.

da horsie
14.12.2016
20:57:49
ну в идеале модель не подозревает о dao
В коде, который ты написал, дао передается в конструктор модели как зависимость. Т.е. модель зависит от дао.

Страница 27 из 785