Само да не станеш като Егор Бугайенко, на него всичко му е антипаттърн. ORM is a perfect anti-pattern

Лисков понякога може да бъде коварен и подвеждащ, да разгледаме пример:

имаме метод за изчисляване на разстояния между две географски координати:

var p1 = new point(lat1, long1)
var p2 = new point(lat2, long2)

Distance(p1, p2)

Решаваме обаче че това не винаги стига и правим наследник в който имаме

var p1 = new point(lat1, long1, alt1)
var p2 = new point(lat1, long1, alt2)

Distance (p1, p2)

координатната система е еднаква, дименсиите са еднакви, всичко изглежда 6, в един светъл момент получаваме проблеми защото в базовия метод дистанцията е смятана в евклидово пространство, а в по-модерния - с отчитане на земната геометрия. Първичните тестове със сравняване на резултати са били с допустима точност, защото са се смятали разстояния в квартали, но проекта скалира и почват да се смятат разстояния между градове в различни държави.

Тук секса е че ако сме противници на Лисков просто ще разкараме базовия клас, ще си напишем собствен и ще сменим навсякъде, като ще преизчислим дори и първичните данни. Т.е. в случая анти-солида се оказва правилния начин на работа.

Courvoisier

Само да не станеш като Егор Бугайенко, на него всичко му е антипаттърн. ORM is a perfect anti-pattern

Не съм толко харизматичен а и си давам сметка че всеки 'антипатърн' го има щото благодарение на него поне тоя дето го е измислил е сложил ядене на масата или е ебал образно казано, ся доколко е универсално приложим и кое представлява 'чист' такъв патърн (около което патърнаджиите изглежда обичат да обсесират) е друг въпрос :)

Тоя Егор специално ако го питаш всичко е анти-патърн, даже патърните.

Егор е топ. Трябва да се изучава в училище

Тея хора дето говорят за патърни треа се трепят.

Rabin

Евлампи

А Лисков казва точно това - подаването на инстанция на наследник не трябва да да чупи кода както синтактично така и семантично което ако си наясно с по-общата идея на полиморфизма е очевидно - всеки наследник или добавя или имплементира базова функционалност по специфичен начин, но това трябва да не променя желаното поведение на програмата, тоест децата да поддържат ПОНЕ нещата поддържани от родителите а тези които ги правят по специфичен начин да са семантично коректни, не просто овъррайднатият метод да е синтактично коректен но и смислово да прави квото базата е посочила като път към светлото бъдеще

Т.е. имаме си 3 думички ено и също нещо. Лисков, open-closed principle, и полиморфизъм?

Леко, че както си се запътил да мислиш ще вземеш да пропишеш SOLID, а това само Ганите го налагат. Са'ни излъжиш ей!

Golden Gega

Тук можем да навлезем в един интересен спор какво значи "смисъл вложен в абстракцията". Ако двата метода са с леко различен смисъл тогава солидни ли сме или не?

Зависи как разбираме 'леко различен смисъл'. Ако приемем изрично като част от дизайна на една система че можем да третираме три де точките като две де точки игнорирайки съзнателно z примерно и тази куца абстракция все пак ни върши работа тогава формално LSP е удовлетворен.

Но три де точките са по-ограничаващ интерфейс от програмистка гледна точка от две де точките (неинтуитивно щото носят повече информация обаче също така ИЗИСКВАТ повече информация за работа с тях И от две де кода) и ако просто пускаме три де точки там където кода очаква две де без да сме помислили дали простото отцепване на x, y например от x, y, z като лесен паразитен ефект от наследяването е това което искаме LSP е счупен и в хубавия случай ще ни го каже някакъв вид верификация на програмата а в лошия програмата някак ще върви обаче ще се чудим що разни точки се появяват на шантави места

Golden Gega

Лисков понякога може да бъде коварен и подвеждащ, да разгледаме пример:

имаме метод за изчисляване на разстояния между две географски координати:

var p1 = new point(lat1, long1)
var p2 = new point(lat2, long2)

Distance(p1, p2)

Решаваме обаче че това не винаги стига и правим наследник в който имаме

var p1 = new point(lat1, long1, alt1)
var p2 = new point(lat1, long1, alt2)

Distance (p1, p2)

координатната система е еднаква, дименсиите са еднакви, всичко изглежда 6, в един светъл момент получаваме проблеми защото в базовия метод дистанцията е смятана в евклидово пространство, а в по-модерния - с отчитане на земната геометрия. Първичните тестове със сравняване на резултати са били с допустима точност, защото са се смятали разстояния в квартали, но проекта скалира и почват да се смятат разстояния между градове в различни държави.

Тук секса е че ако сме противници на Лисков просто ще разкараме базовия клас, ще си напишем собствен и ще сменим навсякъде, като ще преизчислим дори и първичните данни. Т.е. в случая анти-солида се оказва правилния начин на работа.

Тоя пример също не ми изглежда нормален. Ако методите за двумерна точка са предназначени за подаване на евклидови координати примерно в метри, а ние подаваме ъгли дължина и ширина, то много ясно, че ще получим грешни резултати. Но първо, те няма да са верни нито за близки, нито за далечни разстояния. И второ - ООП-то няма нищо общо, ако подаваме грешни мерни единици.

Впрочем, в такива случаи, когато ще използваме различни мерни единици е редно да претоварим методите и да напишем метод за смятане в евклидови координати и такъв смятащ в ъглови координати. Но това пак няма нищо общо със ООП-то като такова, нито със наследяването.

Ако пък наследим класът и го направим с 3 координати, то и методите следва да се направят да обработват правилно и 3 и 2 координати. Което в дъщерния модул е елементарно...

И всичко ще се смята винаги правилно, независимо от това дали точките са от родителският или дъщерният клас.

johnfound

Golden Gega

Лисков понякога може да бъде коварен и подвеждащ, да разгледаме пример:

имаме метод за изчисляване на разстояния между две географски координати:

var p1 = new point(lat1, long1)
var p2 = new point(lat2, long2)

Distance(p1, p2)

Решаваме обаче че това не винаги стига и правим наследник в който имаме

var p1 = new point(lat1, long1, alt1)
var p2 = new point(lat1, long1, alt2)

Distance (p1, p2)

координатната система е еднаква, дименсиите са еднакви, всичко изглежда 6, в един светъл момент получаваме проблеми защото в базовия метод дистанцията е смятана в евклидово пространство, а в по-модерния - с отчитане на земната геометрия. Първичните тестове със сравняване на резултати са били с допустима точност, защото са се смятали разстояния в квартали, но проекта скалира и почват да се смятат разстояния между градове в различни държави.

Тук секса е че ако сме противници на Лисков просто ще разкараме базовия клас, ще си напишем собствен и ще сменим навсякъде, като ще преизчислим дори и първичните данни. Т.е. в случая анти-солида се оказва правилния начин на работа.

Тоя пример също не ми изглежда нормален. Ако методите за двумерна точка са предназначени за подаване на евклидови координати примерно в метри, а ние подаваме ъгли дължина и ширина, то много ясно, че ще получим грешни резултати. Но първо, те няма да са верни нито за близки, нито за далечни разстояния. И второ - ООП-то няма нищо общо, ако подаваме грешни мерни единици.

Впрочем, в такива случаи, когато ще използваме различни мерни единици е редно да претоварим методите и да напишем метод за смятане в евклидови координати и такъв смятащ в ъглови координати. Но това пак няма нищо общо със ООП-то като такова, нито със наследяването.

Ако пък наследим класът и го направим с 3 координати, то и методите следва да се направят да обработват правилно и 3 и 2 координати. Което в дъщерния модул е елементарно...

И всичко ще се смята винаги правилно, независимо от това дали точките са от родителският или дъщерният клас.

