Найдите 10 отличий :D

#99

Теперь последний штрих - справа мой вариант без перезаписанного свойства, но с отдельными методами для каждого свойства. Слева ваш - без перезаписываемого свойства, но с одним методом для всех свойств.

Думаю, тут зависит от вкуса или задачи - валидировать все свойства при любом изменении любого свойства, или валидировать лишь зависимые свойства, как в моём варианте. Если свойств много, то ваш метод Validate превращается в лапшу, а мои отдельные методы всё ещё сохранают читаемость.

Но если нужен признак валидности всего объекта, то у вас достаточно вызвать один метод, а мне - завести специальный метод на весь объект, где вызвать пачку моих отдельных методов. Или завести дополнительные поля типа bool isValidMaxValue для каждого свойства, в каждом отдельном валидирующем методе их устанавливать, а в общем валидирующем методе для всего объекта - считать их по типу bool isValidObject = isValidProp1 && isValidProp2 && isValidProp3...

Вобщем, совсем уж от сеттера избавляться не надо, т.к. на более глобальном уровне и ёмкость бака может измениться.

Не может. Может меняться конфигурация, т.к. можно вызывать конструктор бака с одним или с другим параметром (объемом). Однако объем бака - все равно не меняется.

А если всё таки может, то как тогда спроектировать свойство или параметр "объём бака"?

Допустим, у меня бак новой экспериментальной модели - с изменяемым объёмом. И в нём плещется топливо. И бак может изменить свой объём прямо во время движения или по мере заправки. НАДА!!

Кстати, нашёл ещё один минус в единственном методе Validate на весь класс. Если свойства взаимозависимы, то нужно соблюдать порядок их валидации и присвоений. Если это всё в одном методе, а свойств много, то надо перетасовывать валидации ВСЕХ свойств. А если взаимозависимые свойства сгруппированы в отдельные методы валидации, то перетасовывать надо будет только в этих методах, что куда проще. Сами же эти отдельные методы валидации могут быть применены для всего объекта в любом порядке. Но это так, планы на дальнейшее развитие.

Вы умеете мыслить абстрактно

Похоже у нас совершенно разное определение абстрактного мышления.

То, что хочется вам, что то типа этого – а ну быстро копать яму от забора и до обеда.

Или с большой лупой ползать по земле пытаясь найти нору по следам жителя, вместо того чтобы осмотреть всё пространство с гораздо большей высоты.

Я написал, чего хочу

В итоге то выяснилось, что хотелки и исполнение несколько другие на самом деле, чем ожидалось.

Да и хотелки то совершенно странные.

А вы не пытаетесь улучшить его

Так улучшать то особо и нечего. Когда видишь «неправильную» / непонятную архитектуру нужно разобраться вначале в ней. Уже много раз попадалось, вроде всё правильно сделано и работает, но… не в том месте.

«Это неправильные пчёлы! И они, наверное, делают неправильный мёд!»

и почему я не делаю так, как привыкли вы

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

В этом нет смысла. Но это лишь одно место, где пришлось бы так усложнять.

Опять таки, смотря кому, для того кто будет следующий на правку это было бы более понятно. И не нужно ничего усложнять

Так смотрелось бы немного по другому

param.AddMaxValue(mod.Value)

Вы же не можете взять в голову задачу лишь из-за смущающего вас названия свойства

Нет, работа системы видится абсолютно дикой.

хотя уже 10 раз объяснено, что это такое и зачем так сделано

Эти все "объяснения" лежат на самом нижнем уровне и они не объясняют а все лишь пытаются объяснить зачем нам хочется так приспосабливаться к тому что уже есть. А вот какого так есть, так и осталось непонятным.

Вам бы это больше помогло?

Абсолютно нет, достаточно было понять что на самом деле хотелось сказать. Объект типа "А" и объект типа "Б" было даже более понятно

А куда это применить и как назвать - дело десятое.

Опять таки, с какого уровня смотреть.

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

А тот кто дом проектировал говорит - так первый ящик вообще ни в одну дверь не войдет, а второй превышает номинальную расчётную нагрузку на перекрытия.

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

т.к. там может быть любая валидация, а не только приведение к диапазону

Для меня термин валидация выглядит скорее так

https://ru.wikipedia.org/wiki/Вали�%...

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

Что делать после этого - шаг номер 2

Хотя да, подобрать название для совмещенных двух шагов непросто.

Я написал, чего хочу

В итоге то выяснилось, что хотелки и исполнение несколько другие на самом деле, чем ожидалось.
Да и хотелки то совершенно странные.

Вот два последних примера на картинке удовлетворяют мои хотелки с первой страницы.

У вас и волательность не волательность, и валидация не валидация... )))

Я уже писал - контрол, который автоматически приводит данные к заданному валидацией диапазону - валидирует эти данные или нет?

