-
🔥 Бесплатный курс от Академии Кодебай: «Анализ защищенности веб-приложений»
🛡 Научитесь находить и использовать уязвимости веб-приложений.
🧠 Изучите SQLi, XSS, CSRF, IDOR и другие типовые атаки на практике.
🧪 Погрузитесь в реальные лаборатории и взломайте свой первый сайт!
🚀 Подходит новичкам — никаких сложных предварительных знаний не требуется.Доступ открыт прямо сейчас — Записаться бесплатно
проперти - свойство по сути та же функция, т.е. есть заголовок и входные параметры, тело и возвращаемы результат. Свойство - это дань объектно- ориентированому программированию...... Т.е это способ описывать поведение отдельных объектов.
Другими словами, Ваш вопрос можно переформулировать следующим образом: А зачем вообще нужно объектно ориентированное программирование? ....
Попытайтесь сами ответить на этот вопрос.
Другими словами, Ваш вопрос можно переформулировать следующим образом: А зачем вообще нужно объектно ориентированное программирование? ....
Попытайтесь сами ответить на этот вопрос.
Duedev
Прости, разве в Java есть проперти? Насколько я знаю, нет. И чувствуют себя получше чем LS в плане ООП
Прости, разве в Java есть проперти? Насколько я знаю, нет. И чувствуют себя получше чем LS в плане ООП
Constantin A Chervonenko
Green Team
- 30.05.2006
- 1 345
- 12
"90% мужчин, умерших до 60 лет ели огурцы. Вывод: огурцы смертельно опасны"(с)
В Java ООП лучше, чем в LS; в JAVA нет property. Вывод: property вредны для ООП.
В LS нет виртуальных методов, нет производных классов от всех NotesXXX- классов.. etc. Вот где недостатки LS, а не в наличии пропертей
fedotxxl
Property служит для упрощения интерфейса. Вместо пары getter/setter Вы можете использовать property.
Пример. Есть класс, описывающий точку на плоскости. Точка имеет координаты. Интерфейс при отсутсвии свойств (Java, к примеру):
getX(), getY(), setX(x), setY
, 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", но это скрывает от нас компилятор.) И если нужно, то писать классы-обертки.
Property служит для упрощения интерфейса. Вместо пары getter/setter Вы можете использовать property.
Пример. Есть класс, описывающий точку на плоскости. Точка имеет координаты. Интерфейс при отсутсвии свойств (Java, к примеру):
getX(), getY(), setX(x), setY
, 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", но это скрывает от нас компилятор.) И если нужно, то писать классы-обертки.
Constantin A Chervonenko
Green Team
- 30.05.2006
- 1 345
- 12
Ну, терминологию я уже забыл :blink:
Необходимость-же писания классов-оберток полностью девальвирует всяку ООП-шность стандартных "классов", которые только синтаксис имеют ООП-подобный, но не имеют тех свойств-признаков ООП (наследование, полиморфизм .. что там еще было? Инкапсуляция вроде как есть)
Constantin A Chervonenko, что-то Вы путаете 
LS абсолютно поддерживает стандарты ООП, кроме возможности наследования от "стандартных" классов, причина была указана выше - "стандартные" классы внешние по отношению к "нашему" коду...
А обсуждать ООП свойства внешних классов уже нет смысла, хотя, и наследование и полиморфизм там есть, но разнообразие классов не показывает их явно, но об одном наследовании, как минимум, упоминается в справке - "NotesRichTextItem inherits from NotesItem class".
Еще есть классы по работе с XML, но они реже используются и не являются "стандартными" LS-классами в общем смысле, но тоже имеют дерево классов...
LS, являясь надмножеством языка Basic, является объектно-основанным языком программирования и расширен до объектно-ориентированного, т.е. расширяет язык возможностью создания собственных (user defined) классов.
О перегрузке методов вообще отдельный разговор, на сколько мне помнится, то перегрузка не входит в парадигмы ООП, так же как и свойства, а является лишь расширением компилятора и линкера, хотя, я мог и отстать от теории
Свойства как расширение классов придают не более чем удобо-читаемый интерфейс, для программистов, использующих классы, которые эти свойства и описывают/реализуют...
Т.е. программист может использовать традиционно Set/Get методы, а может описать правила доступа к полям класса, которые реализовываются с помощью тех же методов, но имеющих другой синтаксис, позволяющий использовать в качестве вызова лишь одно имя и для записи и для считывания, т.е. это некоторая перегрузка вызова метода: в случае если используется конструкция считывания поля, происходит вызов Get метода, иначе Set...
Я считаю, что свойства всего лишь для удобства, хотя явно описанные методы доступа позволяют создавать более строгие конструкции кода, в которых явно видно чтение и установка значения поля...
LS абсолютно поддерживает стандарты ООП, кроме возможности наследования от "стандартных" классов, причина была указана выше - "стандартные" классы внешние по отношению к "нашему" коду...
А обсуждать ООП свойства внешних классов уже нет смысла, хотя, и наследование и полиморфизм там есть, но разнообразие классов не показывает их явно, но об одном наследовании, как минимум, упоминается в справке - "NotesRichTextItem inherits from NotesItem class".
Еще есть классы по работе с XML, но они реже используются и не являются "стандартными" LS-классами в общем смысле, но тоже имеют дерево классов...
LS, являясь надмножеством языка Basic, является объектно-основанным языком программирования и расширен до объектно-ориентированного, т.е. расширяет язык возможностью создания собственных (user defined) классов.
О перегрузке методов вообще отдельный разговор, на сколько мне помнится, то перегрузка не входит в парадигмы ООП, так же как и свойства, а является лишь расширением компилятора и линкера, хотя, я мог и отстать от теории
Свойства как расширение классов придают не более чем удобо-читаемый интерфейс, для программистов, использующих классы, которые эти свойства и описывают/реализуют...
Т.е. программист может использовать традиционно Set/Get методы, а может описать правила доступа к полям класса, которые реализовываются с помощью тех же методов, но имеющих другой синтаксис, позволяющий использовать в качестве вызова лишь одно имя и для записи и для считывания, т.е. это некоторая перегрузка вызова метода: в случае если используется конструкция считывания поля, происходит вызов Get метода, иначе Set...
Я считаю, что свойства всего лишь для удобства, хотя явно описанные методы доступа позволяют создавать более строгие конструкции кода, в которых явно видно чтение и установка значения поля...
sax_ol, ты меня не правильно понял, либо я не корректно написал
имелось в виду, что использование обычных методов вместо свойств явно описывают действие, т.е.:
call someObject.SetSomeProperty(SomeValue)
someValue = someObject.GetSomeProperty()
выглядит строже чем
someObject.SomeProperty = SomeValue
SomeValue = someObject.SomeProperty
но второе проще читать, оно как-то легче выглядит
я и не говорил, что свойства отождествляют какую-то закрытую переменную - поле, оно может просто проверять время и выдавать результат, просто, обычно свойствами закрывают доступ к полям
хотя, обычный метод так же может выполнить то же, что и свойство...
короче говоря, свойства не могут существовать без правил доступа, т.е. Get/Set методов, а эти методы ни чем не отличаются от обычных, просто имеют свой синтаксис...
кроме того, fedotxxl, Java ООП не отличается от LS ООП
просто, Java абсолютно объектно-ориентированный язык, т.е. там все от начала и до конца инкапсулировано в классы,
а LS (Pascal, VB) процедурно-основанные языки, с поддержкой ООП...
имелось в виду, что использование обычных методов вместо свойств явно описывают действие, т.е.:
call someObject.SetSomeProperty(SomeValue)
someValue = someObject.GetSomeProperty()
выглядит строже чем
someObject.SomeProperty = SomeValue
SomeValue = someObject.SomeProperty
но второе проще читать, оно как-то легче выглядит
я и не говорил, что свойства отождествляют какую-то закрытую переменную - поле, оно может просто проверять время и выдавать результат, просто, обычно свойствами закрывают доступ к полям
хотя, обычный метод так же может выполнить то же, что и свойство...
короче говоря, свойства не могут существовать без правил доступа, т.е. Get/Set методов, а эти методы ни чем не отличаются от обычных, просто имеют свой синтаксис...
кроме того, fedotxxl, Java ООП не отличается от LS ООП
просто, Java абсолютно объектно-ориентированный язык, т.е. там все от начала и до конца инкапсулировано в классы,
а LS (Pascal, VB) процедурно-основанные языки, с поддержкой ООП...
Cвойства в действительности имеют более полезные функции, чем приведенные не совсем верные абстракции вроде "соответствие объектному программированию".
Например, в Delphi они позволяют создать процедуры, контролирующие собственно ввод-вывод в поля объекта.
Кроме того, там они являются визуальными полями. То есть доступны в Объект-Инспекторе, в IDE, в отличие от просто run-time обычных полей.
очень важно, особенно для LS и Notes
зы: никто не запрещал сделать доступными из IDE простые поля, просто борландовцы так себе решили
свойства тоже run-time, мало того, объект который ты цепляешь на форму в delphi не какой-то, а самый что ни есть run-time объект
истина где-то тамPS: сори за офтоп, но истина дороже.
для того, чтобы это знать надо углубится в то как работает RTL, если мне память не изменяет (давно это было) но мало кто этим занимается, юзают многие, а как работает знают не многие...published property.
И определение методов ввода и вывода.
Вот и вся Истина и все действия. Как я уже сказал, именно эти методы и придают смысл property.
И определение методов ввода и вывода.
Вот и вся Истина и все действия. Как я уже сказал, именно эти методы и придают смысл property.
народ вы спорите на тему что лучше трамвай или тролейбус
- тролейбус лучше, потомучто ездит по дороге а трамвай по рельсам
- но тролейбус ездит по проводам и у ниго такиеже степени свободы как и у тромвая
- берите машину она ездит где угодно
- машина не общественный транспорт, так что же лучше тролейбус или трамвай
- а если пустить трамвайные пути по среди дороги то трамвай будет как тролейбус?
- тролейбус лучше, потомучто ездит по дороге а трамвай по рельсам - но тролейбус ездит по проводам и у ниго такиеже степени свободы как и у тромвая - берите машину она ездит где угодно - машина не общественный транспорт, так что же лучше тролейбус или трамвай - а если пустить трамвайные пути по среди дороги то трамвай будет как тролейбус?зы: никто не запрещал сделать доступными из IDE простые поля, просто борландовцы так себе решили
Поле, оформленное через методы ввода и вывода в него и объявленное не в public, а в published, и есть published property.
Что касается public полей класса - то есть вещи которые просто не нужны в Design-Time
Во всяком случае, вы спокойно можете создать класс, у которого все поля - published property. Если надо :>
"свойства тоже run-time, мало того, объект который ты цепляешь на форму в delphi не какой-то"
в Delphi все run-time. :> Включая Handle на win Api-объекты
И все - design time. Только не все попадает в объект инспектор. Или экперты.
Я как-то компонент написал, графический объект универсальный, который можно было редактировать прямо на Форме - тягая за узлы, как кривые в Сorele.
Поле, оформленное через методы ввода и вывода в него и объявленное не в public, а в published, и есть published property.
Что касается public полей класса - то есть вещи которые просто не нужны в Design-Time
Во всяком случае, вы спокойно можете создать класс, у которого все поля - published property. Если надо :>
"свойства тоже run-time, мало того, объект который ты цепляешь на форму в delphi не какой-то"
в Delphi все run-time. :> Включая Handle на win Api-объекты
И все - design time. Только не все попадает в объект инспектор. Или экперты.
Я как-то компонент написал, графический объект универсальный, который можно было редактировать прямо на Форме - тягая за узлы, как кривые в Сorele.
lionk, чувак, ты не в теме
мы не спорим, что лучше, вернее, я не вижу спора и доказательств на одну и другую сторону, просто обсуждается вопрос "зачем это, если есть то", вот и все
published работает только в каких-то persistent классах, просто обычные визуальные объекты наследуются от какого-то TComponent, а он уже все, что по-минимуму надо реализует... (извините, но точно не помню, да и хватит уже - есть форумы по delphi)
мы не спорим, что лучше, вернее, я не вижу спора и доказательств на одну и другую сторону, просто обсуждается вопрос "зачем это, если есть то", вот и все
published работает только в каких-то persistent классах, просто обычные визуальные объекты наследуются от какого-то TComponent, а он уже все, что по-минимуму надо реализует... (извините, но точно не помню, да и хватит уже - есть форумы по delphi)
Это фраза сама ничего не содержит. И абстрактна (в худшем смысле).
Что это еще за "один вид возможности" ? Чем конкретно отличается ? Чем конкретно property отличается обычного public поля класса - если не тем, что я сказал ? :>
А в Лотусе (хотя я его пока знаю и совсем слабо, но все же... :> ) - по моему "объектная модель" служит скорее рекламным лозунгом, чем реальным инструментом.
Если вам так уж охота препирательства разводить...
Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab
Похожие темы
- Статья
