MrPi

Рейтинг
17
Регистрация
05.05.2025
Александр Воробьев #:
Любой фреймворк, любая библиотека что то "скрывает",

Считаете? Хогвартс в разработке лучшие практики?

User::whereName('Johny');

Что здесь, как думаете? Статичный, публичный метод класса?)

Sly32 #:
Я тоже не всегда классы использую как ООП,  иногда просто удобнее сгруппировать общие методы или хранить настройки.

Именно так и делаю. Очень удобно приватные и публичные методы определять. Но в процедурном стиле тоже легко. Добавить namespace в файл функций и приватные писать с __ privateFunction() к примеру. Ну или определиться с командой.

Чистое ФП не видел нигде. Впрочем как и чистое ООП. Всегда мешают. 

Sly32 #:
Ну слушай, можно же даже на этом форуме немного прочитать инфы про оппонента, прежде чем спрашивать)

Предлагаешь мне ознакомиться с биографией каждого, кому отвечаю?)

Sly32 #:
Это ты путаешь) У вас странное представление о ООП и его принципах.

Так как ты понимаешь инкапсуляцию и наследование? В ООП для веба всегда спрашиваю, а как работаешь с SESSION, COOKIE, POST, GET к примеру?

Sly32 #:
Ты сможешь оценить код на Пайтон?

100%. Я на пайтоне начинал. Но единственный на тот момент выход в веб был через django фреймворк. А после решил, что нужен язык, который появился в следствии развития веба и создан  для него.

Александр Воробьев #:
и если он не нужен, то его можно не использовать.

Ключевое. Потом пригодится)

Александр Воробьев #:
Вы же сами выше писали "не хочу ни чего лишнего".

Где писал? Я хочу простоту топора. Писал, что придерживаюсь принципов KISS DRY YAGNI.

Александр Воробьев #:
Вообще все это индивидуально ИМХО

Так это вам сразу написал, когда спрашивал про ваш челлендж и кто будет судьей.

Александр Воробьев #:
Да даже echo "hello world" магия, вам же не надо знать как устроено.

Вы путаете мягкое с горячим. Синтаксис языка и магические методы фреймворка

TheVS #:
с большим трудом справляются с написанием самых простых нейронок. 
Печально. Кремниевй долине не быть
Анти БОТ #:
Да уже летали, в первой половине прошлого века. Падали, правда, быстро и ярко.

Ой, началось. Вы про 1937 год? Так меньше половины погибло. Сколько при падении самолёта погибает? 

Продумать конструкцию, что бы не сгореть сверху, когда водород загорится? За 100 лет научились? Если бы углубились в разработку, то точно придумали бы оптимальный баланс. Но + экология, + туризм на смену круизным лайнерам. + Посадка где угодно, хоть в тайге. + Автономность недельная и больше. Если солнечными панелями обвесить. + Габариты груза не ограничиваются трубой самолёта. Дом многоквартирный на изи перевезти. Ну и виды, а так же сфера эксплуатации. С ангарами придумали бы точно. Не строили бы их, а рыли бы котлованы под них, подземные

Had #:

в 1890 годах, то не нужно было бы за 130 лет строить столько дорог по всему миру. Это не то что миллиарды долларов, это за всё время триллионы долларов.

Опять же я не понимаю в чём сейчас сложность постройки машины на 4 человека по технологии квадрокопетра (4 вентилятора).

Если бы запустили дирижабли. Нормальную технологию разработали, то с такой грузоподъёмностью и энергозатратами можно было бы бесплатно почти летать

Vladimir SEO #:
а ии может ускорить телеграмм и ютуб ? 
Я смотрел Кремниевая долина серал. Может. Может и сам себя проабгрейдить. Интересно, если нейронки попросить самих себя совершенствовать, выдавая свой же код. Смогут из себя сверх нейронки сделать?)
Vladimir SEO #:
и сразу обнова вышла )))) 

Видео ещё быстрее грузится начало. Странное замедление. 

Sly32 #:
Еще полиморфизм
MrPi #:
Чего стоит только полимарфизм
Sly32 #:
Это в Java так пишут. Разве пхп заставляет все классы хранить в отдельных файлах? 

Это best practice в ООП. Сам паттерн с инкапсуляцией и SRP об этом говорит

Sly32 #:
Я на Ларавел писал, когда про ИИ еще и не слышали. ОТличный фреймворк и довольно понятный.

Довольно понятны методы и вызовы, но просто не смотрели в ядро, пока ничего не упало. Совместимость между версиями - это отдельная кость. Мало того, что тащиет говно мамонта с первых версий, так еще и миграция между версиями часто приносит боль. Даже в нем приняли чрезмерность ООП и сделали функции хелперы, по типу base_path(), url(), route() из процедурном исполнении.

Sly32 #:
Пайтон - изначально построен на ООП

Вы видимо путаете классы и ООП. В энтерпрайз команде работаете или один(вдвоем)? Есть хоть один проект, посмотрю? Просто любопытно стало соотношение масшатаба к количеству кода

Sly32 #:
Это вовсе на ООП
Sly32 #:
Не выдумывайте вы ерунды
Sly32 #:
Какие сотни файлов по 2 метода?

Основные принципы ООП - инкапсуляция, наследование.  Вот такие капсулы с абстрактным наследованием делают из простого сложное. Тот же микрофреймворк, популярный в php slim

https://github.com/slimphp/Slim

Один роутинг из 12 классов.

Вот пример инкапсуляции

class MethodOverrideMiddleware implements MiddlewareInterface
{
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        $methodHeader = $request->getHeaderLine('X-Http-Method-Override');

        if ($methodHeader) {
            $request = $request->withMethod($methodHeader);
        } elseif (strtoupper($request->getMethod()) === 'POST') {
            $body = $request->getParsedBody();

            if (is_array($body) && !empty($body['_METHOD']) && is_string($body['_METHOD'])) {
                $request = $request->withMethod($body['_METHOD']);
            }

            if ($request->getBody()->eof()) {
                $request->getBody()->rewind();
            }
        }

        return $handler->handle($request);
    }
}

1 метод - 1 класс, 1 файл. Прикольный такой SRP. И это микрофреймворк без нихрена. Просто ничего нет. Нет ни работы с локализацией, безопасностью, форматированием, валидацией. Просто снихрена 50 файлов маршрутизации и базового ничего. За сколько без агентов разберетесь в условном фреймворке Ларавель? Там магии больше чем в Хогвартс. Чего стоит только полимарфизм. Вроде просто - одна базовая кнопка. Но в одном действии она запускает двигатель, в другом готовит еду, в тертьем запускает ракеты. А после решил поменять действие. Лезешь в базовую и вспоминаешь, где этих кнопок накидал и сколько. Если дохрена, то кодишь новый класс для новой кнопки. И так накидываешь мертвого кода. На старте это хорошо, но после масштабируемости и смены поведения, либо расширяешь класс на новые кнопки и так до бесконечности. Абстракция в ООП - это отдельное зло. Для меня очевидное решение - лучшее решение. Да. в команде без этого никуда, но в частной разработке ООП зло, когда всё делает несколько разработчиков. Энтерпрайз проекты насчитывают десятки и сотни тысяч классов, наследований. Мне это ни к чему. Буду работать в коммерц разработке над одним микросервисом, буду пилить сотни классов с инкапсулированностью. Ну или банковские приложения с очередями, гонкой. Там это приемлемо, а для меня оверинжиниринг

Всего: 304