У вас и волательность не волатильность, и валидация не валидация

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

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

Нет конечно - он приводит данные к заданному валидацией диапазону. А то что один из шагов и есть собственно валидация данных, не даёт нам основания называть все операции вместе валидацией данных.

Иманна. Валидация это проверка. Которая или возвращает true/false отвечая на вопрос"верны ли данные", или бросает исключение. Но никак не изменяет данные.

Хотим привести к "верному" состоянию, называем хотя бы "makeValid". В немецком используют глагол "plausibilisieren"

Ладно-ладно, пусть будет любая -ация, хоть охренибилизация. Код-то от этого не изменится. Свойства тоже как хотите называйте - максВелью, хераксВелью. "Каррент велью не должно быть больше херакса" - звучит? В коде там от этого тоже ничего не поменяется. Главное, что код работает как мне нужно, а переименовать я потом могу по вкусу. Сейчас меня устраивает.

)))

Кстати, насчёт "назови А или B" - там на всяких Stackoverflow всякие Джоны Скиты и Эрики Липперты жалуются, что некоторые называют классы и объекты A и B вместо скажем Animal и Tiger или foo и bar. Да кто они такие ваще против тутошних титанов?! Привыкли понимаешь там на своём гейзападе узко мыслить, а мы тут доморощенные математики абстрактные - нам подавай "треугольник а бэ цэ равен треугольнику а-штрих бэ-штрих цэ-штрих". Мене, мене, текел, упарсин.

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

Допустим, у меня бак новой экспериментальной модели - с изменяемым объёмом. И в нём плещется топливо. И бак может изменить свой объём прямо во время движения или по мере заправки. НАДА!

Любые ограничения можно ввести при помощи интерфейсов.

Ты высасываешь примеры из пальца "на лету". Банальный пример, который бы тут подошел - XML де- сериализация параметров бака. В этом случае необходимы и геттер и сеттер на объекте. Решение простое - надо работать на уровне интерфейсов.

Кстати, нашёл ещё один минус в единственном методе Validate на весь класс. Если свойства взаимозависимы, то нужно соблюдать порядок их валидации и присвоений. Если это всё в одном методе, а свойств много, то надо перетасовывать валидации ВСЕХ свойств. А если взаимозависимые свойства сгруппированы в отдельные методы валидации, то перетасовывать надо будет только в этих методах, что куда проще. Сами же эти отдельные методы валидации могут быть применены для всего объекта в любом порядке.

В твоей логике есть один изъян :)

Предположим у нас есть 3 своства: A, B и C. При этом A и B зависят от C.

С твои подходом нужно сделать 3 + 1 функцию: ValidateA, ValidateB, ValidateC и Validate

Выглядеть это будет так:

private void ValidateA ()
{
   ValidateC();
   a = .... 
}
private void ValidateB ()
{
   ValidateC();
   b = .... 
}
private void ValidateC ()
{
   c = .... 
}
public void Validate ()
{
   ValidateC();
   ValidateA();
   ValidateB();
}

Очевидно, что ValidateC будет вызвана аж целых 3 раза :) Можно сократить количество вызовов ValidateC до двух, но тогда будет неявная валидация С.

Можно конечно пойти еще дальше и сократить количество вызовов до 1, но тогда придется писать дополнительный код.

Ну и все это безобразие должно конкурировать с этим:

public void Validate ()
{
   // a and b depends on c. Thats'y c must be validated before!!!
   c = .... <span class="redactor-invisible-space"></span>
   a = .... <span class="redactor-invisible-space"></span>
   b = ....
}

Я не знаю что тут надо перетасовывать, но простота кода при моем подходе, как мне кажется, очевидна :)

Любые ограничения можно ввести при помощи интерфейсов.
Ты высасываешь примеры из пальца "на лету". Банальный пример, который бы тут подошел - XML де- сериализация параметров бака. В этом случае необходимы и геттер и сеттер на объекте. Решение простое - надо работать на уровне интерфейсов.

Почему именно интерфейсов? Почему не включать объекты, добавляя функциональности? Типа

List<BaseProperty> Properties

где BaseProperty может быть скол угодно сложным или просто базовым классом для добавления той или иной функциональности.

Мне интерфейсы напоминают модель классов в С++ - надо иметь так называемые заголовки и реализацию, желательно в разных файлах. Лишний гемор и усложнение, если применять интерфейсы именно для цели навешивания функциональности.

Я не знаю что тут надо перетасовывать, но простота кода при моем подходе, как мне кажется, очевидна :)

Мне надо попробовать дальше поприменять. Может ваш подход и окажется лучшим. Пока его и оставлю - пусть будет один метод.