Оф, всички мерни единици са градуси, идеята беше че разстоянията могат да се смятат по различен начин в различните методи, като за засилване на контраста казах че първия метод с приемлива точност за малки разстояние приема че работи в равнина и съответно смята разстоянията по Питагор, а следващия вече приема повърхноста за елипсоид/геоид и смята по крива.

Дори и за сметки по криви алгоритмите са доста, ей тук има примерна дискусия: My link

Golden Gega

Оф, всички мерни единици са градуси, идеята беше че разстоянията могат да се смятат по различен начин в различните методи, като за засилване на контраста казах че първия метод с приемлива точност за малки разстояние приема че работи в равнина и съответно смята разстоянията по Питагор, а следващия вече приема повърхноста за елипсоид/геоид и смята по крива.

Дори и за сметки по криви алгоритмите са доста, ей тук има примерна дискусия: My link

ОК, хубаво, но аз решително не схващам какво точно е порочно на тази схема?

Ако сме направили родителският клас да смята приблизително и точността е спряла да ни устройва, то проблема е именно в родителският клас. Там и трябва да се оправя. Но отново това няма нищо общо с ООП парадигмата. Е, или аз не виждам връзката.

johnfound

Golden Gega

Оф, всички мерни единици са градуси, идеята беше че разстоянията могат да се смятат по различен начин в различните методи, като за засилване на контраста казах че първия метод с приемлива точност за малки разстояние приема че работи в равнина и съответно смята разстоянията по Питагор, а следващия вече приема повърхноста за елипсоид/геоид и смята по крива.

Дори и за сметки по криви алгоритмите са доста, ей тук има примерна дискусия: My link

ОК, хубаво, но аз решително не схващам какво точно е порочно на тази схема?

Ако сме направили родителският клас да смята приблизително и точността е спряла да ни устройва, то проблема е именно в родителският клас. Там и трябва да се оправя. Но отново това няма нищо общо с ООП парадигмата. Е, или аз не виждам връзката.

Ако имаме родителския клас без сорс кода например.

Golden Gega

johnfound

Golden Gega

Оф, всички мерни единици са градуси, идеята беше че разстоянията могат да се смятат по различен начин в различните методи, като за засилване на контраста казах че първия метод с приемлива точност за малки разстояние приема че работи в равнина и съответно смята разстоянията по Питагор, а следващия вече приема повърхноста за елипсоид/геоид и смята по крива.

Дори и за сметки по криви алгоритмите са доста, ей тук има примерна дискусия: My link

ОК, хубаво, но аз решително не схващам какво точно е порочно на тази схема?

Ако сме направили родителският клас да смята приблизително и точността е спряла да ни устройва, то проблема е именно в родителският клас. Там и трябва да се оправя. Но отново това няма нищо общо с ООП парадигмата. Е, или аз не виждам връзката.

Извинявай, ако наследим родителския клас от друг разработчик.

Golden Gega

johnfound

Golden Gega

Оф, всички мерни единици са градуси, идеята беше че разстоянията могат да се смятат по различен начин в различните методи, като за засилване на контраста казах че първия метод с приемлива точност за малки разстояние приема че работи в равнина и съответно смята разстоянията по Питагор, а следващия вече приема повърхноста за елипсоид/геоид и смята по крива.

Дори и за сметки по криви алгоритмите са доста, ей тук има примерна дискусия: My link

ОК, хубаво, но аз решително не схващам какво точно е порочно на тази схема?

Ако сме направили родителският клас да смята приблизително и точността е спряла да ни устройва, то проблема е именно в родителският клас. Там и трябва да се оправя. Но отново това няма нищо общо с ООП парадигмата. Е, или аз не виждам връзката.

Ако имаме родителския клас без сорс кода например.

Ааа тука ръгаме адаптер патърн !

Е-е-е, ама то така ще стане адски зле - код подпрян на патерици и подпорки. И бавно и със скрити бъгове.

В такива случаи, според мене единственият вариант е да се пренапише всичко отначало. Код реюз, добре, но не на тая цена!

johnfound

Е-е-е, ама то така ще стане адски зле - код подпрян на патерици и подпорки. И бавно и със скрити бъгове.

В такива случаи, според мене единственият вариант е да се пренапише всичко отначало. Код реюз, добре, но не на тая цена!

Да, именно това е правилния подход според мен - да се пренапишат и двата метода (или стария да се рапне към новия), като миналите данни през стария метод да се минат (преизчислят) пак. Но това не е ли доста антисолидно решение?

Golden Gega

Но това не е ли доста антисолидно решение?

Че аз откъде да знам. За мене "solid" е агрегатно състояние на веществата. А от ООП езиците знам само Delphi/Object Pascal. Вярно, там съм добър. Е да и си написах ООП библиотека за асемблер, по образеца на Delphi.

johnfound

Golden Gega

Но това не е ли доста антисолидно решение?

Че аз откъде да знам. За мене "solid" е агрегатно състояние на веществата. А от ООП езиците знам само Delphi/Object Pascal. Вярно, там съм добър. Е да и си написах ООП библиотека за асемблер, по образеца на Delphi.

Ох Джонка, целия пример беше в контекста на солида, по-точно за принципа на Лисков. Явно и аз не съм го представил много добре, днес беше бурен/бирен ден

johnfound

В такива случаи, според мене единственият вариант е да се пренапише всичко отначало. Код реюз, добре, но не на тая цена!

И аз така викам, обаче рядмо ми дават и го лепа, къде с лепило, къде с тиксо, къде с плюнка. Имам 5 неща от 3-ма вендори и две наши и вече сме дали много пари, затова го лепима с вечепосочените и тръгва. След време, ако сме били правили милиарди, ще го пренаписваме. Но май и тогава ще го лепим.

Elim Garak

хората отдавна са се отрекли от layered, сега е модерно "clean architecture"

Краткият ми въпрос е, за микросървиси има ли смисъл от каквато и да е архитектура, след като имам не повече от 20 класа. Justification-а ми е както следва.

Не съм ходил на интервю от 4 години, бях се насочил и към други ИТ неща, като мрежи, операционни системи, облак, девопс, така че това ми е убягнало. Нищо, ще наваксам.

Гледах преди време Clean Architecture на Ardalis @ https://github.com/ardalis/CleanArchitecture (Има го и на GOTO Copenhagen в тубата, всъщност от там разбрах). Пуснах един малък сайт с този метод. Видях коментари за MediatR, ползвах го без да задълбая. Сега гледам на Matthew Renze @ https://matthewrenze.com/presentations/clean-architecture/

Той препоръчва и за сървиси. Добре, ако правя REST, ок. Но не би ли било изнасилване в чисто enterprise сценарии, където имам много домейн логика в oracle и аз съм само the means да се консумира тази логика, като им правя сървис. Точно в такава ситуация съм имал един голям solution от 50+ проекта, чиято основна цел беше да определи точно кои stored procedures да run-не на база кой клиент за какво си е платил и кой продукт иска, плюс да persist-на достатъчно данни, така че да се bill-не клиента за използването си и да има достатъчно лог да рови тех съпорт вместо мен. Ако Domain-а ми е сложен в базата, то би ли имало sense, защото layered се фокусира именно върху persistence layer-а. Повечето архитекти, с които съм работил са на 50 годе, трябва да направя наистина огромен justification какво ще спечели. Мога да си broadcast-вам за maintainability и как ще спечелим след време, но това бих имал възможност да го докажа ако се даде да се пише нов проект и да мине достатъчно време, да се плъгнат достатъчно хора и волята някак си да измеря как е минало, сравнявайки го с нещо друго. Бизнесът от velocity за development не разбират, те искат time to market without bugs (хаха!). Досега съм бачкал в компании, които компроментират качество, за сметка на време до пазар, отколкото да залагат на мегакачество. Кауза пердута може би. Но ако точно домейна ми е в базата, в момента аз реално си мисля, че не ми пасва. Освен ако не дойде ново CTO и някак си продаде идеята да се пренаправи всичко пред борда чичковци, вземащи тежки решения, което ще е един дълъг процес.

