Обновить
* Тема закрыта!
1. [автор] (16 ноя 2016, 11:10) [0/0] [0] [спам] [под]

Я вот не понимаю, вам навязали стандартами что ООП нужно сувать во все дырки, хотя это не верно.
Лично я считаю, что ООП нужно исключительно когда нужна инкапсуляция определенных функций и переменных в один контекст(это удобнее чем делать выборку по id к примеру).
Возьмем к примеру мой движок wge2d.
Там есть класс Sprite который в себе именно инкапсулирует все данные о спрайте, такие как данные самого спрайта(битмапу), и некоторую служебную информацию(позиция, путь до оригинального изоображения).
Здесь использование ООП полностью оправдано.
Но зачем использовать ООП там, где объекты создаются один раз за всю работу скрипта? Они там совершенно не нужны и создают не нужный оверхед по сравнению с использованием обычных функций.
Например в коде моей соц. сети совершенно отсутствует ООП, там пыха юзается исключительно как шаблонизатор, и только в паре модулях в бэкэнде есть функции.
Может я слишком много кодил нативную функциональщину, но все же, думаю мои аргументы вполне обоснованы.
Что касается namespace, хз нахера он нужен в php, разве что для более удобного автодополнения или например размещения классов с одинаковыми именами.
В дотнете namespace обоснованы тем, что namespace это часть всех языков(даже ironpython), и там просто удобно и приятно юзать namespace, для разделения классов из одной группы в другую(например в wge2d раньше были нэймспэйсы Graphics, Sound, Core, что облегчало понимание где какой класс за что отвечает), а не как в пыхе My/Namespace/MyClass.
В чем суть темы? В том что нахера использовать ООП там где не нужна инкапсуляция, объект создастся и даст больший оверхед чем использование голых функций.
Может дело в код стайле или привычке.
Но все же.

2. (16 ноя 2016, 11:14) [0/0] [0] [спам] [под]

Тему перенёс из подраздела Общение/Флуд/Оффтоп в подраздел Программирование!*

3.
bibilink * 19.01
(16 ноя 2016, 12:13) [0/0] [0] [спам] [под]

З расширением проекта весь твой нативный код превратится в лютый "лапша-код", с проблемной поддержкой/расширением функционала для других возможных кодеров да и для тебя (спустя некоторое время).

ООП для грамотного раскладывания по полочкам и структурирования кода.

Не умеешь мыслить обтектами, не пиши.
А главная ошибка, это пытаться накладывать опыт с другим языком на работу с PHP.

4. [автор] (16 ноя 2016, 12:38) [0/0] [0] [спам] [под]

bibilink, по твоей логике - ядро линукса ровно как и остальных ОС - лапша код.
В контексте пхп виновата каша в стандартной библиотеке.

5.
bibilink * 19.01
(16 ноя 2016, 12:48) [0/0] [0] [спам] [под]

monobogdan, C не обьектно-ориентированный язык, а ты такой же великий программист как Торвальдс, по этому ты, как и он, не допустишь лапша кода. Да.

6. [автор] (16 ноя 2016, 15:44) [0/0] [0] [спам] [под]

bibilink, C может быть объектно ориентированным при некоторой модификации рантайма, однако такое возможно только с GCC.
Ядро Linux пишет не только Торвальдс но и орава добровольцев включая гугл, у которого свой кодстайл.
И каши там нет.
Так что ваши убеждения не верны.

7.
bibilink * 19.01
(16 ноя 2016, 15:53) [0/0] [0] [спам] [под]

Да все верно, твоя квалификация == квалификации Торвальдса и сотрудников гугла.
Говорю же.

8.
3KZO * VIP 4.87
(16 ноя 2016, 15:53) [0/0] [0] [спам] [под]

Смысле темы? Автор тормаз. Тему оффайте, ребята.

9. [автор] (16 ноя 2016, 15:59) [0/0] [0] [спам] [под]

bibilink, причем здесь квалификация? Мы вроде говорили о том зачем нужен ООП в простых проектах, где не требуется инкапсуляция. Вместо этого вы начали нести какую то чепуху про удобство и.т.д.
Да, это несомненно правильно но исключительно в контексте когда объектам требуется инкапсуляция.
А например в классе рендерера body зачем нужен ООП, если он за весь проход скрипта будет рендерится один раз? Это создает уже оверхед.
Ну а так да, ООП удобнее но оверхед...

10. [автор] (16 ноя 2016, 15:59) [0/0] [0] [спам] [под]

3KZO, скорее тормоз ты, объективного мнения в твоем сообщении я не нашел.

В теме: 1 чел., 28 заходили, 0 подписаны.
Скачать тему | Файлы темы | Фильтр сообщений