Если вдаваться в трудности перевода, то перевод слова Plain как «Плоский», более отражает суть и поведение объекта — простой и без наследования.
Плоский объект для меня — добрый объект :) Кому как удобнее :)
Извиняюсь за глупые вопросы. Возможно, автор статьи (@vkhorikov) подскажет.
Но можно привести пример POCO с логикой, чтоб он не нарушал SRP, и не был VO?
Будет ли единственным отличием POCO и VO иммутабельность последнего?
Можно ли вообще обойтись без термина POCO, ограничившись DTO (объекты без логики) и VO (объекты с тривиальной логикой)?
Вопрос в том, что такое логика.
Если рассматривать например даты, то не вижу проблем добавить методов работы с самими датами.
Но если брать какой-нибудь объект типа «товар», неужели это нормально создавать класс в котором будут методы по добавлению товаров в БД, отправки их по сети, получения связанных сущностей типа всех покупателей? Не будет ли это перегружать класс, и создавать проблем с тестированием, распараллеливанием, поддержкой?
Мне всегда казалось, что Value Object — простые иммутабельные объекты типа дат или денег. Никакой логики в них быть не должно, заисключением, разве что, логики сравнения и определения равества. Они как бы строительные кирпичики для Entity, Business Objects, DTO и пр.
У Вас в кругах Эйлера так и нарисовано Value Object ⊂ POCO. Какой же это Plain Object, если он с логикой? POCO (POJO, PODS) — это принцип организации данных, пассивные структуры. DTO — это роль, которую данные выполняют (Transfer).
Расскажите, пожалуйста, зачем нужна кодогенерация с использованием IL?
Если для оптимизации, почему не удобнее наиоблее критичные вещи реализовать с помощью c/c++ и делать unmanaged вызовы? Ведь это должно работать быстрее.
Какие задачи решаются кодогенерацией?
Другими словами — почему мне нужно тратить время на это? :)
хороший тест на научное мышление, если помнить про принцип фальсифицируемости и знать про когнитивное искажение «Предвзятость подтверждения», то задача решается легко.
> К сожалению, привыкнуть к “вертикальной” мышке очень тяжело, так что даже советовать не будем. :)
Да у вас просто нет таких в наличии!
Давно уже хочу купить вертикальную мышь, но даже в Москве это можно сделать только под заказ.
Завезите уже нормальных в ценовом диапазоне до 10 000 рублей, думаю, быстро раскупят.
Видео симпотичное, но слово комбат реально режет слух.
И управление геймпадом — это скорее минус. Влияние консоли очень сильно потрит геймплей последних PC RGP.
И это печально.
Когда одни открывают свои патенты и тем самым совершают прорыв в области автомобилестроения, другие создают еще более нелепые патенты.
Чтож, если я раньше фанатов Apple считал просто дураками, которые повелись на рекламу, то теперь я считаю их идейными врагами, раз они рублем поддерживают подобное поведение Apple.
Какое будущее ждет космонавта по завершении карьеры?
Как государство поддерживает космонавтов в отставке? Какая пенсия выплачивается? Есть ли какие-то бонусы?
Какая поддержка космонавтам оказывается при получении производственных травм или при получении инвалидности?
Коментарий, проясняет суть вопроса лучше чем статья :)
Сказано не в обиду автору, автор тоже млодец.
Плоский объект для меня — добрый объект :) Кому как удобнее :)
Но можно привести пример POCO с логикой, чтоб он не нарушал SRP, и не был VO?
Будет ли единственным отличием POCO и VO иммутабельность последнего?
Можно ли вообще обойтись без термина POCO, ограничившись DTO (объекты без логики) и VO (объекты с тривиальной логикой)?
Если рассматривать например даты, то не вижу проблем добавить методов работы с самими датами.
Но если брать какой-нибудь объект типа «товар», неужели это нормально создавать класс в котором будут методы по добавлению товаров в БД, отправки их по сети, получения связанных сущностей типа всех покупателей? Не будет ли это перегружать класс, и создавать проблем с тестированием, распараллеливанием, поддержкой?
Мне всегда казалось, что Value Object — простые иммутабельные объекты типа дат или денег. Никакой логики в них быть не должно, заисключением, разве что, логики сравнения и определения равества. Они как бы строительные кирпичики для Entity, Business Objects, DTO и пр.
У Вас в кругах Эйлера так и нарисовано Value Object ⊂ POCO. Какой же это Plain Object, если он с логикой? POCO (POJO, PODS) — это принцип организации данных, пассивные структуры. DTO — это роль, которую данные выполняют (Transfer).
Если для оптимизации, почему не удобнее наиоблее критичные вещи реализовать с помощью c/c++ и делать unmanaged вызовы? Ведь это должно работать быстрее.
Какие задачи решаются кодогенерацией?
Другими словами — почему мне нужно тратить время на это? :)
Да у вас просто нет таких в наличии!
Давно уже хочу купить вертикальную мышь, но даже в Москве это можно сделать только под заказ.
Завезите уже нормальных в ценовом диапазоне до 10 000 рублей, думаю, быстро раскупят.
С цветом платья-то не можем определиться!!!
И управление геймпадом — это скорее минус. Влияние консоли очень сильно потрит геймплей последних PC RGP.
Когда одни открывают свои патенты и тем самым совершают прорыв в области автомобилестроения, другие создают еще более нелепые патенты.
Чтож, если я раньше фанатов Apple считал просто дураками, которые повелись на рекламу, то теперь я считаю их идейными врагами, раз они рублем поддерживают подобное поведение Apple.
Аллоды… хорошая попыптка, но нет.
Как государство поддерживает космонавтов в отставке? Какая пенсия выплачивается? Есть ли какие-то бонусы?
Какая поддержка космонавтам оказывается при получении производственных травм или при получении инвалидности?
Положу пока на полку.