-
-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Приватные свойства - зачем? #137
Comments
For get Private properties and getter/setters allow easier to make changes in the future, create readonly or writeonly properties, also in most cases getter or setter perform additional actions (for example, in Clone are needed in order for the widgets to be immutable. |
Делать getId() пабликом бессмысленно - т.к. на каждый вызов он будет генерить новый id за счёт накручивающегося счётчика + у данных виджетов "по хардкору" вписан суффикс (-tabs, -alert и т.д.) который может быть изменён в следующих релизах или вообще исчезнуть. И перефразирую - readonly свойства нужны, не спорю. НО сейчас получается нет никаких read свойств, никаких геттеров - по сути мы имеем сплошное writeonly, т.е. мы можем установить значение, но не можем обратно получить. А это зачастую нужно и именно после манипуляций с этим свойством самим виджетом. Ну и ИМХО - иммутабельность иммутабельностью, но может не стоит возводить её в абсолют, особенно там где она не "делает погоды"? Т.е. вот тут я не вижу от этого пользы, т.к. всё что требуется - это отрисовать нужный мне контент, в нужном мне месте в зависимости от виджета, всё. Но вижу вред - вынужден ждать когда будут потрачены человекочасы на написание геттеров к каждому свойству у которого есть сеттер и не факт, что они вообще будут написаны (хотя хватило бы просто сделать часть свойств, которые может установить пользователь публичными) Т.е. к примеру я в миграциях повсеместно напрямую использую ColumnSchemaBuilder, чтобы дополнить недостающие в MigrationBuilder нативные pgsql типы (point, *range, uuid) и никаких проблем с отсутствием в нём иммутабельности я не обнаружил |
In If getters real need (has use cases), then we should added their. In modern IDEs create base setters/getter very simple. For example, in PhpStorm: Immutable objects making impossible to make certain types of mistakes. When we pass an object to somewhere, we are sure that it will not change. |
что удивительного в доступе к свойствам через сеттер/геттер?
почитай о immutable objects
смысл в том что у тебя нет прямого доступа к свойству, ты вызываешь сеттер для его изменения, данных метод может нормализовывать/форматрировать передаваемое значение что гарантирует корректную запись в свойстве. Для понимания подобных концепций стоит вначале ознакомится с SOLID |
Доброго дня. Т.к. свой новый корпоративный проект я решил сразу начать на yii3, то возник ряд вопросов/непониманий. Относятся они наверно ко всему yii3, но живой кейс возник с виджетом табов, поэтому напишу сюда.
Итак имеем:
Мой "живой" случай в идеале, но не как сейчас:
Т.е. мне всё-равно какой id сгенерится виджетом, у меня к нему не привязано никаких CSS, ни чего другого. Но сейчас я вынужден каждый раз выдумывать этот самый id элемента, т.к. не могу получить приватный $options
Вопрос - а почему эти свойства не сделать публичными?
При этом, если допустить ошибку и забыть при конфигурации указать "()" в конце, то yii3 заботливо предлагает добавить "$" в начало, чтобы установить свойство - что опять-же не работает с приватными свойствами. Но как минимум я так полагаю, что задумка такая была, но сейчас я мало где вижу ей применение, т.к. практически всё либо private, либо в лучшем случае protected
Заранее благодарен
The text was updated successfully, but these errors were encountered: