C# vs Java: properties

[Ranger]

это ты еще то, что там заместо anonimous inner classes, не видел.

или видел?

[badger]

это ты еще то, что там заместо anonimous inner classes, не видел.

или видел?

Если Вы про случаи использования delegates там, где в Java можно только через anonymous inner classes, то видел конечно. Как раз delegates я не считаю плохой идеей. Не так удобно, конечно, как в функциональных языках, но ничего, жить можно. Это по сути те же объекты, только синтаксически замаскированные и упрощённые для удобства программиста.

Я уже писал, что в целом считаю дизайн C# очень даже неплохим. Это я только теперь, в этой теме, по прошествии некоторого времени, решил попридираться к некоторым его концепциям вроде properties и namespaces в сравнении с Java.

[Stanislav]

А что Вы инкапсуляцией называете тогда, можно уточнить? Я не применительно к С# которого не знаю, а вообще.

Надеюсь, понаопределяя private полей x и public методов а-ля getX()/setX(), единственная функция которых вернуть или присвоить значение x, Вы не рискнёте утверждать, что в подобном классе имела место инкапсуляция данных, представленных этим x. Её там и близко не будет, что видно уже исходя из самих названий методов.

Рискну - именно это и есть инкапсуляция. И такой способ обеспечивает сокрытие данных.

Инкапсуляция — это принцип, согласно которому любой класс должен рассматриваться как чёрный ящик — пользователь класса должен видеть и использовать только интерфейсную часть класса (т. е. список декларируемых свойств и методов класса) и не вникать в его внутреннюю реализацию. Поэтому данные принято инкапсулировать в классе таким образом, чтобы доступ к ним по чтению или записи осуществлялся не напрямую, а с помощью методов. Принцип инкапсуляции (теоретически) позволяет минимизировать число связей между классами и, соответственно, упростить независимую реализацию и модификацию классов.
Сокрытие данных — неотделимая часть ООП, управляющая областями видимости. Является логическим продолжением инкапсуляции. Целью сокрытия является невозможность для пользователя узнать или испортить внутреннее состояние объекта.

[aissp]

тише, у нас теоретег вещаить не спугни

[badger]

тише, у нас теоретег вещаить не спугни

Как же, вспугнёшь меня. Я практик, и более того, прагматик. Но на досуге люблю потеоретизировать. Особенно на любимые темы.

По делу есть чего сказать, или ты так, дурку повалять зашёл?

[Waterbyte]

тише, у нас теоретег вещаить не спугни

Как же, вспугнёшь меня. Я практик, и более того, прагматик. Но на досуге люблю потеоретизировать. Особенно на любимые темы.

По делу есть чего сказать, или ты так, дурку повалять зашёл?

я снова таки извиняюсь, шо встреваю в умный разговор, но мне [таки]*) кажеццо, шо "дурку повалять" - есть рулез, что бы там кто ни говорил. Даже еси нету чего сказать по делу.

*) скобочки - ибо перебор

пыс. нет, ты скажи: я не прав?

[badger]

Рискну - именно это и есть инкапсуляция. И такой способ обеспечивает сокрытие данных.

Инкапсуляция — это принцип, согласно которому любой класс должен рассматриваться как чёрный ящик — пользователь класса должен видеть и использовать только интерфейсную часть класса (т. е. список декларируемых свойств и методов класса) и не вникать в его внутреннюю реализацию.

В том и дело, что в данном случае инкапсуляция как таковая отсутствует. getX()/setX() напрямую следуют внутренней реализации класса. Они не оперируют ничем иным, как физическим обращением к полю x. Другими словами, здесь нет никакого скрытия внутренней структуры. Она проявлена через методы доступа, которые жёстко завязаны на эту структуру. И если понадобится изменить структуру, то придётся переделывать и все методы getX()/setX(). А это не инкапсуляция.

Хороший пример инкапсуляции -- наручные часы. Шестерёнки, пружинки -- внутренняя структура. Завод часов -- метод. Можно менять внутреннее устройство часов, совершенно не меняя метода завода.

Я, кстати, не утверждаю, что getX()/setX() конструкции вредны. Это бывает необходимо, но это не ООП.

[badger]

я снова таки извиняюсь, шо встреваю в умный разговор, но мне [таки]*) кажеццо, шо "дурку повалять" - есть рулез, что бы там кто ни говорил. Даже еси нету чего сказать по делу.

*) скобочки - ибо перебор

пыс. нет, ты скажи: я не прав?

Прав канешна. А я сам что делаю? Логинюсь, понимаешь, в Каморку и теоретизирую тут бесплатно. Тоже валяю дурку. Тока мы с aissp разную дурку валяем. Его беседа сводится только к тому, "жмут ему трусы или не жмут", и даже если жмут, то ему всё равно, так как "платят деньги", чтобы ходил в тех трусах.

А мне интересны детали: почему эти трусы жмут, а те не жмут. То есть, я не только мыслью о деньгах живу. Я не против, его право, но если он других взглядов, зачем здесь это высказывать? Мне был бы интересен ход его мыслей, а не его эмоции по данному вопросу.

[Waterbyte]

Ну не все же склонны к абстракциям и дедукциям. Вон, тот же aissp, к примеру, не видит связи между интервью на бухгалтерскую (ну или какую есчо, абсолютно неважно) позицию и на попадание в киношные "сферы", а я - ну так вижу, и что? Не спорить же мне с ним по этому поводу. Поделились мнениями-тире-эмоциями, каждый в силу своей собственной степени запущенности алекситимии - и поржали вместе. Плохо ли?

[badger]

Ну не все же склонны к абстракциям и дедукциям. Вон, тот же aissp, к примеру, не видит связи между интервью на бухгалтерскую (ну или какую есчо, абсолютно неважно) позицию и на попадание в киношные "сферы", а я - ну так вижу, и что? Не спорить же мне с ним по этому поводу. Поделились мнениями-тире-эмоциями, каждый в силу своей собственной степени запущенности алекситимии - и поржали вместе. Плохо ли?

Да конечно же нормально. Вот и я, в силу своей запущенности, ржу сижу. А он ржёт по-своему

[Stanislav]

Рискну - именно это и есть инкапсуляция. И такой способ обеспечивает сокрытие данных.

Инкапсуляция — это принцип, согласно которому любой класс должен рассматриваться как чёрный ящик — пользователь класса должен видеть и использовать только интерфейсную часть класса (т. е. список декларируемых свойств и методов класса) и не вникать в его внутреннюю реализацию.

В том и дело, что в данном случае инкапсуляция как таковая отсутствует. getX()/setX() напрямую следуют внутренней реализации класса. Они не оперируют ничем иным, как физическим обращением к полю x. Другими словами, здесь нет никакого скрытия внутренней структуры. Она проявлена через методы доступа, которые жёстко завязаны на эту структуру. И если понадобится изменить структуру, то придётся переделывать и все методы getX()/setX(). А это не инкапсуляция.

Хороший пример инкапсуляции -- наручные часы. Шестерёнки, пружинки -- внутренняя структура. Завод часов -- метод. Можно менять внутреннее устройство часов, совершенно не меняя метода завода.

Я, кстати, не утверждаю, что getX()/setX() конструкции вредны. Это бывает необходимо, но это не ООП.

Нет, это именно ООП - инкапсуляция ничего не говорит о том, как нужно бороться с изменением структуры - об этом говорит полиморфизм.
Кстати, сравните:
нарушение инкапсуляции:

Код: Выделить всё

паблик дабл синусУглаСтрельбы;

или сохранение

Код: Выделить всё

приват дабл синус;
приват булево этоВойна;
свойство синусУглаСтрельбы
   гет ( ...)
   сет (
       синус = значение;
       если  (синус > 4) тогда    
             если (этоВойна) тогда
                   синус = 4;
             иначе
                   синус = 1;
   )

вы это называете "только прямой доступ к переменной"?

Кстати, пример со швейцарскими часами крайне неудачен - на моих часах нет завода совсем Была изменено внутреннее устройство часов Можете проверить по инету характеристики, я не вру: часы Тиссо Баллада.

[badger]

Нет, это именно ООП - инкапсуляция ничего не говорит о том, как нужно бороться с изменением структуры - об этом говорит полиморфизм.

Неа, полиморфизм, это всего лишь насчёт взаимозаменяемости объектов с одинаковым интерфейсом.

Кстати, сравните:
нарушение инкапсуляции:
[skipped]
вы это называете "только прямой доступ к переменной"?

Стас, как раз это я не называю прямым доступом. Хитрый Вы. Вы-то привели пример с более-менне качественным скрытием внутренней структуры. Хотя, похоже, и там надо ещё поработать. Но уже между ним и типичными getX()/setX() есть разница. А я именно про getX()/setX(), единственная цель которых -- автоматизация доступа к полям, что не есть инкапсуляция.

Кстати, пример со швейцарскими часами крайне неудачен - на моих часах нет завода совсем Была изменено внутреннее устройство часов Можете проверить по инету характеристики, я не вру: часы Тиссо Баллада.

Да охотно верю, но всё же Вы знаете, что подавляющее число, скажем, механических часов имеют одинаковый метод завода при достаточно разнящемся внутреннем устройстве. Хорошо, будем считать пример неудачным.

[Stanislav]

Нет, это именно ООП - инкапсуляция ничего не говорит о том, как нужно бороться с изменением структуры - об этом говорит полиморфизм.

Неа, полиморфизм, это всего лишь насчёт взаимозаменяемости объектов с одинаковым интерфейсом.

Ой... ИМХО это как раз про изменение методов при изменении структуры, а вот интерфейс - одинаков.

Стас, как раз это я не называю прямым доступом. Хитрый Вы. Вы-то привели пример с более-менне качественным скрытием внутренней структуры. Хотя, похоже, и там надо ещё поработать. Но уже между ним и типичными getX()/setX() есть разница. А я именно про getX()/setX(), единственная цель которых -- автоматизация доступа к полям, что не есть инкапсуляция.

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

[badger]

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

Понятное дело. Мир не идеален. Но потеоретизировать иногда хочется