Друг сценарии - микросървиси с много раздробен домейн, буквално са по 20-на класа на сървис, по- често 10, които са вързани към queue-та (сметнахме го за по- добър вариант, защото така гледахме от гурута, защото избягваме HTTP Chaining, за да не страдаме от latency и availability issues, и решихме, че вътрешно ще е overkill да симулираме асинхронна комуникация през HTTP с callback-ове (по- скоро колбеци ), и би било по- евтино да симулираме синхронна комуникация навън от системата, на ниво gateway, ако на външен HTTP Request трябва да върна непременно Response с нещо, което не е само ID (като например, някой ме пита какво е времето в София и аз му връщам температура, влажност, UV, etc.). Но това е по- скоро бонус, по- скоро гледаме да съпортваме callback/webhook. Може би тук трябва да се насоча по- скоро върху самата абстракция, subdomain-а ми няма да порасне много, а ако порасне, може би ще искаме да го разделим. И ако в крайна сметка се връзва да слушам на едно queue и пиша в няколко queue-та, като съм направил малко бизнес логика с event-а и съм го валидирал + малко encryption + малко hashing, що да overkill-вам? Да, на моменти трябва да имплементирам сага, за да знам, ако Иван купува с Пейпал акаунта си кашон цигари, то има ли той достатъчно пари в пейпал акаунта си и има ли партньора ми на склад точно такава бройка цигари, въпреки че сутринта ми е казал, че има N+1000 бройки и ми казва от време на време колко точно бройки има, все пак може да не резервирам кашона с цигари, защото го няма, а аз не мога да му взема парите, ако не мога да му предоставя цигарите (всъщност мога, но после доусложнявам процеса, че ще трябва да му ги върна и може да има такси, икебана работа). Тогава ще пусна 2-3-4 месиджа по queue-то или http до другите сървиси, те ще си кажат кой как се чувства и ще предприема действие или няма да предприема.

Защо да сегрегирам? Регистрирал съм евент, например искам да пратя пари от Англия за Гана или пращам пари от Германия за Белгия (щото минават през различни пеймънт системи и различни пеймънт провайдъри и други финансови институции, в това число банки, уестърни, некви уйове, отнема различно време и още много детайли, така че реално не знам дали парите ще идат днес, утре, другата седмица докато не видя от точно коя финансова организация до коя финансова организация го пращам, а отделно трябва да следя и за PEP и anti money laundering и още наистина много детайли, но може и да не следя, а финансовите организации и така нататък други законодателни или не специфики... после що хората харесват биткойн...). Какво е станало с него (с евента)? Връща се ID на този евент. Ти може и да си поискал callback на адрес, но може и да не си го поискал, може да искаш да идеш на друг адрес и да видиш с това ID статус или детайли, или и двете, няма значение. Финансовите преводи са много хубав пример, защото могат да имат частни ситуации с много детайли. Как парите да стигнат от един човек до друг човек с минимални такси и максимално бързо. Или как да стигнат между тези хора по- анонимно. А дали не искат биткойн или монеро или хуйнеро. Тук ще има още повече развитие в бъдеще и може би накрая NWO ще излезнат с една единствена електронна валута, след като бутнат Китай и Русия. Специално Европа, като изключим регулациите, прави този процес по- лесен. В Гана и Бурунди да пращаш пари си е приключение. Може да има по- малко детайлна, но подобна ситуация ако продавам сървис за пращане на СМС-и в повече от една страна (been there, done that).

В крайна сметка имам много сървиси с малко код в тях. Да, от една страна, за да знам какво става, трябва да знам целия процес и трябва да съм много внимателен с логинга, щото иначе иди му хвани края, но от друга страна, почти всеки може да напише, ако иска и може и всичко на статик да ми напише, плъгвам го и бачка. Е, не е баш така, щото трябва да внимава със специфики около queue-то, но няма идеален свят. Но имам един малък unit без гранде патърне и даже може да не е SOLID.