|
Страници по тази тема: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | (покажи всички)
Тема
|
Недостатъците на OOP
|
|
Автор |
sashometallico (непознат) |
Публикувано | 09.11.18 12:24 |
|
| |
|
стига да не четеш за парадигми и патерни, или да бачкаш с колеги дето си падат да четат подобни глупости
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.
Освен другото, чрез такава проста схема е изключително лесно да вкараш новобранци в дълбоките води на програмирането и да ги направиш полезни, вместо да ти късат нервите 3-4 години, докато научат А и Б.
| |
|
С малко ум в главата, единствените god objects ще са ти фронт-контролерите.
Аз също съм уебаджия, но нещо не съм съгласен. По принцип не трябва изобщо да има god обекти. А пък Controller-a трябва да е тънък ако говорим за контролери по смисъла на MVC.
Виж Laravel (който е SOLID базиран) как е направен: правиш си нов controller, описваш му входящия route в routes.php и си ти. След това като решиш да правиш нов controller, слагаш нов route. Никъде няма god обекти.
| |
|
При Ларавел, както и повечето ПХП фреймуърци, рутера изземва част от функциите на фронт контролера. При него на отделните рутинг правила можеш да закачаш мидълуер, дипендънсита и т.н.
Както и да е, ако фреймуърка е по-гъвкав, например любимия ми Slim, можеш в зависимост от стила на програмиране, да изолираш рутера да върши само рутинг, а зад него да имаш фронт контролери. При уеба ползвам по два такива - един за Аякс и един за рендване на страници.
Както и да е, понеже освен уеб, пиша и за Андроид, а понякога и на C#, видях че същата елегантна схема може да се използва и за други платформи. Не съм я мислил аз, видях идеята отнякъде и я доразработих за свои нужди. После видях, че и други я ползват - проста едноетажна схема, изключително гъвкава. Не е с god обекти, по-скоро плуралистична, защото фронт контролерите са икспендъбъл.
| |
|
Страници по тази тема: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | (покажи всички)
|
|
|