стига да не четеш за парадигми и патерни, или да бачкаш с колеги дето си падат да четат подобни глупости




NE SUTOR ULTRA CREPIDAM

Мда и резултата винаги са няколко god objects дето наследяват 20+ класа и са couple-нати към още 100 (статични, щото нема къде другаде да ги набухат). Променяш едно нещо и се чупи нещо друго съвсем различно. Примера с банана и горилата много ме изкефи.

Рабине, ти велики ПРОГРАМИСТе, моля те изкажи експертно си мнение как посочената ситуация може да бъде решена? Като се уволни Гана ли?

Одрътех, не ми се четат философски простотии.
Май се задава огромна финансова буря, не мога да си намеря свободен дограмаджия, пък и комин имам да замазвам.
Кодеца дето ще ми носи дебелата пачка дори не е обектно ориентиран в голямата си част.
Ма вий четете, Гана ще го оцени. Освен това по-скоро ще уволнят целия ви екип, отколкото да се отърват от Гана. Лелките с плетките си заминават последни. Що така и аз не знам!

Редактирано от rabin на 09.11.18 13:36.

ООПето е обществно приемливо програмиране с мазане през глобални променливи и настъпване на другарчетата през ръцете (с чизми с шипове). Сапиенсите сме така, не е нужно нещо да се прави както трябва а само неква общоприета илюзия че се прави ужким както трябва и вече всеки сере както му падне и играеме the blame game като се срути част от кулата от карти.

Ама общо взето бачка тая схема, цайковците с монадите и ковариантностите още не са произвели чеп за зеле. Всичките хубави неща отдолу са безумен ляйнян оопе/процедурен код

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

това са дреболии, нямам спомен за ядове такива, може би щото класовете ми не наследяват 20 класа хахах.
основния демидж на ооп е загубата на време на ропчетата в спорове кое е по-правоверно и богоугодно, това не е малко де, не го омаловажавам. но да жулиш на С++ без да си ооп пропонент си е екстра




NE SUTOR ULTRA CREPIDAM

Простотий, простотий, ...

Кратък прелет над предишните изяви на г-на ме кара да си мисля, че той е някакъв хаскелджия, който е направил първи стъпки в необятните ловни полета на истинското програмиране, настъпил е остър камък, изохкал е и е решил, че реалния свят извън парника му трябва да бъде сетнат на null.

Банана-манки-джангъл проблема значел, че унаследяването ще изчезне. rly? Ма той не е ли чувал за пекидж мениджъри? Не знам дали в Хаскел има такива, но във всеки уважаващ себе си език са по 20-30 минимум. С'я ясно, че има кофти пакети, има и гениални, но това някаква новост ли е?

Даймънд-проблем - бас държа, че пича не е чувал за traits. Ама честно! М/у другото съм забелязал, че на не-уебаджии им е изключително трудно да проумеят що е то трейт и как да се използва. За да научи уебаджия какво е трейт е достатъчно да му кажеш "Абе същото, като CSS клас, само че за обекти", "Аха, ясно". И имате готов обучен човек, който ще знае какво е трейт и ще го ползва по най-перфектен начин, все едно му е фамилна традиция да пише с трейтове.

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

Съдържаниет е скрито
Влезте за да го видите

Мда и резултата винаги са няколко god objects дето наследяват 20+ класа и са couple-нати към още 100

С малко ум в главата, единствените god objects ще са ти фронт-контролерите. Аз винаги ползвам два такива - един за вътрешни заявки и един за външни. Всичко друго зад тях е едноетажна йерархия от сингълтъни, трейтове и хелпъри. Ако се наложи - за 5 минути някой фронт контролер може да бъде разкаран и нещо друго да върши неговата работа.

Проблем при подобно писане е само големия обем на създадени файлове, но тъй като те са изключително подобни, имам приготвени и няколко ХТМЛ панела за code generating.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

С малко ум в главата, единствените god objects ще са ти фронт-контролерите.

Аз също съм уебаджия, но нещо не съм съгласен. По принцип не трябва изобщо да има god обекти. А пък Controller-a трябва да е тънък ако говорим за контролери по смисъла на MVC.

Виж Laravel (който е SOLID базиран) как е направен: правиш си нов controller, описваш му входящия route в routes.php и си ти. След това като решиш да правиш нов controller, слагаш нов route. Никъде няма god обекти.

При Ларавел, както и повечето ПХП фреймуърци, рутера изземва част от функциите на фронт контролера. При него на отделните рутинг правила можеш да закачаш мидълуер, дипендънсита и т.н.

Както и да е, ако фреймуърка е по-гъвкав, например любимия ми Slim, можеш в зависимост от стила на програмиране, да изолираш рутера да върши само рутинг, а зад него да имаш фронт контролери. При уеба ползвам по два такива - един за Аякс и един за рендване на страници.

Както и да е, понеже освен уеб, пиша и за Андроид, а понякога и на C#, видях че същата елегантна схема може да се използва и за други платформи. Не съм я мислил аз, видях идеята отнякъде и я доразработих за свои нужди. После видях, че и други я ползват - проста едноетажна схема, изключително гъвкава. Не е с god обекти, по-скоро плуралистична, защото фронт контролерите са икспендъбъл.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите