Недостатъците на OOP

257 отговора 0 прегледа
#1

Недостатъците на OOP

[линк]

Отговор
в отговор на sashometallico #2

екстраси е ооп

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




NE SUTOR ULTRA CREPIDAM
Отговор
в отговор на zaphod #3

Re: екстраси е ооп

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

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

Отговор
в отговор на sashometallico #4

Re: екстраси е ооп

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

Редактирано от rabin на

Отговор
в отговор на sashometallico #5

Re: Недостатъците на OOP

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

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

I have sold less books on sex than Stephen Hawking has on physics -- Madonna
Отговор
в отговор на sashometallico #6

Re: екстраси е ооп

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




NE SUTOR ULTRA CREPIDAM
Отговор
в отговор на sashometallico #7

Re: Недостатъците на OOP

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

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

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

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

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

Отговор
в отговор на sashometallico #8

Re: екстраси е ооп

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

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

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

Освен другото, чрез такава проста схема е изключително лесно да вкараш новобранци в дълбоките води на програмирането и да ги направиш полезни, вместо да ти късат нервите 3-4 години, докато научат А и Б.

Отговор
в отговор на croesus #9

Re: екстраси е ооп

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

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

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

Отговор
в отговор на sashometallico #10

Re: екстраси е ооп

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

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

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

Отговор
в отговор на sashometallico #11

тоя е некъф рабин

още първия проблем дето реве показва че не разбира идеята
искал бил да реюзне некъф клас от неква друга програма, програма, не библиотека.
кво очаква да го еба в некадърния ревльо

Отговор
в отговор на ~@!$^%*amp;()_+ #12

Re: тоя е некъф рабин

Тая симптоматика е характерна за оопето, баш е прав - зле прикрито глобално омазано повръщано с малко шарени салфетки. Функционалното програмиране насърчава стил на писане при който е много по-лесно да зимаш отделни парчета отнякъде и тия парчета да са self-contained. Друг е въпросът че в голема система неминуемо имаш глобален стейт и странични ефекти и това винаги е наметено некси под килима сравнително грозно и реалистично повечето код се оказва овързан като черва независимо на къв език и от кви майстори е писан

I have sold less books on sex than Stephen Hawking has on physics -- Madonna
Отговор
в отговор на evlampi_popdimitrov #13

Re: тоя е некъф рабин

нема значение дали е ооп или функционално

ако не си оформил нещата като библиотека, да се опиташ да ги ползваш наготово си е рецепта за омазване

Отговор
в отговор на ~@!$^%*amp;()_+ #14

Re: тоя е некъф рабин

Пойнта е че е много лесно да създаваш скрити чупливи зависимости с класовете а обещанието на самата парадигма е че създаваш независими капсулирани блокчета с добре дефиниран интерфейс. В це плюс пляс примерно е особено смешно че трябва да прекомпилираш клиентския код ползващ обичаен наивен клас при пипане на имплементацията и как се избягва това са лупинги които минават за големото знаене

Иначе да, как да се оформи една абстракция така че хем да върши работа хем да е лесно да бъде преизползвана е тънко независимо коя религия се ползва

I have sold less books on sex than Stephen Hawking has on physics -- Madonna
Отговор
в отговор на evlampi_popdimitrov #15

Re: тоя е некъф рабин

Никой не ти пречи да спазваш най-добрите практики (SOLID) и да „създаваш независими капсулирани блокчета с добре дефиниран интерфейс“. Обаче е много по-лесно да „създаваш скрити чупливи зависимости с класовете“ и след това да хванеш горилата за банана като тоя мрънкач от линка. Това си е до програматора.

В це плюс пляс примерно е особено смешно че трябва да прекомпилираш клиентския код ползващ обичаен наивен клас при пипане на имплементацията и как се избягва това са лупинги които минават за големото знаене

Това пак е SOLID и пак си е до програматора дали ще ползва Open/Close принципа с декоратор шаблон или ще прекомпилира всичко. Смешно ти е щото пишеш на JavaScript

Редактирано от sashometallico на

Отговор
в отговор на sashometallico #16

Re: Недостатъците на OOP

Сички езици за програмиране са шит и да се спори кой от тях е по-добър, е все едно да се спори коя мотика е по-добра.
Инструмент за работа ли е - не ми го фали!

Отговор
в отговор на evlampi_popdimitrov #17

пойнта е че тоя е ревльо като рабин

повече не четох

Отговор
в отговор на evlampi_popdimitrov #18

Re: тоя е некъф рабин

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




NE SUTOR ULTRA CREPIDAM
Отговор
в отговор на zaphod #19

Re: тоя е некъф рабин

Хаха, да, не е доброто старо процедурно, имаш един куп неща гравитиращи около идеята за pure functions, сега е пълно с педераси видели светлината, забава голяма

I have sold less books on sex than Stephen Hawking has on physics -- Madonna
Отговор
в отговор на sashometallico #20

Re: тоя е некъф рабин

Най-забавното с джаваскрипта е че калъфите кълват първосигнално и като им кажеш за джаваскрипта почват да се дуят като пуяци предполагайки че пишеш САМО джаваскрипт понеже не си 'умен' колкото тях които мажат некви лайна на език който ползваш от памтивека и вероятно познаваш по-добре от тях, сериозно обмислям да почна да ходя с тениска javascript sensei само за да се хиля на разни калъфи с тяхното смешно чувство за фалшиво превъзходство щото те не били джаваскрипт мънкита моля ти се ами некви висши пазители на ПОЗНАНИЕТО

I have sold less books on sex than Stephen Hawking has on physics -- Madonna
Отговор