Считаете? Хогвартс в разработке лучшие практики?
User::whereName('Johny');
Что здесь, как думаете? Статичный, публичный метод класса?)
Именно так и делаю. Очень удобно приватные и публичные методы определять. Но в процедурном стиле тоже легко. Добавить namespace в файл функций и приватные писать с __ privateFunction() к примеру. Ну или определиться с командой.
Чистое ФП не видел нигде. Впрочем как и чистое ООП. Всегда мешают.
Предлагаешь мне ознакомиться с биографией каждого, кому отвечаю?)
Так как ты понимаешь инкапсуляцию и наследование? В ООП для веба всегда спрашиваю, а как работаешь с SESSION, COOKIE, POST, GET к примеру?
100%. Я на пайтоне начинал. Но единственный на тот момент выход в веб был через django фреймворк. А после решил, что нужен язык, который появился в следствии развития веба и создан для него.
Ключевое. Потом пригодится)
Где писал? Я хочу простоту топора. Писал, что придерживаюсь принципов KISS DRY YAGNI.
Так это вам сразу написал, когда спрашивал про ваш челлендж и кто будет судьей.
Вы путаете мягкое с горячим. Синтаксис языка и магические методы фреймворка
Ой, началось. Вы про 1937 год? Так меньше половины погибло. Сколько при падении самолёта погибает?
Продумать конструкцию, что бы не сгореть сверху, когда водород загорится? За 100 лет научились? Если бы углубились в разработку, то точно придумали бы оптимальный баланс. Но + экология, + туризм на смену круизным лайнерам. + Посадка где угодно, хоть в тайге. + Автономность недельная и больше. Если солнечными панелями обвесить. + Габариты груза не ограничиваются трубой самолёта. Дом многоквартирный на изи перевезти. Ну и виды, а так же сфера эксплуатации. С ангарами придумали бы точно. Не строили бы их, а рыли бы котлованы под них, подземные
в 1890 годах, то не нужно было бы за 130 лет строить столько дорог по всему миру. Это не то что миллиарды долларов, это за всё время триллионы долларов.
Опять же я не понимаю в чём сейчас сложность постройки машины на 4 человека по технологии квадрокопетра (4 вентилятора).
Если бы запустили дирижабли. Нормальную технологию разработали, то с такой грузоподъёмностью и энергозатратами можно было бы бесплатно почти летать
Видео ещё быстрее грузится начало. Странное замедление.
Это best practice в ООП. Сам паттерн с инкапсуляцией и SRP об этом говорит
Довольно понятны методы и вызовы, но просто не смотрели в ядро, пока ничего не упало. Совместимость между версиями - это отдельная кость. Мало того, что тащиет говно мамонта с первых версий, так еще и миграция между версиями часто приносит боль. Даже в нем приняли чрезмерность ООП и сделали функции хелперы, по типу base_path(), url(), route() из процедурном исполнении.
Вы видимо путаете классы и ООП. В энтерпрайз команде работаете или один(вдвоем)? Есть хоть один проект, посмотрю? Просто любопытно стало соотношение масшатаба к количеству кода
Основные принципы ООП - инкапсуляция, наследование. Вот такие капсулы с абстрактным наследованием делают из простого сложное. Тот же микрофреймворк, популярный в 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 файлов маршрутизации и базового ничего. За сколько без агентов разберетесь в условном фреймворке Ларавель? Там магии больше чем в Хогвартс. Чего стоит только полимарфизм. Вроде просто - одна базовая кнопка. Но в одном действии она запускает двигатель, в другом готовит еду, в тертьем запускает ракеты. А после решил поменять действие. Лезешь в базовую и вспоминаешь, где этих кнопок накидал и сколько. Если дохрена, то кодишь новый класс для новой кнопки. И так накидываешь мертвого кода. На старте это хорошо, но после масштабируемости и смены поведения, либо расширяешь класс на новые кнопки и так до бесконечности. Абстракция в ООП - это отдельное зло. Для меня очевидное решение - лучшее решение. Да. в команде без этого никуда, но в частной разработке ООП зло, когда всё делает несколько разработчиков. Энтерпрайз проекты насчитывают десятки и сотни тысяч классов, наследований. Мне это ни к чему. Буду работать в коммерц разработке над одним микросервисом, буду пилить сотни классов с инкапсулированностью. Ну или банковские приложения с очередями, гонкой. Там это приемлемо, а для меня оверинжиниринг