|
Модераторы: LSD |
|
Pawl |
|
||||||||||
Опытный Профиль Группа: Участник Сообщений: 649 Регистрация: 22.4.2008 Где: Витебск Репутация: нет Всего: 28 |
Каждый маленький программист, можно сказать, с молоком матери впитывает идею постоянного сокрытия данных, и, если в методах класса с модификатором public ему приходится мириться, то вот поля обязательно должны быть private или уж на крайняк protected! Со временем это переходит в ритуал, благодаря которому для простого доступа или изменения полей класса надо писать еще дополнительный код стандартных геттеров/сеттеров. Веселуха начинается при написании какого-либо java-класса PODJO типа сущностей для доступа к таблицам в БД с десятком-другим полей в каждой, или action'ов из фрэймворка Struts2. Тогда программа обрастает прям километрами кода. Честно, не понимаю, зачем для простого получения/изменения значения поля обязательно нужны некие костыли? Допускаю необходимость инкапсуляции - в разумных пределах, но писать код типа
и потом обращаться к х и у через point.getX() / point.setX(х) считаю явным излишеством. В этом случае гораздо проще использовать для полей модификатор public и обращаться к ним напрямую:
В С#, на сколько я знаю, для этого есть сахарные костыли, называемые свойствами, которые имитируют прямой доступ к переменной: point.х = х. Для этого класс Point надо оформить так:
Данный код выглядит значительно короче, чем в java, но по поведению также практически ничем не отличается от кода
Видимо, java-сообщество просекло фишку и создало библиотеку lombok, с помощью которой можно сократить код до
Имхо, все эти телодвижения происходят из-за проблемы, которую сами себе и создали. А насколько было бы проще жить, если не возводить инкапсуляцию данных в священную догму! -------------------- В действительности всё совсем не так, как на самом деле |
||||||||||
|
|||||||||||
Guinness |
|
||||
Опытный Профиль Группа: Участник Сообщений: 310 Регистрация: 21.6.2009 Где: Зеленоград Репутация: нет Всего: 10 |
А что если потом придётся делать некие проверки при установке или передаче этих значений? Весь код, который использует данные переменные придётся переписывать.
Имхо, нихрена это не костыли. Для меня это очень большой плюс в сравнении с плюсами, к примеру, на которых я пишу большую часть кода. |
||||
|
|||||
Alexeis |
|
|||
Амеба Профиль Группа: Админ Сообщений: 11743 Регистрация: 12.10.2005 Где: Зеленоград Репутация: 14 Всего: 459 |
А я не парюсь при использовании тривиальных полей, пихаю их в паблик и пошло оно все лесом. На крайняк всегда есть рефракторниг и ctr+shift+f .
-------------------- Vit вечная память. Обсуждение действий администрации форума производятся только в этом форуме гениальность идеи состоит в том, что ее невозможно придумать |
|||
|
||||
Pawl |
|
|||
Опытный Профиль Группа: Участник Сообщений: 649 Регистрация: 22.4.2008 Где: Витебск Репутация: нет Всего: 28 |
И в чём же плюс? -------------------- В действительности всё совсем не так, как на самом деле |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15711 Регистрация: 24.3.2004 Где: Dublin Репутация: 9 Всего: 537 |
Возможность быстро создать пропертю, в которую потом при необходимости легко добавить, без рефакторинга и перекомпиляции, нужные проверки. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
Pawl |
|
||||
Опытный Профиль Группа: Участник Сообщений: 649 Регистрация: 22.4.2008 Где: Витебск Репутация: нет Всего: 28 |
Согласен, это плюс. Но, к примеру, в классах-сущностях проверки можно осуществлять и при помощи аннотаций к полям:
-------------------- В действительности всё совсем не так, как на самом деле |
||||
|
|||||
diadiavova |
|
|||
Доктор Зло(диагност, настоящий, с лицензией и полномочиями) Профиль Группа: Модератор Сообщений: 5820 Регистрация: 14.8.2008 Где: В Коньфпольте Репутация: 4 Всего: 142 |
Pawl, а чем не устраивает то объяснение, которое дается в любом пособии для начинающего программиста? По мере развития проекта может возникнуть ряд ситуаций, как то:
1. При тестировании может выяснится, что некоторые значения переданные полю, приводят к некорректной работе класса. В данном случае может возникнуть необходимость либо корректировать налету полученное значение либо отклонять изменение значения. 2. Существует вероятность того, что в процессе развития проекта может возникнуть необходимость уведомлять заинтересованные стороны о том, что значение поля изменилось, либо кто-то пытается его изменить. 3. Для оптимизации работы класса может понадобиться, к примеру, ленивая инициализация значения (то есть объект создается при первом обращении к свойству, в противном случае не создается вообще). Во всех этих случаях прямое обращение к полю может привести к необходимости переписывать туеву хучу кода. Не имитируют. То, что ты привел - это т.н. автоматически реализуемое свойство. Его объявление мало чем отличается от объявления поля, но фактически компилятор создает обычные акцессоры свойства со стандартным кодом. Для них всегда можно описать реализацию вручную с тем же успехом. Надо сказать, что автоматическая реализация - сама по себе очень крутая штука и сильно сокращает количество кода. Но, в то же время, даже когда ее не было (в шарпе она появилась в 2005-м, а в бейсике в 2008-м), свойства все равно отчасти решали описанную тобой проблему. Дело в том, что в языках, где есть свойства, инкапсуляция доступа к полям в принципе не так критична. Несмотря на то, что во всех учебниках пишут о том, что публичные поля - зло, тем не мене, в языках со свойствами поле почти всегда можно совершенно безболезненно заменить свойством, если такая необходимость возникла(есть пара случаев исключения, но в основном они не критичны).
А если ты пишешь библиотеку, которую используют десятки других разработчиков, которые обращаются к полю класса в сотне различных мест, а потом всякий раз, когда оказалось, что поле надо заменить методами, будешь предлагать и им тоже все это дело рефакторить? А если все так начнут делать? -------------------- Хочешь получить мудрый совет - читай подписи участников форумов. Злой доктор Щасзаболит |
|||
|
||||
Pawl |
|
||||
Опытный Профиль Группа: Участник Сообщений: 649 Регистрация: 22.4.2008 Где: Витебск Репутация: нет Всего: 28 |
Ну так вы, можно сказать, сами и ответили на свой вопрос: Т. е. Можно написать так:
и при необходимости заменить поля свойствами с необходимыми проверками. При этом доступ из других классов как был point.х, так и останется point.х, т. е. их модифицировать не понадобится. Это сообщение отредактировал(а) Pawl - 30.5.2014, 11:18 -------------------- В действительности всё совсем не так, как на самом деле |
||||
|
|||||
diadiavova |
|
|||
Доктор Зло(диагност, настоящий, с лицензией и полномочиями) Профиль Группа: Модератор Сообщений: 5820 Регистрация: 14.8.2008 Где: В Коньфпольте Репутация: 4 Всего: 142 |
Я не задавал вопросов, а попытался ответить на твой. Ну так на C# можно. Это не будет работать при обращении к свойствам через рефлексию, а так же, если код вызывается из проекта написанного на языке, в котором нет свойств. Например был в семействе дотнет-языков такой язык как J# (на заре развития технологии с его помощью пытались привлечь ява-программистов). В нем свойств нет, и обращаться приходится к методам-акцессорам непосредственно. Но такие языки мало распространены, так что большой проблемы в этом нет. А так вообще да, свойства в принципе для этого и существуют. Когда я интересовался явой, то одной из причин, по которой я оставил эти попытки было именно отсутствие свойств, поскольку к хорошему быстро привыкаешь. -------------------- Хочешь получить мудрый совет - читай подписи участников форумов. Злой доктор Щасзаболит |
|||
|
||||
Pawl |
|
|||
Опытный Профиль Группа: Участник Сообщений: 649 Регистрация: 22.4.2008 Где: Витебск Репутация: нет Всего: 28 |
Думаю теперь, когда Оракл обязался выпускать по новой версии java не реже, чем раз в 2 года, свойства в ней тоже появятся и причины для принудительной инкапсуляции со временем исчезнут - с учетом того, что свойства во многих языках программирования уже реализованы, а в с++ тоже могут появиться. По крайней мере, потребность в них есть, т. к. люди извращаются, чтобы реализовать их самостоятельно. -------------------- В действительности всё совсем не так, как на самом деле |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15711 Регистрация: 24.3.2004 Где: Dublin Репутация: 9 Всего: 537 |
Перекомпиляция все же потребуется.
Метода акцессоры можно мокать, а вот доступ к полям фиг замокаешь. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
Alexeis |
|
|||
Амеба Профиль Группа: Админ Сообщений: 11743 Регистрация: 12.10.2005 Где: Зеленоград Репутация: 14 Всего: 459 |
Pawl привел тривиальный случай и я, собственно, в этом контексте комментировал. То что ты описал никак нельзя назвать тривиальным случаем. Это только быдло кодеры пишут класс и не представляют себе как его потом будут использовать. При конструировании программы от простого к сложному заранее понятно, что точка это пассивный объект из 2-3 полей и из нее никто не будет строить в последствии объект с виртуальными функциями и т.д. В С++ есть даже такое понятие как POD тип Plain Old Data, т.е. тип, который устроен так как описан. На самом деле, очень здорово, когда простые вещи устроены простым образом, это делает код прозрачным. Программист, который читает такой код не вынужден каждый раз обращаться в реализации функции GetX чтобы убедиться в том, что ее реализация тривиальна. Экономиться куча времени на чтении и куча времени на компиляции. -------------------- Vit вечная память. Обсуждение действий администрации форума производятся только в этом форуме гениальность идеи состоит в том, что ее невозможно придумать |
|||
|
||||
diadiavova |
|
||||||
Доктор Зло(диагност, настоящий, с лицензией и полномочиями) Профиль Группа: Модератор Сообщений: 5820 Регистрация: 14.8.2008 Где: В Коньфпольте Репутация: 4 Всего: 142 |
Автоматически реализуемые свойства вообще никаких проблем с разрастанием кода не создают, так что лучше уж их использовать, если они есть. Да и не факт, что свойства появятся. Насколько мне известно, Сан не добавлял новые фичи в язык потому, что считали все это веяниями моды и не хотели засорять ими язык. Что будет делать Оракл - неизвестно, хотя, вроде кое-что уже сделал полезное(лямбды замыкания и прочее).
Даже в яваскрипте есть уже Да. Но она обычно и так выполняется время от времени. Хотя согласен, что лучше такими заменами не злоупотреблять.
Он вроде там приводил пример с сущностями для доступа к объектам датабазы. Ну так такие классы обычно генерируются автоматически, а писать их руками - чистой воды извращение
Я не об этом написал. Я написал о том, что код, который пишешь ты, возможно будут использовать другие разработчики и просить их каждый раз, чтобы они рефакторили свой код из-за того, что ты поленился описать акцессоры можно до поры до времени, но если делать это постоянно, то тебе могут устроить "тёмную" Но ты ведь в данном случае написал, что таки возникают проблемы с этим и порой приходится рефакторить. Так что простота не гарантирует отсутствия проблем в будущем. А вообще, при наличии нормальных инструментов, тривиальный код генерируется автоматически. Думаю, что для любой ява-иде такие инструменты, которые ну по крайней мере код акцессоров генерят, найти вполне можно. Поэтому проблемы в этом не вижу. -------------------- Хочешь получить мудрый совет - читай подписи участников форумов. Злой доктор Щасзаболит |
||||||
|
|||||||
Alexeis |
|
|||
Амеба Профиль Группа: Админ Сообщений: 11743 Регистрация: 12.10.2005 Где: Зеленоград Репутация: 14 Всего: 459 |
Простые классы просто рефракторятся, но этого как правило и не требуется. Тебе наверное редко приходиться читать чужой код без комментов. Иногда берешь чужую прогу и хочется убить автора. Там где можно написать решение в 100 строк, обнаруживаешь 1500 вот таких вот пустых строк и вдобавок непонятные иерархии, наследования виртуальные функции и т.д. Раздувают общее решение для узкой задачи. Программист не должен быть заложником ООП. ООП нужен там где он нужен, а там где не нужен, то нужно писать простой компактный читабельный код, который не нуждается в документировании и даже комментариях. У меня нет проблем со скоростью печати. Пока обдумываешь решение хватает времени не то что гетеры с сетерами налепить руками, а еще сделать выравнивания, отступы пробелы и прочий марафет облегчающий восприятие кода. Нетривиальный код, который будут читать другие люди, вообще желательно строить на абстрактных классах, чтобы человек видел только то что ему может понадобиться. Но в этой теме поднят вопрос целесообразности применения ООП в тривиальных ситуациях. Я поддерживаю автора. Фтопку ООП когда оно не нужно. -------------------- Vit вечная память. Обсуждение действий администрации форума производятся только в этом форуме гениальность идеи состоит в том, что ее невозможно придумать |
|||
|
||||
diadiavova |
|
||||
Доктор Зло(диагност, настоящий, с лицензией и полномочиями) Профиль Группа: Модератор Сообщений: 5820 Регистрация: 14.8.2008 Где: В Коньфпольте Репутация: 4 Всего: 142 |
Да, но как я уже написал, делать это, возможно, придется не только тебе одному. А если все будут поступать так же, то работенки прибавится всем и немало. Я тут вообще ни при чем. В случае со мной публичное поле объявляется так
Согласен полностью, только не знаю, при чем тут ООП. Обеспечивать доступ к данным из одного места программистов научила практика. Для случаев, когда можно быть уверенным, что никакое изменение порядка доступа к полю не потребуется, я ничего против паблик-полей не имею. Мало того, в литературе мне встречалось утверждение, что, например, в структурах паблик-поля - вообще обычное дело. В принципе догматизм - это всегда плохо, всегда надо не только знать как что сделать, но и понимать почему. Тем не менее иметь в виду возможное(но не очевидное в данный момент) изменение условий - совсем не лишняя предосторожность ибо ситуации такие не редки. А у меня есть, да и отступы руками делать не привык, поскольку иде с этим прекрасно справляется. И вообще, чем меньше кнопок приходится жать - тем лучше Я писал о коде, который используют другие. Вот ты при необходимости взял да и заменил публичное поле акцессорами. Отрефакторил все те места, где ты к этому полю обращался и вроде все нормально. Только проблема в том, что если и у других разработчиков имеется код, где они обращались к этому же полю, то и им придется в каждой такой ситуации делать то же самое. Я говорил только об этом и тут не имеет ровны счетом никакого значения степень тривиальности кода. А если каждый начнет делать так же как и ты, то это может обратиться в серьезную проблему. -------------------- Хочешь получить мудрый совет - читай подписи участников форумов. Злой доктор Щасзаболит |
||||
|
|||||
Правила ведения Религиозных войн | |
|
1. Уважайте собеседника 2. Собеседник != враг 3. Старайтесь воздерживаться от тем вида "Windows Rulez" или "Linux Rulez" С уважением, Smartov. |
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Религиозные войны | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |