Property

[fedotxxl]

Работаю в аутсорсинговой компании... Часть моих друзей считает, что property нужны. Мне же кажется, что это только усложнее, код выглядит хуже и менее читабельно. Например,

myClass.a = "a"
Set myClass.obj = myObj

или

Call myClass.setA("a")
Call myClass.setObj(obj)

Что думаете по этому поводу? Главное, хрен их переубедишь. Поэтому половина кода с проперти, другая - с функциями.

 

[Akupaka]

Мне же кажется, что это только усложнее

Что тут "усложнее"? О.о

Щас припрутся явисты и начнут орать, что надо с методами, потом дельфисты запоют арию про проперти.
Вообще, то это лишь синтаксис, в обоих случаях используются методы доступа, что не нарушает требования парадигмы.
Тут не надо спорить (см подпись), тут надо договориться в рамках проекта/проектной группы как писать и все. Киньте монету.

 

[Medevic]

Ну да, в java нету. А т.к. использовать можно и java и ls, то хорошо бы соблюдать один стиль, а не делать винегрет.
По свойствам вообще не поймешь, оно только возвращает значение или только присваивает, или всё делает.

 

[turumbay]

Главное, хрен их переубедишь. Поэтому половина кода с проперти, другая - с функциями.

однох монописс да без разницы.
"когда в товарищах согласья нет..." (с) Крылов

Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Команда работает над проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять дублирующий код, анализировать и улучшать чужие классы и т. п. Со временем нельзя будет сказать, кто автор конкретного класса. Следовательно, все должны подчиняться общим стандартам кодирования – форматирование кода, именование классов, переменных, констант, стиль комментариев. Вышесказанное означает, что все члены команды должны договориться об общих стандартах кодирования. Неважно каких, но все обязаны им подчиняются.

Ссылка скрыта от гостей

Также рекомендую к прочтению:

Ссылка скрыта от гостей

Гарантировано получите массу удовольствия.

Лично мне проперти нравяца возможностью записи: Set myClass.obj = new Obj() - нет необходимости объявлять лишнюю переменную Dim myObj As new Obj().
P.S. IMHO: развод на флейм.

 

[Akupaka]

Гарантировано получите массу удовольствия

Нудятина

 

[turumbay]

Нудятина

IMHO: развод на флейм.

 

[Akupaka]

развод

Не ))) просто стиль изложения показался мне "тяжеловатым".

 

[TIA]

Проперти не столько нужны, сколько удобны в некоторых случаях.
Синтаксис обращения к проперти и к полю класса идентичный. Что удобно для изменения способа чтения/записи поля.
Скажем, был класс

Class Person
father as Person
lastName as String
End Class

Dim fil as Person, bob as Person

Обращения:

Set fil.father = bob ' запись
Set bob = fil.father ' чтение
fatherName = fil.father.lasName 'чтение

Замена на проперти никак не изменит конструкции обращений

Class Person
Property Get father as Person	
Set father = readFromExternalSource(Me).father 'получение новым способом
End Property
Property Set father as Person
Call writeFatherToExternalSource(father) 'запись новым способом
End Property

Property Get lastName as String
lastName = readFromExternalSource(Me).lastName 'получение новым способом
End Property

Property Let lastName as String
Call writeLastNameToExternalSource(lastName) 'запись новым способом
End Property
End Class

Если бы не было проперти пришлось бы менять конструкцию обращений на

Call fil.setFather(bob) ' запись
Set bob = fil.getFather ' чтение
fatherName = fil.getFather().lasName 'чтение

Т.о. проперти крайне удобны для добавления операций при чтении/записи полей.
Вопросы целесообразности прямого обращения к полям класса оставим за рамками.

Минусы: Реализация пропертей в LS не безглючная. В частности, нельзя переопределить проперти в наследнике, если он в другой библиотеке.