Property

fedotxxl

Well-Known Member
09.11.2005
614
0
#1
Работаю в аутсорсинговой компании... Часть моих друзей считает, что property нужны. Мне же кажется, что это только усложнее, код выглядит хуже и менее читабельно. Например,
Код:
myClass.a = "a"
Set myClass.obj = myObj
или
Код:
Call myClass.setA("a")
Call myClass.setObj(obj)
Что думаете по этому поводу? Главное, хрен их переубедишь. Поэтому половина кода с проперти, другая - с функциями.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#2
Мне же кажется, что это только усложнее
Что тут "усложнее"? О.о

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
2
#3
Ну да, в java нету. А т.к. использовать можно и java и ls, то хорошо бы соблюдать один стиль, а не делать винегрет.
По свойствам вообще не поймешь, оно только возвращает значение или только присваивает, или всё делает.
 
13.03.2009
625
2
#4
Главное, хрен их переубедишь. Поэтому половина кода с проперти, другая - с функциями.
однох монописс да без разницы.
"когда в товарищах согласья нет..." (с) Крылов
Единые стандарты кодирования. сказал(а):
Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Команда работает над проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять дублирующий код, анализировать и улучшать чужие классы и т. п. Со временем нельзя будет сказать, кто автор конкретного класса. Следовательно, все должны подчиняться общим стандартам кодирования – форматирование кода, именование классов, переменных, констант, стиль комментариев. Вышесказанное означает, что все члены команды должны договориться об общих стандартах кодирования. Неважно каких, но все обязаны им подчиняются.
стырено отсюда
Также рекомендую к прочтению: С. Макконнелл, Совершенный код , Питер, 2007 г. , ISBN 5-469-00822-3, 5-7502-0064-7 Гарантировано получите массу удовольствия.

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

TIA

:-)
Lotus team
15.05.2009
790
3
#8
Проперти не столько нужны, сколько удобны в некоторых случаях.
Синтаксис обращения к проперти и к полю класса идентичный. Что удобно для изменения способа чтения/записи поля.
Скажем, был класс

Код:
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 не безглючная. В частности, нельзя переопределить проперти в наследнике, если он в другой библиотеке.