@oop_ru

Страница 431 из 785
 
Aleh
16.12.2017
10:09:13
Ну так да)

 
И я его знаю

 
Mykola
16.12.2017
10:52:42
отличие как раз таки в том что при "вызове" ты должен знать кого вызывать, а ивенты - наоборот, тебе не интересно кто будет обрабатывать событие и будет ли вообще
тут ты прав 100%, но есть нюанс

 
иногда ты событие бросаешь и как-бы знаешь кого ты вызываешь

Google
 
Mykola
16.12.2017
10:53:26
не надо так)

 
Sergey
16.12.2017
10:53:37
И я его знаю
ну короч разница кому принадлежит интерфейс по сути) и тут можно про инверсию зависимостей вспомнить о чем @Lividgreen говорил) правда думаю он чуть в другом ключе..

 
не надо так)
да, в этом случае лучше явно сделать взаимодействие)

 
Mykola
16.12.2017
10:57:42
тут все упирается в вопрос есть ли у тебя "лишние знания", когда ты событие бросаешь

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

 
Sergey
16.12.2017
11:01:19
одним из признаков является нужда в "приоритете" обработчиков
о да, помню нашу пьяную дискуссию тогда в баре)

 
и в целом это проблема не того, кто ивент кидает, а скорее того, что обработчики ивентов оказывают эффект друг на друга

 
как ты относишься к тому что ивент листенер кидает свой ивент?

 
ну то есть пришел ивент А, и вот тебе листенер продьюсит ивент Б

 
вместо того что бы выстраивать приориеты

 
Артур Евгеньевич
16.12.2017
11:02:57
Авот кстати еще такой вопрос. При событиях нам нужно в модель инджектить выбрасывальщик событий, т.е по сути нам нужна зависимость от инфраструктурного слоя напрямую...чет не очень хорошо

 
Не микрсоервисы. Если на слабосвязанные бандлы например делить, которые в рамках одного приложения, я думаю тоже это можно назвать сервис ориентирвоанной архитектурой. Ну и сервисы м воспринимаем как "что то делающий деятель", то есть в процессе размышления ставим действия а не данные. Ну и пришел я к SOA vs ES потмоу что ты сказал что без событий не получается грамотный whole object. То есть еще раз, вопросполучается как с whole object создать бизнес транзакцию без событий. Т.е. например получаем фотку от юзера и если там порнуха, то отклоняем ее, заносим полььзователя в бан на месяц, и отсылаем емэй в ментовку например) 1.Анемичная модель: Сервис фотоприемщик, в которые инджектится фотоМодератор, в который инджектятся сервисФотореагировщик, и уже реализация этого реагирвоика содержит вызов сервисов отправки емайла, бана и т.д. Заметим, если всё делать через DI это будет ее все очень расширемо и легко кастомизируемо за счет полиморфизма в релализации интерфейса разными классами под каждую ситуацию(порно фотка, недостаточный размер фотки, мат на фотке и т.д) Все понятно, хорошо читается и расширяется. Если есть к вашей ide плагин для нормлаьной работы с di. 2. сОбытийна модель. ну вот произошло событие загрузки фотки(кстати кто его должен выбросить, фотка сама? или у нас какой то есть сущность для этого другая)? И далььше она обрабатывается всеми штуками. Тут у мнея опыта немного, так тчо не смогу подробно расписать, но идея мне понятна. 3. whole object без событий или то что я называл богатой доменной моделью. Вообще хз что куда пихать? вот дернули метод контроллера загрузить фотку, и дальше что опять нам нужен какой то фотоприемщик, но это насколько я понимаю плохое назваание для сущности(так как отглагольное, и по сути тот же сервис из пункта 1). Но вот допустим приняли мы фотку, и дальше какое ее взаимодествие и с кем? Я не могу понять как бить ответственности между сущностями предметной области, их вообще выделять? Если в анемичной или событийной модели я просто рассматирваю данные(объект фотки) котоырй проходит через разные фильтры/преобразоователи и с которым в итоге что то происходит - могу это ясно изобразить и в коде и на бумаге. Тот тут у меня ступор
@fes0r ты кстати прочитал мое сочинение?)

 
Aleh
16.12.2017
11:08:50
Авот кстати еще такой вопрос. При событиях нам нужно в модель инджектить выбрасывальщик событий, т.е по сути нам нужна зависимость от инфраструктурного слоя напрямую...чет не очень хорошо
Не, достаточно сложить все доменные ивенты в коллекцию, а по инфраструктурному коммиту транзакции по очереди запустить, например

