Публичные поля класса - делать, как поля или как свойства?
Если оба кода по ту и по другую сторону от стыка доступны в любой момент в исходниках с возможностью перекомпиляции, то удобнее делать поля.
Во всех книжках по ООП пишут, что нельзя делать публичными поля класса.Книжки пишут те, кто не взяли на работу программистами?
Это полный бред, нельзя быть таким категоричным. Да, очень часто лучше сделать так:
private:
mytype var;
public:
const mytype &get_var const;
void set_var(const mytpe& v);
так надо делать, когда хотелось бы имет не просто присванивание, а всякое изменение сопровождалось каким-то действием -- пересчетом других переменных, отображением куда-либо, еще каким-то действием.
Но часто бывает, что можно просто сделать и открытой переменную.
В С#, если не ошибаюсь, есть понятние "свойства" -- это как раз "переменная" которая присваивается не простым присваиванием и отдает значение тоже...
+ пользователь класса не должен развлекаться рефлекшеном.
А вообще в 2005 студии, насколько я помню, можно породить по полю проперти нажатием двух кнопок. А ещё я давно писал макрос для этого, но он потерялся.
А вообще в 2005 студии, насколько я помню, можно породить по полю проперти нажатием двух кнопок. А ещё я давно писал макрос для этого, но он потерялся.
А еще для этого есть Resharper.
Не вижу смысла делать поле свойством, если оно реально глупое, т.е. нет никаких ограничений на доступ к нему.
Не вижу смысла делать поле свойством, если оно реально глупое, т.е. нет никаких ограничений на доступ к нему.
Во всех книжках по ООП пишут, что нельзя делать публичными поля класса.Не пишут такого "во всех книжках".
Не пишут такого...Ну уж противоположного утверждения, мол "пишите, где вздумается, поля, потом переделаете" я точно ни в одной книжке не встречал. А в то же время, мне тоже кажется, что это самая здравая позиция, когда в языке есть property.
тем не менее позволю себе указать ссылочку на другое мнение
"С самого утра веселье, респект 
"
Опять за своё? Решил наехать узконаправленно, на Java&Eclipse? Не только в Eclipse [JDT], но и в любой нормальной IDE для Java есть автоматическая генерация getter-ов и setter-ов. И что?
Повторяю, Java нацелена но то, чтобы быть простой. Когда за строчкой a = 5; стоит чёрти-чего (set {...}) - это не по-Javaвски.
Теперь по делу. Простые "структуры" типа пары координат даже самый отмороженный Java-ер скорее всего сделает так:
"Опять за своё?
Решил наехать узконаправленно, на Java&Eclipse? Не только в Eclipse [JDT], но и в любой нормальной IDE для Java есть автоматическая генерация getter-ов и setter-ов. И что?Повторяю, Java нацелена но то, чтобы быть простой. Когда за строчкой a = 5; стоит чёрти-чего (set {...}) - это не по-Javaвски.
Теперь по делу. Простые "структуры" типа пары координат даже самый отмороженный Java-ер скорее всего сделает так:
public class Point {
public int x;
public int y;
}Во всех книжках по ООП пишут, что нельзя делать публичными поля классаНе во всех уже. Это старый подход.
Если есть код типа,
property Modified: boolean read FModified write FModified;
то смысла в приватном FModified совершенно нет никакого. Он подподает под одно из определений рефакторинга и надлежит быть замененным на обычный публичный Modified.
Если нужно будет привязать какие-либо действия - снова можно всегда вернуться к свойству.
Справедливо и для С#.
Подробнее см. лит-ру по рефакторингу.
Вывод: ты прав
Замечу, что в Eclipse [рекомендуемые] правила пользования классами прописаны в документации. Вспоминается пример org.eclipse.jface.text.Position:
"...
Field Summary:
[public] int length - The length of the position
[public] int offset - The offset of the position
...
Because position updaters are freely definable and because of the frequency in which they are used, the fields of a position are made publicly accessible. Clients other than position updaters are not allowed to access these public fields.
..."
Т. е. одни клиенты работают с этими полями напрямую. Все остальные - вызывают getPosition getLength и т. д.
"...
Field Summary:
[public] int length - The length of the position
[public] int offset - The offset of the position
...
Because position updaters are freely definable and because of the frequency in which they are used, the fields of a position are made publicly accessible. Clients other than position updaters are not allowed to access these public fields.
..."
Т. е. одни клиенты работают с этими полями напрямую. Все остальные - вызывают getPosition getLength и т. д.
Т. е. одни клиенты работают с этими полями напрямую. Все остальные - вызывают getPosition getLength и т. д.за этим компилятор следит?
Т. е. одни клиенты работают с этими полями напрямую. Все остальные - вызывают getPosition getLength и т. д.а вот это полный бардак!
Нет. Сами клиенты.
Это не бардак. Это прилагаемая к классу инструкция по его использованию.
Дело в том, что если ты просто сделаешь класс public, сделаешь какие-то методы и поля public без дополнительных разъяснений и предоставишь свой класс широкой общественности, то больше ты уже не сможешь что-то в этом изменить, даже если очень захочешь. Иначе клиенты, которые используют твой код, больше не смогут его использовать. Вряд ли это их сильно осчастливит.
Поэтому в Eclipse ясно прописано, какие классы можно наследовать или инстанциировать, а какие нет.
Дело в том, что если ты просто сделаешь класс public, сделаешь какие-то методы и поля public без дополнительных разъяснений и предоставишь свой класс широкой общественности, то больше ты уже не сможешь что-то в этом изменить, даже если очень захочешь. Иначе клиенты, которые используют твой код, больше не смогут его использовать. Вряд ли это их сильно осчастливит.
Поэтому в Eclipse ясно прописано, какие классы можно наследовать или инстанциировать, а какие нет.
Поэтому в Eclipse ясно прописано, какие классы можно наследовать или инстанциировать, а какие нет.Это должно быть реализовано в языке(и средствами языка а не в документации.
// Это должно быть реализовано в языке
Ничего и никому не должно. Не нравится - не пользуйся.
Вообще, всегда может появиться концепция, который в данный момент в языке нет. Если ты такой идеалист, можно, конечно, сразу прекратить пользоваться языком...
Кстати, не знаю, как с этим в C#, а вот в C++ та же проблема, из-за чего Microsoft добавила в свой VC++ слово published (наряду с public) - в стандартном C++ его нет.
Ничего и никому не должно. Не нравится - не пользуйся.
Вообще, всегда может появиться концепция, который в данный момент в языке нет. Если ты такой идеалист, можно, конечно, сразу прекратить пользоваться языком...
Кстати, не знаю, как с этим в C#, а вот в C++ та же проблема, из-за чего Microsoft добавила в свой VC++ слово published (наряду с public) - в стандартном C++ его нет.
Оставить комментарий
6yrop
Во всех книжках по ООП пишут, что нельзя делать публичными поля класса. Для доступа из вне к полям следует вводить дополнительные методы: геторы, сеторы. В Eclipse даже автогенерация кода для этого есть.Насколько я понимаю, в C# такой фигней можно не страдать. Если при обращении к полю никаких дополнительных действий не требуется, то его можно сделать публичным. Потом, если потребуется дополнительные действия, поле можно преобразовать в свойство. Внешние классы этого почти не почувствуют, их нужно только перекомпилировать (проблем с перекомпиляцией не вижу).
Я прав?