Property Vs Function?

Тема в разделе "Lotus - Программирование", создана пользователем fedotxxl, 11 окт 2008.

  1. fedotxxl

    fedotxxl Well-Known Member

    Регистрация:
    9 ноя 2005
    Сообщения:
    614
    Симпатии:
    0
    Зачем нужен property, когда можно возвращать ответ через функцию?
     
  2. Duedev

    Duedev Гость

    проперти - свойство по сути та же функция, т.е. есть заголовок и входные параметры, тело и возвращаемы результат. Свойство - это дань объектно- ориентированому программированию...... Т.е это способ описывать поведение отдельных объектов.
    Другими словами, Ваш вопрос можно переформулировать следующим образом: А зачем вообще нужно объектно ориентированное программирование? ....
    Попытайтесь сами ответить на этот вопрос.
     
  3. fedotxxl

    fedotxxl Well-Known Member

    Регистрация:
    9 ноя 2005
    Сообщения:
    614
    Симпатии:
    0
    Duedev
    Прости, разве в Java есть проперти? Насколько я знаю, нет. И чувствуют себя получше чем LS в плане ООП
     
  4. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    "90% мужчин, умерших до 60 лет ели огурцы. Вывод: огурцы смертельно опасны"(с)
    В Java ООП лучше, чем в LS; в JAVA нет property. Вывод: property вредны для ООП.

    В LS нет виртуальных методов, нет производных классов от всех NotesXXX- классов.. etc. Вот где недостатки LS, а не в наличии пропертей
     
  5. Yakov

    Yakov Гость

    fedotxxl
    Property служит для упрощения интерфейса. Вместо пары getter/setter Вы можете использовать property.
    Пример. Есть класс, описывающий точку на плоскости. Точка имеет координаты. Интерфейс при отсутсвии свойств (Java, к примеру):
    getX(), getY(), setX(x), setY(y), moveTo(x, y).
    Интерфейс со свойствами:
    x, y [, moveTo(x, y)].
    Пример использования:
    1. Без свойств
    If point.getX() < 0 Then point.setX(-point.getX())
    2. Со свойствами
    If point.x < 0 Then point.x = -point.x

    Если же Вы используете read-only property да еще с именем вида getXXX, то тут будет уместней функция. (Интимная подробность. Компилятор всегда создает методы свойства парами. Даже если Вы объявили только Get-метод свойства, компилятор создаст, по крайней мере, описание и Set-метода.)
    (Лирическое отступление. В одной из весьма распространенных СЭД у одного из классов есть read-only свойство по имени SetName: Property Get SetName As String. Я испытал, что называется, когнитивный диссонанс, когда первый раз это увидел. Потом дошло, что это "Имя комплекта".)
    Вообще, чтобы понять всю прелесть пропертей, можно почитать исходники на Delphi (особенно те, что писали сами разработчики Delphi - VCL, к примеру) или C#.


    Constantin A Chervonenko
    В LS есть виртуальные методы. Более того, в LS все методы (и свойства) класса виртуальные. Методы подклассов подменяют (override) методы класса-предка. Другое дело, что нет возможности перегрузить (overload) один метод другим методом с этим же именем, но с другой сигнатурой.
    А все NotesXXX классы нужно воспринимать как внешние. (Они и есть внешние, не "родные" языку, ибо написаны на C++ и подключаются из dll при помощи Uselsx "%LSXBE" и Uselsx "%LSXUI", но это скрывает от нас компилятор.) И если нужно, то писать классы-обертки.
     
  6. Kee_Keekkenen

    Kee_Keekkenen Well-Known Member

    Регистрация:
    5 сен 2006
    Сообщения:
    616
    Симпатии:
    4
    сеты и геты используются для обращения только к приватным полям (переменным) классов..
     
  7. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Ну, терминологию я уже забыл :blink:
    Необходимость-же писания классов-оберток полностью девальвирует всяку ООП-шность стандартных "классов", которые только синтаксис имеют ООП-подобный, но не имеют тех свойств-признаков ООП (наследование, полиморфизм .. что там еще было? Инкапсуляция вроде как есть)
     
  8. Kee_Keekkenen

    Kee_Keekkenen Well-Known Member

    Регистрация:
    5 сен 2006
    Сообщения:
    616
    Симпатии:
    4
    это последнее в скрипте и осталось от ООП
     
  9. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    Constantin A Chervonenko, что-то Вы путаете :(
    LS абсолютно поддерживает стандарты ООП, кроме возможности наследования от "стандартных" классов, причина была указана выше - "стандартные" классы внешние по отношению к "нашему" коду...
    А обсуждать ООП свойства внешних классов уже нет смысла, хотя, и наследование и полиморфизм там есть, но разнообразие классов не показывает их явно, но об одном наследовании, как минимум, упоминается в справке - "NotesRichTextItem inherits from NotesItem class".
    Еще есть классы по работе с XML, но они реже используются и не являются "стандартными" LS-классами в общем смысле, но тоже имеют дерево классов...
    LS, являясь надмножеством языка Basic, является объектно-основанным языком программирования и расширен до объектно-ориентированного, т.е. расширяет язык возможностью создания собственных (user defined) классов.

    О перегрузке методов вообще отдельный разговор, на сколько мне помнится, то перегрузка не входит в парадигмы ООП, так же как и свойства, а является лишь расширением компилятора и линкера, хотя, я мог и отстать от теории :)

    Свойства как расширение классов придают не более чем удобо-читаемый интерфейс, для программистов, использующих классы, которые эти свойства и описывают/реализуют...
    Т.е. программист может использовать традиционно Set/Get методы, а может описать правила доступа к полям класса, которые реализовываются с помощью тех же методов, но имеющих другой синтаксис, позволяющий использовать в качестве вызова лишь одно имя и для записи и для считывания, т.е. это некоторая перегрузка вызова метода: в случае если используется конструкция считывания поля, происходит вызов Get метода, иначе Set...
    Я считаю, что свойства всего лишь для удобства, хотя явно описанные методы доступа позволяют создавать более строгие конструкции кода, в которых явно видно чтение и установка значения поля...
     
  10. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    sax_ol, ты меня не правильно понял, либо я не корректно написал :(
    имелось в виду, что использование обычных методов вместо свойств явно описывают действие, т.е.:

    call someObject.SetSomeProperty(SomeValue)
    someValue = someObject.GetSomeProperty()

    выглядит строже чем

    someObject.SomeProperty = SomeValue
    SomeValue = someObject.SomeProperty

    но второе проще читать, оно как-то легче выглядит

    я и не говорил, что свойства отождествляют какую-то закрытую переменную - поле, оно может просто проверять время и выдавать результат, просто, обычно свойствами закрывают доступ к полям :)
    хотя, обычный метод так же может выполнить то же, что и свойство...

    короче говоря, свойства не могут существовать без правил доступа, т.е. Get/Set методов, а эти методы ни чем не отличаются от обычных, просто имеют свой синтаксис...

    кроме того, fedotxxl, Java ООП не отличается от LS ООП :)
    просто, Java абсолютно объектно-ориентированный язык, т.е. там все от начала и до конца инкапсулировано в классы,
    а LS (Pascal, VB) процедурно-основанные языки, с поддержкой ООП...
     
  11. Sch

    Sch Гость


    Cвойства в действительности имеют более полезные функции, чем приведенные не совсем верные абстракции вроде "соответствие объектному программированию".

    Например, в Delphi они позволяют создать процедуры, контролирующие собственно ввод-вывод в поля объекта.
    Кроме того, там они являются визуальными полями. То есть доступны в Объект-Инспекторе, в IDE, в отличие от просто run-time обычных полей.
     
  12. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    очень важно, особенно для LS и Notes ;)
    зы: никто не запрещал сделать доступными из IDE простые поля, просто борландовцы так себе решили :(
    свойства тоже run-time, мало того, объект который ты цепляешь на форму в delphi не какой-то, а самый что ни есть run-time объект ;)

    истина где-то там :) для того, чтобы это знать надо углубится в то как работает RTL, если мне память не изменяет (давно это было) но мало кто этим занимается, юзают многие, а как работает знают не многие...
     
  13. Sch

    Sch Гость

    published property.

    И определение методов ввода и вывода.

    Вот и вся Истина и все действия. Как я уже сказал, именно эти методы и придают смысл property.
     
  14. lionk

    lionk Well-Known Member

    Регистрация:
    5 апр 2007
    Сообщения:
    308
    Симпатии:
    3
    народ вы спорите на тему что лучше трамвай или тролейбус

    :( - тролейбус лучше, потомучто ездит по дороге а трамвай по рельсам
    ;) - но тролейбус ездит по проводам и у ниго такиеже степени свободы как и у тромвая
    ;) - берите машину она ездит где угодно
    :) - машина не общественный транспорт, так что же лучше тролейбус или трамвай
    :) - а если пустить трамвайные пути по среди дороги то трамвай будет как тролейбус?
     
  15. Sch

    Sch Гость

    зы: никто не запрещал сделать доступными из IDE простые поля, просто борландовцы так себе решили

    Поле, оформленное через методы ввода и вывода в него и объявленное не в public, а в published, и есть published property.

    Что касается public полей класса - то есть вещи которые просто не нужны в Design-Time

    Во всяком случае, вы спокойно можете создать класс, у которого все поля - published property. Если надо :>

    "свойства тоже run-time, мало того, объект который ты цепляешь на форму в delphi не какой-то"

    в Delphi все run-time. :> Включая Handle на win Api-объекты :(

    И все - design time. Только не все попадает в объект инспектор. Или экперты.

    Я как-то компонент написал, графический объект универсальный, который можно было редактировать прямо на Форме - тягая за узлы, как кривые в Сorele.
     
  16. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    lionk, чувак, ты не в теме :)
    мы не спорим, что лучше, вернее, я не вижу спора и доказательств на одну и другую сторону, просто обсуждается вопрос "зачем это, если есть то", вот и все ;)

    published работает только в каких-то persistent классах, просто обычные визуальные объекты наследуются от какого-то TComponent, а он уже все, что по-минимуму надо реализует... (извините, но точно не помню, да и хватит уже - есть форумы по delphi)
     
  17. Sch

    Sch Гость

    Да, конечно, он должен быть наследован от TComponent.
    и, конечно, тут форум по Лотусу.
     
  18. Sch

    Sch Гость

    Это фраза сама ничего не содержит. И абстрактна (в худшем смысле).

    Что это еще за "один вид возможности" ? Чем конкретно отличается ? Чем конкретно property отличается обычного public поля класса - если не тем, что я сказал ? :>

    А в Лотусе (хотя я его пока знаю и совсем слабо, но все же... :> ) - по моему "объектная модель" служит скорее рекламным лозунгом, чем реальным инструментом. :)

    Если вам так уж охота препирательства разводить...
     
  19. Sch

    Sch Гость

    Вы опять умудрились не сказать ничего конкретного - и по теме.

    Замнем для ясности. :>
     
  20. Sch

    Sch Гость

    Модератор: детский сад не тут. Пока устно.
     
Загрузка...

Поделиться этой страницей