Google
 
Aleh
16.12.2017
11:12:05
ну короч разница кому принадлежит интерфейс по сути) и тут можно про инверсию зависимостей вспомнить о чем @Lividgreen говорил) правда думаю он чуть в другом ключе..
В обоих случаях принадлежит тому, кто вызывает?

 
Конечно вопрос что значит "принадлежит"

 
Sergey
16.12.2017
11:12:33
Авот кстати еще такой вопрос. При событиях нам нужно в модель инджектить выбрасывальщик событий, т.е по сути нам нужна зависимость от инфраструктурного слоя напрямую...чет не очень хорошо
не обязательно

 
@fes0r ты кстати прочитал мое сочинение?)
вот собираюсь)

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

 
да, хз что значит "принадлежит")

 
Aleh
16.12.2017
11:13:55
да, хз что значит "принадлежит")
Ну тут можно посмотреть с точки зрения как и кого затрагивает изменение интерфейса

 
Хотя хз

 
Sergey
16.12.2017
11:15:05
@fes0r ты кстати прочитал мое сочинение?)
я тебе рекомендовал уже почитать Object design: roles, responsibilities and calloboration?

 
я вот сейчас перечитывавю... оч годная книжка

 
> Finding good candidate objects isn't a topic that has received a lot of attention. Early object design books, including Designing Object-Oriented Software, speak of finding objects by identifying things (noun phrases) written about in a design specification. In hindsight, this approach seems naïve. Today, we don't advocate underlining nouns and simplistically modeling things in the real world. It's much more complicated than that. Finding good objects means identifying abstractions that are part of your application's domain and its execution machinery. Their correspondence to real-world things may be tenuous, at best. Even when modeling domain concepts, you need to look carefully at how those objects fit into your overall application design.

 
http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf

 
Артур Евгеньевич
16.12.2017
11:39:39
я тебе рекомендовал уже почитать Object design: roles, responsibilities and calloboration?
неа, ща погугл

 
http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf
Это она и есть или это конспкт по ней?

 
Sergey
16.12.2017
11:42:01
тип краткая выжимка

 
andretshurotshka?❄️кде
16.12.2017
21:50:48
привет

 
melancholiac
16.12.2017
21:50:58
привет
nyanpasu!

 
Kirill
16.12.2017
21:54:14
Крч. Есть класс пциент и клсс врач. Стоит ли создавать класс персона, а потом наследовать его будет класс врач и пациент, т.к. у них есть общие поля: имя, фамилия, отчество и как бы все. Стоит ли ради этого создавать класс персон?

 
Adel
16.12.2017
21:54:37
нет

 
имя фамилия и отчество - Value Object

Google
 
Kirill
16.12.2017
21:55:05
А можно обосновать? Или ссылку почитать ппро это?

 
melancholiac
16.12.2017
21:55:09
keep it simple

 
da horsie
16.12.2017
21:57:43
Крч. Есть класс пциент и клсс врач. Стоит ли создавать класс персона, а потом наследовать его будет класс врач и пациент, т.к. у них есть общие поля: имя, фамилия, отчество и как бы все. Стоит ли ради этого создавать класс персон?
Композиция вместо наследования. Пусть врач и пациент будут, например, стратегиями поведения.

 
Kirill
16.12.2017
21:59:01
Спасибо

 
da horsie
16.12.2017
21:59:50
Тогда ты сможешь сделать врача без имени, например, консилиум. И пациента, скажем, черепашку.

 
Наследование очень сложно использовать правильно, как нам тут недавно Алан Кей напомнил :)

 
Kirill
16.12.2017
22:04:58
Я тут подумал

 
Композиция не оч подходит

 
Класс пациент будет содержать поле класса врач?

 
Ну бред же

 
Aliaksandr
16.12.2017
22:06:00
Ну так никто и не сказал, что пациент будет с полем врач.

 
Kirill
16.12.2017
22:06:02
Это вот класс двигатель и авто. Класс авто содержит поле класс двигатель

 
Здесь есть смысл композиции

 
da horsie
16.12.2017
22:06:20
Класс пациент будет содержать поле класса врач?
Нет. Это стратегия поведения.

 
Kirill
16.12.2017
22:06:29
Не совсем понял

 
da horsie
16.12.2017
22:06:41
Поведение тоже может быть частью агрегата

 
ООП не про материальный мир.

 
Kirill
16.12.2017
22:06:59
поведение это методы?

 
da horsie
16.12.2017
22:08:01
Нет. Ну представь стратегию в игре, например. Она описывает как ты реагируешь на внешние события. Она нематериальна.

 
Adel
16.12.2017
22:09:11
тызахотел делать общего предканаоснове того что у обоих есть ФИО. тебе же предложили заменить ее композицией. внедрить обоим свойствокласса ФИО. и не делать наследование просто изза тогочтоу них обоих одинаковое свойство есть

