открытые переменные класса в языке С++
IMHO const public вполне допустим. Если есть переменная, которая ставится один раз при инициализации, то можно сделать ее const public, чтобы избежать многочисленного делегирования по типу
class X {
private:
const Y* y;
public:
bool doSomething1 { return y->doSomething1; }
bool doSomething2 { return y->doSomething2; }
bool doSomething3 { return y->doSomething3; }
}
IMHO Изучая ФЯ и CLOS я пришел к выводу, что деление на private/public далеко не так важно как кажется. Для полноценной поддержки ООП в языке более важны другие механизмы. Существуют языки, где ООП реализовано IMHO не хуже чем в C++, но при этом все методы и поля public, при этом никаких проблем не возникает.
class X {
private:
const Y* y;
public:
bool doSomething1 { return y->doSomething1; }
bool doSomething2 { return y->doSomething2; }
bool doSomething3 { return y->doSomething3; }
}
IMHO Изучая ФЯ и CLOS я пришел к выводу, что деление на private/public далеко не так важно как кажется. Для полноценной поддержки ООП в языке более важны другие механизмы. Существуют языки, где ООП реализовано IMHO не хуже чем в C++, но при этом все методы и поля public, при этом никаких проблем не возникает.
Если это математическая библиотека, открытые поля я допускаю.
Если это реализация не слишком навороченной бизнес-логики, лучше обойтись без них.
Короче, если не предвидятся конструкции вида
то лучше сделать открытые поля и не парясь писать
PS. C# с этой проблемой борется красиво и эффектно.
Если это реализация не слишком навороченной бизнес-логики, лучше обойтись без них.
Короче, если не предвидятся конструкции вида
vector.SetX(v1.GetX + v2.GetX;
vector.SetY(v1.GetY + v2.GetY;
то лучше сделать открытые поля и не парясь писать
vector.x = v1.x + v2.x;
vector.y = v1.y + v2.y;
PS. C# с этой проблемой борется красиво и эффектно.
ООП, говоришь, с публичными полями. А как же инкапсуляция?
PS. C# с этой проблемой борется красиво и эффектно.Да.
Правда, всё-таки приходится перекомпилить все депендент проекты при превращении открытой переменной в проперти.
А ещё я тут недавно узнал Страшное про
public const
Типа, оно подставляется как значение в депендент проекты на этапе компиляции в мсил. Рояль в кустах.
А вот ещё, оффтопик:
Кто-нибудь может мне объяснить, почему разработчики .нет не смогли включить туда атрибут [Const], применяющийся к методам (аналог плюсового const)? Тогда нахаляву получились бы readonly коллекции и всё такое.
Правда, всё-таки приходится перекомпилить все депендент проекты при превращении открытой переменной в проперти.Несекрет в том, что поля должны быть приватными изначально
public constЭто неприятно. Поэтому лучше пользоваться readonly полями или вообще пропертями.
Типа, оно подставляется как значение в депендент проекты на этапе компиляции в мсил. Рояль в кустах.
Кто-нибудь может мне объяснить, почему разработчики .нет не смогливключить туда атрибут [Const], применяющийся к методам (аналогплюсового const)? Тогда нахаляву получились бы readonly коллекции и всётакое.Казлы они. Хотя может и есть какое-то мудрое обоснование
Думаю, что можно-таки ввести такой атрибут и натренировать fxcop так, чтобы он предупреждал о вызовах неконстантных методов, относящихся к this, из константных. Не знаю, правда, можно ли в fxcop поймать изменения значения поля класса из константного метода. Если нет, то фиговое будет решение.
Конечно, наличие встроенной поддержки константных методов в языке и компиляторе было бы куда приятнее, чем вручную реализовывать логику, работающую в run-time и бросающую InvalidOperationException при обращениях к изменяющим функциям. Хотя бы в плане unit-тестирования проще.
>> Несекрет в том, что поля должны быть приватными изначально
Дык одна из прикольностей пропертей в том и состоит, что они выглядят просто как поля. С точки зрения кодера, но не с точки зрения компилятора.
>> Думаю, что можно-таки ввести такой атрибут и натренировать fxcop так
Задолбаешься. Я как-то приблизительно пробовал (только у меня своя бродилка/верифаилка была). Там очень много непонятных и стрёмных вещей - ты думаешь зря я про "автоматическое получение readonly коллекций" сказал? - так вот, если это самому писать, то они должны получиться (в смысле, что когда ты пишешь public [Const] ValueCollection Values { get; }, то тебе не нужно определять ValueCollection как ридонли но автоматичностью там и не пахнет - прогать и прогать =(
Дык одна из прикольностей пропертей в том и состоит, что они выглядят просто как поля. С точки зрения кодера, но не с точки зрения компилятора.
>> Думаю, что можно-таки ввести такой атрибут и натренировать fxcop так
Задолбаешься. Я как-то приблизительно пробовал (только у меня своя бродилка/верифаилка была). Там очень много непонятных и стрёмных вещей - ты думаешь зря я про "автоматическое получение readonly коллекций" сказал? - так вот, если это самому писать, то они должны получиться (в смысле, что когда ты пишешь public [Const] ValueCollection Values { get; }, то тебе не нужно определять ValueCollection как ридонли но автоматичностью там и не пахнет - прогать и прогать =(
Плюс потребуется "параноидальное" присваивание - [Const]Values можно присвоить только в переменную, объявленную как [Const]ValueCollection.
А ещё все эти ограничения пойдут по влагалищу если учесть мультитредность.
А ещё все эти ограничения пойдут по влагалищу если учесть мультитредность.
Оставить комментарий
Ventalf
Допускаете ли вы открытые переменные.Мне кажется что будут люди которые иногда допускают такое. Так же будут люди которые категорически такое не допускают.
Мне интересно выслушать мнение обоих сторон.
*. при каких обстоятельствах вы допускаете открытые переменные?
или же
*. почему вы категорически не допускаете открытых переменных?