• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Property Vs Function?

  • Автор темы fedotxxl
  • Дата начала
F

fedotxxl

Зачем нужен property, когда можно возвращать ответ через функцию?
 
D

Duedev

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

fedotxxl

Duedev
Прости, разве в Java есть проперти? Насколько я знаю, нет. И чувствуют себя получше чем LS в плане ООП
 
30.05.2006
1 345
12
BIT
0
Duedev
Прости, разве в Java есть проперти? Насколько я знаю, нет. И чувствуют себя получше чем LS в плане ООП
"90% мужчин, умерших до 60 лет ели огурцы. Вывод: огурцы смертельно опасны"(с)
В Java ООП лучше, чем в LS; в JAVA нет property. Вывод: property вредны для ООП.

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

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", но это скрывает от нас компилятор.) И если нужно, то писать классы-обертки.
 
K

Kee_Keekkenen

сеты и геты используются для обращения только к приватным полям (переменным) классов..
 
30.05.2006
1 345
12
BIT
0
В LS есть виртуальные методы. ... Другое дело, что нет возможности перегрузить (overload) один метод другим методом с этим же именем, но с другой сигнатурой.
А все NotesXXX классы нужно воспринимать как внешние. И если нужно, то писать классы-обертки.
Ну, терминологию я уже забыл :blink:
Необходимость-же писания классов-оберток полностью девальвирует всяку ООП-шность стандартных "классов", которые только синтаксис имеют ООП-подобный, но не имеют тех свойств-признаков ООП (наследование, полиморфизм .. что там еще было? Инкапсуляция вроде как есть)
 
K

Kee_Keekkenen

это последнее в скрипте и осталось от ООП
 
A

Akupaka

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

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

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

Akupaka

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

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

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

someObject.SomeProperty = SomeValue
SomeValue = someObject.SomeProperty

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

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

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

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

Sch

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


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

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

Akupaka

Кроме того, там они являются визуальными полями. То есть доступны в Объект-Инспекторе, в IDE, в отличие от просто run-time обычных полей.
очень важно, особенно для LS и Notes ;)
зы: никто не запрещал сделать доступными из IDE простые поля, просто борландовцы так себе решили :(
свойства тоже run-time, мало того, объект который ты цепляешь на форму в delphi не какой-то, а самый что ни есть run-time объект ;)

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

Sch

published property.

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

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

lionk

народ вы спорите на тему что лучше трамвай или тролейбус

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

Sch

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

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

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

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

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

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

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

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

Akupaka

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

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

Sch

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

Sch

"Свойства это всего-лишь еше один вид возможности реализации инкапсуляции в ООП. абстракция ..."

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

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

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

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

Sch

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

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

Sch

Модератор: детский сад не тут. Пока устно.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!