Читаю это: https://php.ru/manual/language.oop5.visibility.html Я понял как это работает, но не понял в чём профит. Почему нельзя просто опускать ключевые слова public, private, protected и тем самым делать всё public? Есть какой-то ощутимый профит в ограничении области видимости, например в производительности скрипта, или это просто прогерские загоны?
как минимум оно всё повылезает в автоподсказках при использовании, и будет грузить тем, что трогать нельзя. в производительности программиста это способ ускорить разработку и не давать другим говнякать твою внутреннюю механику а ты реально 14-летний ребёнок со спермотоксикозом, который обсирает всё, что не понимает? ты не работаешь в команде - тебе всё равно что там, ты держишь в голове все свои десять классов, и тебе хватает. Когда работаешь в команде или выкладываешь проект в паблик, то объяснять людям что им никогда не нужно дёргать какой-то метод, который служит для внутренних целей - это маразм. Ещё больший бред делать это про каждый класс своей либы.
В автомобиле для того, чтобы поднять обороты двигателя, используется целый комплекс механизмов и, зачастую, электроники. А водителю дали только педаль газа. Я не понимаю смысла таких ограничений. Почему бы все это не высунуть в салон? От этого есть какой-то профит, или это просто инженерские загоны?
Понятно, значит делать всё пабликами это просто быдлокодерство. Отлично, это как раз по мне. --- Добавлено --- А со статическими свойствами и методами та же история? Никакого профита нет, просто навязанная академическая правильность? https://php.ru/manual/language.oop5.static.html
@NerdRage, от видимости профит в том, что клиенты класса потом не смогут полезть туда, куда их не просят, и не смогут ничего сломать. Статические методы работают совсем по-другому, они не требуют создания экземпляра, т.е. в них можно вынести методы, не зависящие от контекста конкретного объекта, но имеющего отношения к классу семантически. Хочешь профита по скорости выполнения - программирую без ООП. ООП замедляет выполнение. На копейки правда, но замедляет. А потом откажись от функций - тоже замедляют, представь себе Нужно стек выполнения создать, поместить туда параметры, потом вытаскивать из этого стека возвращаемое значение - просто уйма работы.
иногда мне кажется, что человек, который настолько не хочет нихрена познавать, не должен программировать но я уверен, что ты тоже считаешь, что твоё призвание не программировать, а повелевать и править. Просто ты ещё не должил до нужной карьерной позиции.
не, это владелец форума повышает крутость своих же страниц можно обойти сделав так: php.net php.%6eet пример: http://php.net/manual/en/function.parse-str.php --- Добавлено --- он так утвержает каждый день по любому аспекту жизни, в котором ни бум-бум при этом чуйство собственной значимости выше крыши
А потом откажись от инклудов, они тоже ппц замедляют. А потом вовсе откажись от PHP. Как Игорь сказал, это не мы, это вышестоящая инстанция. Модеры как раз против этого и просили неоднократно выпилить эту фичу, но увы. Чтобы ссылка не ломалась, убирай в конце ".php", а в начале замени "http" на "https". Проверено многократно. --- Добавлено --- https://php.net/manual/en/function.parse-str
Не зовите меня программистом, я быдлокодер. Ты попал в точку - без сарказма. Я не особо хочу всю жизнь работать программистом, рано или поздно я уйду в бизнес, как завещал Медведев, либо напишу супер-пупер-инновационную разработку и продам её в Сколково. А пока - я хочу писать красиво и правильно, ну вот честно. Потому что кризисы кругом и оранжевые революции, а программисты нужны всегда и в любой стране. Но когда я вижу какую-то штуку, которую вроде как "по учебнику" нужно использовать, но профита от неё никакого нет, то и смысл для меня теряется.
да чета непохоже. ты ж не спрашиваешь, зачем умные дяди делают то, чего я не понимаю ты говоришь - это хрень которая ненужна. и только может быть потом ты думаешь, что кому-то может и нужна. При такой точке зрения невозможно ни управлять, ни создать ничего путного. Вот тебе правильная точка зрения: в разных ситуациях полезно разное. Так-то. Т.е. тебя должны интересовать границы применимости того или иного подхода. Вот тогда будет звучат правильно. При этом суть не поменяется. Просто ты начнёшь говорить как разумный взрослый человек.
ты профит видишь только в производительности. А профит от ООП вообще в другом. Вот написал ты какую-то большую систему, в которой у тебя 1000 классов. Если ты их правильно написал, то ты можешь взять, поменять реализацию одного из них, и если при этом интерфейсная часть не изменилась, остальные 999 классов продолжают работать. А по производительности - я уже писал, ООП замедляет выполнение, но ускоряет разработку. Хотя, поскольку в PHP всё создаётся динамически, здесь замедление от ООП должно быть меньше, чем в компилируемых языках, типа C, где часть переменных создаются ещё в процессе компиляции.
Чтобы снять вопрос производительности: права доступа при выполнении опкода не сэконят тебе совершенно ничего. Статические и не статические методы - аналогично. В разных релизах пыха статика была то быстрее то медленнее не статики. Соответственно, вы на 99.00% вероятнее нахерачите что-то в логике что замедлит приложение кратно больше чем все экономии на спичках. Д кеширующие байт-код еще больше нивелируют "спички" поэтому лучше на их настройку время потратьте
А потом настанет момент, когда все вылизал, спички заточил, все чинно-благородно, код идеален, а база данных как бы говорит тебе - иди в жопу, мне нужно подумать. И ты такой весь супер производительный сверхскоростной с одинарными кавычками летишь на этой супер-скорости в ту самую жопу, куда тебя послала БД. Там тебе сидеть не нравится, ты начинаешь накручивать поверх БД какой-нибудь мемкеш, который тоже вносит оверхеды. А потом сбоку прикручиваешь еще что-то. А потом до тебя доходит, что вылизывать один компонент, отказываясь ото всего на свете, ради его скорости - глупо, потому что связка лошадей не может скакать быстрее самой медленной лошади в связке. А потом ты откроешь для себя чудесный мир "дальней перспективы", который ставит раком твое представление о производительности кода. Потому что, к примеру, Apache+modphp, в чистом виде - быстрейшая связка из возможных. В ближней перспективе. А в дальней - это лежащий кверху пузом сервер. Apache+modphp+nginx в ближней перспективе работает медленнее из-за nginx-а, вносящего свой оверхед, свои буферы, и вообще это дополнительный узел в сетевом стеке. Но в дальней перспективе, под нагрузкой, такой сервер будет работать лучше, а, следовательно, производительность такого решения будет выше. Вывод - "Не гонись за здесь и сейчас, думай и планируй наперед".
Разговор зашёл не в то русло. Для меня не весь профит сводится к производительности. Удобство написания это тоже профит, именно поэтому я когда-то ушёл от процедурного программирования. @igordata выше написал, что от областей видимости единственный профит в том, что у тебя IDE не будет высвечивать лишних подсказок при обращении к ссылке на класс. Я его услышал и согласен что это полезно. Но это на столько незначительный профит, что переписывать весь свой код ради этого я не стану. Слишком велик риск поломать что-то в процессе, ограничив область видимости слишком сильно. А то что второй программист способен поломать механику, вызвав что-то не оттуда - для меня это вообще не существующая проблема, у меня ни один метод на такое не способен. Так что сложно представить о чём вы.
Ты так и не понял, что это и зачем нужно, ок, яснопонятно. РАЗРАБОТЧИК, ПОМНИ, ТЫ СИЛЬНО РИСКУЕШЬ КАЖДЫЙ ДЕНЬ!