Ну да, ещё он написал это: Что есть размазывание абстрактных соплей и ворчание о несуществующих проблемах. Это ты ничего не понял. У меня длинный код и овер-дофига классов подключено к родительскому классу из овер-дофига файлов. Если я начну сейчас что-то ограничивать, то наверняка где-то методе на двухсотом мозг поплывёт и я запривачу то, что где-то используется вне класса. Я вас понял, что разграничивать области видимости это круто, модно, молодёжно. Постараюсь приватить всё лишнее в будущем, и даже нижнее подчёркивание перед заприваченными методами обещаю ставить. Но переделывать то что уже написано сейчас - сложно, долго, рисково и главное бесполезно.
Мне кажется, что это служит зачастую другому программисту подсказкой о том, что конкретный метод используется только внутри класса, и не надо пытаться изменить его извне, так как ты рискуешь нарушить работу/логику/механику класса. Да и сам ты создавая дохрена классов не всегда можешь вспомнить, что можно изменять, а что нет. Так, что хотя бы в этом есть несомненный профит.
Просто есть внешние методы и свойства, они нужны для того, кто пользуется объектом. А есть внутренние. Они нужны для работы объекта. Точка. Когда хочешь, чтобы машина повернула - ты крутишь руль, а не лезешь на ходу к передней оси с тем, чтобы что-то там сдвинуть руками. Потому что ты не должен это делать. Поворот колеса обеспечивается взаимодействием ряда приватных узлов. Тебе даже не обязательно знать, как они работают. Чтобы инициировать работу этих приватных узлов, у тебя есть узел публичный - руль. С простым и понятными API. Повернул в нужную сторону - машина делает маневр. Сильнее повернул - резче маневр. А сама рулевая система может быть устроена кучей способов. Может меняться от машине к машине. И тебе пофигу. Оно инкапсулировано внутри. Внешний интерфейс неизменен. В этом вот суть. Наружу смотрит только то, что должно туда смотреть. Если у тебя снаружи объекта юзаются какие-то методы, специфичные для его внутренней логики, завязанные на его контекст, то у тебя огромные проблемы в архитектуре. Что уж там, они у тебя уже есть. Судя по тому, что ты боишься что-то там менять, у тебя уже безумная связность и нет никакого контроля над системой. Нет согласованности в ней. Нет абстрактной структуры. Есть нагромождение костылей, которые ты боишься трогать, потому что один достанешь - и все обвалится.
Я ещё люблю везде писать $this->blabla(). Но если blabla() будет приватным, то надо же будет везде переписывать на self::blabla() ? Вообще использовать $this внутри класса это нормально, или эта штука скоро будет деприкэйтед?)
Где ты такой бред прочитал? $this использовать внутри классов в php - это необходимость, а не "нормально" или "нет". Вызов через self:: - это для статических, а не приватных методов (разница большая)
@NerdRage зачем использовать термины, которые не понимаешь? Разберись в терминологии, и может быть этого будет достаточно, чтобы ответить на сабж)
Вот, стоит попробовать. Например ты попробуешь и откажешься потому-то и посему-то. Тогда это будет аргументированная позиция человека с опытом. с подачи ты обговнякал важные для людей вещи, эссно они на тебя сагрились, и не важно, прав ты или нет поработай над формой подачи просто не нужно всегда пыжиться умным очень удобно казаться дураком в таких случаях - спрашиваешь и получаешь ответы С возврастом ещё приходит понимание, что лучше сказать "я не знаю, расскажи скорей", чем задрать нос и сделать вид, что ты в теме, и просрать возможность узнать что-то новое.
ну зачем так, все когда то чего то не понимали)) вот к примеру я)) когда то давным давно еще на спектруме на бейсике что то делал и под ДОС программировал на паскале)) даже писал на СУБД Фокспро когда мне 13 лет было) популярная штука была в свое время в госучереждениях) потом пошел больше по железякам выступать) в сервисе работал) потом ушел в продажи)) а потом уже лет в 30 с копейками потянуло опять в програмирование)) и вот я уже 5 лет что то пишу на пхп)) пишу сам) ) без команды)) кое что пишу для себя) кое что для клиентов)) очень хочется поработать в команде - но реально как то страшно)) вроде не было такой проблемы у меня еще с которой бы я не смог разобраться сам или с помощью гугла)) а в команде работать не умею) потому что никогда не работал) и когда то у меня тоже был такой вопрос зачем приватные, защищенные методы)) правда я погуглил и нашел ответ) форум на то и форум что бы кто то спрашивал)) кто то отвечал)) извините если что) --- Добавлено --- может)) если человек не сталкивался с ООП, а только с процедурным программированием то классы и их свойства и методы могут быть непонятны) --- Добавлено --- мне в свое время очень помогло разобраться с классами и всем остальным YII2)) я ради интереса себе его поставил и покопал)) много чего узнал интересного)
Мне кажется что вот в этом-то и хорошо ООП. Один программист пишет один класс. Другой программист ещё какой-то класс. И им совершенно не нужно знать, что внутри этого класса. Не нужно разбираться в чужом коде. Нужно только отправить запрос и получить ответ. Как правильно написал @Fell-x27 про руль в автомобиле. Когда автомобиль собирают, кто-то разрабатывает двигатель, например. Но разработчику ходовой не интересно как он устроен, ему нужен только итог, крутящийся вал. А разработчику двигателя по большому счету не интересно, что там в ходовой. А конечный пользователь только давит на педальки и крутит рулём)
в процедурном программировании за это отвечали фунции)) а класс это просто набор функций)) просто там дробление было всего этого)) а класс это просто набор функций (методов) достаточный для работы с каким либо объектом)
У объектов класса есть ещё состояние (то бишь поля, по простому), а у функции состояния нету. В этом всё дело. А вообще, главное в ООП - это полиморфизм, без него классы смысла никакого не несут.
ну это да, наследования у функций нет)) .. а еще объекты можно сериализовать и хранить в БД))) тоже интересно)
Вот в этом согласен. Но понимать это я стал только после того как начал изучать фреймворки. Когда смотришь код написанный профессионалами начинаешь понимать намного больше. Что, кстати и советовал бы ТС.