Хотя справедливости ради, метод-то уже не один - из-за наследования минимум он имеет перегрузку. Но в подходе с кучей методов, если добавить наследование и перегрузки, мусора и лапши будет ещё больше. У меня пока лишь два класса в иерархии наследования, поэтому пока что всё выглядит не таким уж сложным.

Почему не включать объекты, добавляя функциональности?

Потому что на уровне абстракций все выглядит четче :)

Я уж не говорю о тестируемости.

List<BaseProperty> Properties
    

где BaseProperty может быть скол угодно сложным или просто базовым классом для добавления той или иной функциональности.

Тут есть одна проблема - со списком пропертей можно сделать все, что угодно.

Можно конечно полагаться на разумность того, кто будет использовать, но лучше все таки ограничить полет его фантазии до

IEnumerable<IBaseProperty> Properties { get; }

Ну пусть даже этот вариант. Но чем плохо? В Unity 3D вообще именно так функциональность к объектам и цепляется.

Я не знаю что тут надо перетасовывать, но простота кода при моем подходе, как мне кажется, очевидна :)

И это всё, конечно, очень красиво. Но не жизнеспособно. Как только класс становится немножко сложнее и таскает пару десятков полей, случается ой. И дело даже не в том, что один метод валидации внезапно становится строк так 300, с этим можно бороться, а с тем, что при изменении одного параметра мы валидируем и 29 остальных. Хотя они не менялись. И понеслась. Метод начинают "оптимизировать". Типа - а если вот это так, то вот эту часть можно не проверять. И он превращается в такой клубок if-else что легче повеситься, чем разобраться.

А вот если валидировать после каждого изменения, то валидация остаётся простой. Поменялся А - я проверяю не стал ли он больше Д и не меньше 0.19 * Ф. И ускоряется.

Только вот в прошлом месяце поменяли такой "супер-валидатор" на валидацию после каждого изменения. Время исполнения одного загрузочного теста уменьшилось с 130 секунд до 28. За время выполнения теста валидация вызывалась примерно 200 тысяч раз.

ПС и теперь надо уговорить поменять валидатор для целого кластера "договор". Код вынесен в классы. Вызывается при каждом изменении (блядь!). В сумме примерно 6 тысяч строк. В гуях есть одна кнопочка, при нажатии на которую для одного договора валидация вызывается 3,5 тысяч раз. 40 секунд ждём реакции. По профайлеру из низ 39 проводим в валидаторах. Ужасные истории на ночь. (№;%:!"% привычно откликнулось эхо).

Когда число пропертей разрастается, нужно рефакторить. Для малого числа удобнее в одном валидаторе на весь класс, для большого - как-то группировать зависимые свойства и валидировать их в группах их зависимости. Ну и общий валидатор для всего объекта тоже обычно присутствует. Главное, что нет одного универсального решения на все случаи, которое одновременно простое и для малого числа сущностей, и при сколь угодном масштабировании. В лучшем случае что можно придумать, чтобы не захламлять - использовать сторонние универсальные валидаторы, типа тех же атрибутов и фреймворков валидации для них, которые делают всю грязную работу, а ты лишь проверяешь свойства типа Property.Valid.

Отвлечёмся немного на другие "рахитекурты". Ещё одно подтверждение, что многие паттерны-шматтерны это костыли для старых говноязыков и куцых фреймворков, служащие для обхода их ограничений и недостатков. Когда чел городит репозиторий, фасад и юнит оф ворк вокруг Entity Framework, хочется спросить, из какого тифозного загона он сбежал. Какой-нибудь плюсовик поди? ))) А он ведь это на автоматизме уже делает, начиная любой новый код.

Вот что это за херь, которая делает из двух строчек одну на любую операцию? А если разобраться, то SaveChanges можно вызывать не на каждый чих, а пореже, в конце группы операций, и тогда вообще получается, что весь ниипаца-паттерн у нас - просто однострочные обёртки над уже существующим из коробки функционалом. Но для желающих накодить километры неподдерживаемой лапши "только я знаю, как это работает", чтобы забронзоветь и дотянуть до пенсии на этом месте - сойдёт.

Да вы просто неправильно его готовите, чуваки. В нашем паттерне главное отличие начинается с пятой строчки снизу, двадцатый знак слева в списке основных свойств нашего паттерна. А так он - копия другого паттерна, только сбоку. Там ниже совсем упоротые примеры по переименованию методов изкоробочного фреймворка и оборачиванию их вызовов. Уникальный шматтерн, мать его! И ведь все эти гении где-то работают, зачастую не на последних должностях. По сути всё сводится к тому, что приходя на работу куда-то ты либо соглашаешься с говнокодом местного гуру и пытаешься подражать его писулькам, либо валишь с позором из этой конторы. Искать там логику, какие-то перспективы - бесполезное занятие, зря тратящее нервы. И чем дольше в чей-то говнокод будешь погружаться, тем больше будет сужаться твоё мировоззрение и подходы.