Google
 
da horsie
16.12.2017
22:09:43
Так же и тут. Стратегия врач описывает поведение: ставить диагноз, лечить, выписывать лекарства.

 
И потом, врач ведь тоже может болеть

 
Adel
16.12.2017
22:10:26
Так же и тут. Стратегия врач описывает поведение: ставить диагноз, лечить, выписывать лекарства.
ты домена даже не знаешь но уже все спроектировал :)

 
da horsie
16.12.2017
22:10:42
ты домена даже не знаешь но уже все спроектировал :)
Я привел пример.

 
И потом. Как это не знаю. Я посмотрел всего доктора Хауса, я теперь спец :)

 
Kirill
16.12.2017
22:12:04
тызахотел делать общего предканаоснове того что у обоих есть ФИО. тебе же предложили заменить ее композицией. внедрить обоим свойствокласса ФИО. и не делать наследование просто изза тогочтоу них обоих одинаковое свойство есть
То есть сделать класс фио и вставить этот класс в пациент и врач? Так это как наследование же

 
Adel
16.12.2017
22:12:20
композиция

 
Kirill
16.12.2017
22:12:20
Смысл не меняется

 
Ну да

 
Я понял, что композиция

 
Adel
16.12.2017
22:12:33
не отнаследоваться же я предлагаю

 
Kirill
16.12.2017
22:13:01
Так разницы никакой?

 
Один фиг класс с 3 полями

 
Буду я наследовать его

 
или делать композицию

 
Разница где?)

 
Adel
16.12.2017
22:13:35
но пациент и врач не связаны наследованием. это важно

 
Kirill
16.12.2017
22:13:55
А

 
Вот ща начал понимать

 
Adel
16.12.2017
22:15:44
чтобы длать общего предка у тебя должна быть веская причина. например ты делаешь игру про больницу. и оба этих класса - это просто юниты. которые бегают по больнице.. и чтото делают. но по-разному. тогда да. можно делать общего предка.

Google
 
Adel
16.12.2017
22:16:10
но если это информационная система больницы... там это совсем разныесущности

 
Kirill
16.12.2017
22:16:51
Спасибо

 
Я понял

 
f4rt~
16.12.2017
22:32:10
И потом. Как это не знаю. Я посмотрел всего доктора Хауса, я теперь спец :)
у бизнеса волчанка, сделайте ему мрт если ему станет лучше, прав я. Если он умрет — прав ты.

 
Kirill
16.12.2017
23:17:46
Уххх

 
Новый вопросик

 
Зачем этот общий класс фио вообще?

 
Пациент и врач капец разные класс

 
Я могу просто вписать каждому классу эти общие поля

 
И ничего не объединять

 
Не использовать композицию

 
da horsie
16.12.2017
23:22:41
Я могу просто вписать каждому классу эти общие поля
Можно и так. Зависит от языка и твоих задач.

 
Kirill
16.12.2017
23:22:50
Понял

 
Тип не обязательно?

 
da horsie
16.12.2017
23:28:30
Ну я ж не знаю твоих задач.

 
Aleh
16.12.2017
23:36:51
Зачем этот общий класс фио вообще?
http://wiki.c2.com/?PrimitiveObsession

 
f4rt~
16.12.2017
23:38:35
?

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