принципиальные невозможности ООП
возьмем ларавел. там есть система фасадиков, которые аля синглетон, из-за чего фактически final, но де-юре - нет.
а теперь внезапно - я хочу расширить класс методом, использующимся внутри, но название (оппа) оставить прежним.
к примеру, юзается Request с набором методов для валидации и обработки. я хочу добавить еще один, но рисовать везде опосля такого NewRequest - идиотизм полный.
вопрос же как это "решает" ООП очевиден - никак. нужны другие средства, которых пока еще нет. либо, как это нам предлагают идеологи недоперепаттернов - перефигаривать мелкий и удобный класс с набором фильтров в монстра, выделяющего хозяйство в фабрики методиков, подгружающиеся и регистрирующиеся, и прочее и прочее. и доворачивающие название Request примерно такие же - "снаружи". не, оно будет чисто ООП не вопрос, оно будет очень "крутым" и это тоже не вопрос - простыни текста, структуры и разные регистрилки с фабриками. но одна чисто "писательская", не ООП-конструкция аля
modified class Request { function new_filter(){} } - и вся эта аляповатая крутость уходит в ноль.
тот же ларавел, помним примерно такое: [ 'nick' => "required|string|trim|escape" ] в валидаторе?
а помним идею с конструкциями аля pipeline? ведь эта вот пайплайна - чисто костыль. я дичайше удивлен почему оно не выглядит как nick->required()->string()->trim()->escape() аля моднявость, но это другой вопрос.
первый же - совсем не ООП-шное, хотя "новый вид класса" с набором локальных для него методов пайплайна был бы наверно очень успешен. типа
$nick = use Filters($nick) : required|string|trim|escape; как вариант. как это удобно описать, кстати, повыше, в массивчике - отдельный вопрос. потому, что даже короткая запись массива в похопе явно может быть улучшена, причем не убирая и "старую короткую", чо, как и многое другое, а необходимость перечислять "аля настройки" переменные - в похохопе (типа новом) будет востребована.
еще одна принципиальная фигня ООП - невозможность тупо переименовать что-то. любой класс в сторонней либе, вызывающий конфликт имен. а то и неймспейс. вон, выше, любой FigKakoyRequest в Request. очевидно, что любая либа должна быть в неймспейсе, очевидно, что конструкция переименования должна быть 99%+ только на конечной прикладной штуковине, а не посередке в либах, очевидно, что для мелких использований можно даже давать переименовывать только в рамках неймспейса, но очевидно, что такая штука нужна. и маппинг имен. чтобы любой Symfony\Request use as SymfonyDrop\ArchiveRequest и - наоборот. а все очевидности - либо административными либо (если это возможно технически) и техсредствами обеспечивать.
отступление раз: кеш мог бы так настраиваться и быть дефолтным аля фасадом как cache. и многое другое, из коробки.
отступление два: интересно, что идеи тут разрисованные - нигде просто даже и не пахнет подобным. даж намеков (окромя похопе) нету. а это значит, что, скажем любой китаец, или японец, или русский - могут взять так, и попробовать допилить просто и тупо похопе хотя бы. и - получить нехилый профит прямо в отрасли в своем городе. почему нет. эти ж идеи - снижают риски ошибок, повышают уровень кода, упрощают и ускоряют разработку. в том языке, где реализованы. ну, должны, если я прав и если допилить достаточно корректно.
да, для этого нужно включить бошку, проверить гипотезы и попроверять как оно в деле. я вот пробую и, скажем ajax контроллер в две строки:
$request = Request::get( [ 'answer_id' => "required|int" ] );
$this->answer = $game->answer( $request->answer_id );
мне нравится больше, чем все что я видел на просторах "инторнета", включая ларавел и поделки на его основе, где параметры запроса ваще не проходят фильтрацию и идут as is в базу. ну да, там где-то они чудесным, непрописанным и дефолтным образом, канеш что-то там. но. можно расписать чем такой вариант хорош, но - лучше самим. потому, что в двух строках нету много чего, тоже важного. но не суть.
важно то, что аналогов нет. что можно и нужно развивать. потому, что потолок сложности фабрично-паттерного г-а уже виден, а альтернатив - ну, просто, тупо, нету. потому, что как показывает практика и примерчики на просторах, даже удобнее-не-случается-пока валидаторы ларавеля не пользуются. наверно, потому, что. зато как построить питнацать файлов с фабриками, генераторами и прочими провайдерами шоп просто страничку отрисовать - эт могЕм, это круто.
и ничо, что это нах никому не надо.
а я вот уверен, что как только у кого включатся даже не руки, а легкий интерес и упростится вот все вот это вот, скачок в уровне разработки может случиться тот еще.
и это не процессоры перевести на новые нанометры, это студенческие в половине случаев _минимум_ доработки. там где инфраструктурщинское аля дефолтный кеш или хранилка для аплоадов.
а теперь внезапно - я хочу расширить класс методом, использующимся внутри, но название (оппа) оставить прежним.
к примеру, юзается Request с набором методов для валидации и обработки. я хочу добавить еще один, но рисовать везде опосля такого NewRequest - идиотизм полный.
вопрос же как это "решает" ООП очевиден - никак. нужны другие средства, которых пока еще нет. либо, как это нам предлагают идеологи недоперепаттернов - перефигаривать мелкий и удобный класс с набором фильтров в монстра, выделяющего хозяйство в фабрики методиков, подгружающиеся и регистрирующиеся, и прочее и прочее. и доворачивающие название Request примерно такие же - "снаружи". не, оно будет чисто ООП не вопрос, оно будет очень "крутым" и это тоже не вопрос - простыни текста, структуры и разные регистрилки с фабриками. но одна чисто "писательская", не ООП-конструкция аля
modified class Request { function new_filter(){} } - и вся эта аляповатая крутость уходит в ноль.
тот же ларавел, помним примерно такое: [ 'nick' => "required|string|trim|escape" ] в валидаторе?
а помним идею с конструкциями аля pipeline? ведь эта вот пайплайна - чисто костыль. я дичайше удивлен почему оно не выглядит как nick->required()->string()->trim()->escape() аля моднявость, но это другой вопрос.
первый же - совсем не ООП-шное, хотя "новый вид класса" с набором локальных для него методов пайплайна был бы наверно очень успешен. типа
$nick = use Filters($nick) : required|string|trim|escape; как вариант. как это удобно описать, кстати, повыше, в массивчике - отдельный вопрос. потому, что даже короткая запись массива в похопе явно может быть улучшена, причем не убирая и "старую короткую", чо, как и многое другое, а необходимость перечислять "аля настройки" переменные - в похохопе (типа новом) будет востребована.
еще одна принципиальная фигня ООП - невозможность тупо переименовать что-то. любой класс в сторонней либе, вызывающий конфликт имен. а то и неймспейс. вон, выше, любой FigKakoyRequest в Request. очевидно, что любая либа должна быть в неймспейсе, очевидно, что конструкция переименования должна быть 99%+ только на конечной прикладной штуковине, а не посередке в либах, очевидно, что для мелких использований можно даже давать переименовывать только в рамках неймспейса, но очевидно, что такая штука нужна. и маппинг имен. чтобы любой Symfony\Request use as SymfonyDrop\ArchiveRequest и - наоборот. а все очевидности - либо административными либо (если это возможно технически) и техсредствами обеспечивать.
отступление раз: кеш мог бы так настраиваться и быть дефолтным аля фасадом как cache. и многое другое, из коробки.
отступление два: интересно, что идеи тут разрисованные - нигде просто даже и не пахнет подобным. даж намеков (окромя похопе) нету. а это значит, что, скажем любой китаец, или японец, или русский - могут взять так, и попробовать допилить просто и тупо похопе хотя бы. и - получить нехилый профит прямо в отрасли в своем городе. почему нет. эти ж идеи - снижают риски ошибок, повышают уровень кода, упрощают и ускоряют разработку. в том языке, где реализованы. ну, должны, если я прав и если допилить достаточно корректно.
да, для этого нужно включить бошку, проверить гипотезы и попроверять как оно в деле. я вот пробую и, скажем ajax контроллер в две строки:
$request = Request::get( [ 'answer_id' => "required|int" ] );
$this->answer = $game->answer( $request->answer_id );
мне нравится больше, чем все что я видел на просторах "инторнета", включая ларавел и поделки на его основе, где параметры запроса ваще не проходят фильтрацию и идут as is в базу. ну да, там где-то они чудесным, непрописанным и дефолтным образом, канеш что-то там. но. можно расписать чем такой вариант хорош, но - лучше самим. потому, что в двух строках нету много чего, тоже важного. но не суть.
важно то, что аналогов нет. что можно и нужно развивать. потому, что потолок сложности фабрично-паттерного г-а уже виден, а альтернатив - ну, просто, тупо, нету. потому, что как показывает практика и примерчики на просторах, даже удобнее-не-случается-пока валидаторы ларавеля не пользуются. наверно, потому, что. зато как построить питнацать файлов с фабриками, генераторами и прочими провайдерами шоп просто страничку отрисовать - эт могЕм, это круто.
и ничо, что это нах никому не надо.
а я вот уверен, что как только у кого включатся даже не руки, а легкий интерес и упростится вот все вот это вот, скачок в уровне разработки может случиться тот еще.
и это не процессоры перевести на новые нанометры, это студенческие в половине случаев _минимум_ доработки. там где инфраструктурщинское аля дефолтный кеш или хранилка для аплоадов.