|
|
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
Начинайте бить. Только не больно. Надеюсь найдутся соратники. В чём полезность этих директив? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 19:00 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
в возможности контролировать действия над данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 19:14 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
SarinВ чём полезность этих директив? Примерно в том же, в чем полезность стен между комнатами, кухней, туалетом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 19:17 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
Инкапсуляция - очень хорошо! Но, во-первых, не кажется ли вам, что лучше было ограничится, например, предупреждениями компиляции, а не ошибками. И, во-вторых, не кажится ли вам, что, например, подход питона практичней и универсальней? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 20:28 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
SarinНачинайте бить. Только не больно. Надеюсь найдутся соратники. В чём полезность этих директив? Не-а, бить не будем - лень... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 20:46 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
предупреждения ничего не дадут.все бы плевали на них, и никакой инкапсуляции невышло б. а какой подход у питона? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 20:48 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
SarinНачинайте бить. Только не больно. Надеюсь найдутся соратники. В чём полезность этих директив? Чтобы никто не дергал те методы, которые я перефасую раз 10 по дороге к релизу и еще раз 50 после перформанс тестов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 20:55 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
latexа какой подход у питона? В питоне у объектов есть специальные имена методов. Такие методы вызываются когда с объектом пытаются что-то сделать. Например представить в виде строки. Или когда в объект пытаются напечатать. Или когда объект пытаются использовать в арифметических операциях. Когда его пытаются использовать в качестве списка. Очень много всяких методо штук 30. Так вот есть методы предназначенные на тот случай когда у объекта пытаются что-то сделать с его полями. Прочитать, выставить. Удалить. Пример: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 21:27 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
там лишний метод затесался:) __str__ Он как раз предназначен для "печати" объекта. Забыл удалить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 21:32 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
Слабо понятно, но по-моему с++ проще и логичней: обратился к закрытому полю - получил ошибку при компиляции ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 21:42 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
SarinНо, во-первых, не кажется ли вам, что лучше было ограничится, например, предупреждениями компиляции, а не ошибками. Нет, не кажется. Единственное, когда этот подход мог бы быть оправдан - для преодоления тупой файловой дружественности, реализованной в дельфе и в яве (может и еще где-нибудь). Но лично я полагаю, что лучше было бы убить саму дружественность. При этом такой подход не мог бы не привести к некоторым тонким моментам - например, реализовав новый метод в private части класса A, можно сломать его наследника, класс B, из-за возникшей перегрузки методов. SarinИ, во-вторых, не кажится ли вам, что, например, подход питона практичней и универсальней? Питона не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 22:26 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
SarinВ питоне у объектов есть специальные имена методов. Хм. Уже не нравится. Дай угадаю - это интерпретатор? Sarin def __setattr__(self, attname, attvalue): if attname == "private": raise AttributeError, "Try to acess to private value!" self.__dict__[attname] = attvalue Хм. То есть в нормальном случае получается длинный switch из реакций на разные имена свойств? Боюсь, я не очень понял, какое это имеет отношение к инкапсуляции. В любом случае, не отличается от Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. - итого, можно везде писать таким образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 22:41 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
облегчается сопровождение программы колегами и самим автором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2006, 23:09 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
softwarerХм. Уже не нравится. Дай угадаю - это интерпретатор? Да. Интерпретатор. Мне тоже долго не нравился такой подход. Коробило отсутствие private, public и protected. Но потом умные люди из рассылки по питону спросили у меня зачем они нужны. С тех пор я не знаю зачем они:) Подход питона к данному вопросу универсальней. Поясню на примере: допустим нам надо сделать так чтобы переменные a, b, c и d могли быть только целочисленные. f - только вещественного. Ну я конечно знаю, что для той-же явы - такого вопроса встать не может в принципе Но давайте теперь выпендримся. Введём ограничения на переменные. a от 0 до 100 b от -2 до 20 c от 100 до 300 d от -1 до 1 f от 0 до 1 Конечно это можно сделать легко на той-же яве. Ведь нас так призывают скрывать поля под привейтами. И я, лично, скрываю. Но вот код на питоне: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Например представте себе ситауацию, что в данном примерепридётся ввести ещё одну переменную с такими же ограничениями. Я добывлю строчку. А вы сколько?:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 00:05 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
начнем с того что изменять переменные класса на прямую как это делаете Вы по меньшей мере безграмотно... ну да ладно опустим мое (и не только мое) мнение насчет переменных класса и попробуем добавить в Ваш замечательный пример такую вот переменную номер дисконтной карты с проверкой на валидность ввода шаблон ХХХХ-1234-5678-0000 а я могу придумать объект из реальной жизни (в отличие от Вашего) у которого минимум 10 полей вот с такой вот "загогулиной" что мы получим? получим кусок кода который не поддается никакому пониманию раз и второе очень опасен в плане исправления старых и добавления новых полей (очень легко чего нить испортить в соседних ifах) в итоге получаем что удобнее писать под переменные несколько методов set, get, и т.д. НО если нет привата тогда очень велик соблазн особенно у "юных похрамистав" дернуть переменную напрямую (ладно переменную, а как получит доступ к служебному методу???) в обход всякой логике и тогда все старания на смарку, а как документировать если все это хозяйство???!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 01:23 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
В IDEA пишешь класс Код: plaintext 1. 2. 3. 4. 5. Если уж тебя так напрягает писать структуры-носители и устраивает питоновский перформанс, наследуешься от Hashtable и добавляешь туда рестрикшен сет в каком-нибудь виде. PS:Че-то я завяз в ночных халтурах... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 01:37 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
ставь везде и всегда public и будет все хорошо. в смысле не вижу большой нужды от приватов и протектед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 04:57 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
[quot vfabr шаблон ХХХХ-1234-5678-0000 [/quot] Вариант номер раз: создать специальный класс для этого типа. Можно, кстати, создать не класс, а метакласс. Но это уже чёрная магия. Ябы сделал проще: проверял бы эту переменную при попытке выставить её определённое значение при помощи регулярного выражения. vfabrв итоге получаем что удобнее писать под переменные несколько методов set, get, и т.д. НО если нет привата тогда очень велик соблазн особенно у "юных похрамистав" дернуть переменную напрямую (ладно переменную, а как получит доступ к служебному методу???) в обход всякой логике Дык пусть они ради бога и читают и выставляют поле. А класс отлавливает эти попытке. Тут нет нарушения инкапсуляции! Сергей ИльичВ IDEA пишешь класс Ну дык это уже IDE даёт:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 08:57 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
авторВариант номер раз: создать специальный класс для этого типа. Можно, кстати, создать не класс, а метакласс. Но это уже чёрная магия. Ябы сделал проще: проверял бы эту переменную при попытке выставить её определённое значение при помощи регулярного выражения. это не совпадает с этим заявлением авторНапример представте себе ситауацию, что в данном примерепридётся ввести ещё одну переменную с такими же ограничениями. Я добывлю строчку. А вы сколько?:) получается что никакого выигрыша нет??! авторДык пусть они ради бога и читают и выставляют поле. А класс отлавливает эти попытке. Тут нет нарушения инкапсуляции! может словари тоже дураки пишут? авторИнкапсуляция - в объектно-ориентированном программировании - сокрытие внутренней структуры данных и реализации методов объекта от остальной программы. Другим объектам доступен только интерфейс объекта, через который осуществляется все взаимодействие с ним. лат.In - в + Capsula - ящичек вот тут на помощь и приходит приват но Вам то он не нужен так что настаивать не буду не используйте его, но и не песдите в воздух о вещах о которых имеете весьма смутное представление ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 10:28 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
Sarin Сергей ИльичВ IDEA пишешь класс Ну дык это уже IDE даёт:) И это весь твой ответ? А по существу - ты сравниваешь язык, в котором все переменные - это варианты, которые могут содержать либо атом либо хеш из вариантов, с языком со статической типизацией. Хочешь питоновские объекты - расширяй класс Hashtable. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 12:31 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
ДА! (в след за Бертраном Мейером): не нужны нам private public protected. Нужны "visible for Class1, Сlass2, Class3" делающих компонент доступным для всех наследников Class1,2,3 (включив в множество классов классы ANY и NONE). Но это уже Eiffel и ещё большее количество проверок в компил тайм, которых так не любят приверженцы динамических языков программирования. Если ставить полезность p-p-p под сомнение, то начать нужно с постановки под сомнение полезности ОО метода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 14:17 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
вот начитаются такого бреда смешного и думают что самые умные :-))) http://www.computer-science.ru/docs/comp/rus/develop/other/stroustrup_interview/ ---------------------------------------- жизнь как пестня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 14:28 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
Ну, парни, наверное автор не подумал о том, что часто проект - коллективная разработка и имена переменных внутри объектов - личное дело разработчика. И вот тут (здесь) и требуются определения видимости (доступности). А ежели один - на один... То и зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 14:37 |
|
||
|
Ставлю под сомнение полезность private, public и protected
|
|||
|---|---|---|---|
|
#18+
Fabrichenko Viktorвот начитаются такого бреда смешного и думают что самые умные :-))) Это фейк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2006, 15:09 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=33669894&tid=1345367]: |
0ms |
get settings: |
5ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 335ms |

| 0 / 0 |
