|
Курс:"Hello World или изучаем : Java. Синтаксис.Ч.2."
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 13:56 | Сообщение # 81 |
старожил
Сейчас нет на сайте
| ArromanFox, имеется ввиду что при передачи механизма третьим лицам, не подкованным в программировании данные которые им заведомо не нужны или тупо их изменение приведет к непридвиденным событиям заносят в private, например. Мы передаем коробку третьим лицам, а ее высоту, ширину, длину мы хотим скрыть значит пишем. private int height;
кактотак.
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
Сообщение отредактировал Alfe - Пятница, 12 Февраля 2016, 13:58 |
|
|
| |
| ArromanFox | Дата: Пятница, 12 Февраля 2016, 14:02 | Сообщение # 82 |
почетный гость
Сейчас нет на сайте
| Alfe, это то понятно, но речь шла о соответствии парадигме (т.е. хоть с третьими лицами, хоть без них).
Наблюдатель
|
|
|
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 14:06 | Сообщение # 83 |
|
старожил
Сейчас нет на сайте
| ArromanFox, вечером отвечу. Я с телефа. А расписывать долго.
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
|
|
|
| |
| Lapish | Дата: Пятница, 12 Февраля 2016, 20:16 | Сообщение # 84 |
частый гость
Сейчас нет на сайте
| Цитата ArromanFox (  ) Из этих слов получается, что всю логику желательно скрывать, притом максимально. Разве это не усложнит разработку?
Верно. Да, в самом начале разработка будет несколько сложнее, но в будущем она многократно себя окупит.
Парадигмы, паттерны и.т.п придумывали далеко не глупые люди. Все это необходимо понимать и применять в разных задачах.
Попробуйте разработать программу как сами считаете нужным, а потом используя правила ООП, а возможно и некоторые паттерны. Сразу заметите их преимущество.
Цитата ArromanFox ( ) А как же взаимодействие классов?
Для взаимодействия классов хватит n-го количества переменных, методов, свойств и.т.п, а не все.
|
|
|
| |
| Xakep | Дата: Пятница, 12 Февраля 2016, 21:03 | Сообщение # 85 |
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата ArromanFox ( ) P.S Если кому-то интересно, то в ООП заложено 3 правила, которые желательно выполнять. Так одно из них и есть - инкапсуляция ( сокрытие данных). Суть его состоит в том, чтобы максимально скрыть всю логику класса.
Ну это не обязательно, можно просто в документации прописать что лучше этот метод/переменную не трогать и все, так например в python вообще нету инкапсуляции, просто соглашение, что если перед переменной/методом стоит нижнее подчеркивание (к пример: _foo) то этот метод лучше не трогать, хотя никто не мешает его вызвать.
В ООП в основном инкапсуляция классов, например у тебя один класс всем занимается, но это может быть не очень гибко, к примеру у тебя класс Editor который и правописание проверяет и за отрисовку символов отвечает и еще много чего можно придумать, так делать не самое лучшее решение, лучше инкапсулировать классы, т.е. создать отдельно класс, который будет заниматься проверкой правописания, и в то же время ничего не знает о редакторе, ему это и не нужно, отдельно класс на отрисовку различных глифов (тут тоже есть где развернуться), и уже класс редактор или менеджер какой-то использует эти классы, хотя тоже не обязательно, можно рекурсивную схему составить, при которой есть один root глиф, и уже от него все идет, и отрисовка и прочее.
|
|
|
| |
| Izaron | Дата: Пятница, 12 Февраля 2016, 21:41 | Сообщение # 86 |
Rammstein forever
Сейчас нет на сайте
| Что это? Зачем? Почитайте учебник Шилдта про Java 8. И мануалы по IntelliJ Idea. Очень поможет. Добавлено (12 февраля 2016, 21:41)
---------------------------------------------
Еще можно почитать Head First O'Reilly Java, где воды больше, чем в Тихом Океане, но ученикам средних классов в самый раз.
|
|
|
| |
| ArromanFox | Дата: Пятница, 12 Февраля 2016, 21:58 | Сообщение # 87 |
|
почетный гость
Сейчас нет на сайте
| Lapish, Xakep, мне вообще казалось, что закрывать те или иные методы и данные имеет смысл только в том случае, если их вызов в неположенном месте или изменение данных, противоречит логике программы и может привести к её сбою, неправильной работе и более серьезным проблемам. В остальных случаях, когда открытость не вредит, в случае ограничения доступа к ним могут возникнуть трудности при изменении программы. Например мы решили спустя пять лет, что какие-то данные могут изменяться откуда-то ещё. Разве использование ограничения доступа не должно быть оправданным?
Xakep, вот и мне кажется, что если речь не идет о закрытии методов и данных от третьих лиц или в качестве профилактики сбоев, можно это всё просто в документации прописывать.
Наблюдатель
|
|
|
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 22:32 | Сообщение # 88 |
|
старожил
Сейчас нет на сайте
| ArromanFox, так весь принцип инкапсуляции заключается в сокрытии членов класса для того чтобы кто либо ненадлежащим образом его не изменил.
Смотри - холодильник. В нем есть механизм в котором идеально сощуществуют компоненты, есть его характеристики. Есть действия, закрыть лампочку-открыть лампочку... Тьфу, вкл/выкл короче. Плюс методы уровня мороза. А ведь мы не знаем как это все тама устроено, нам положил еду и всё. Так и в Инкапсуляции все то, что заведомо ненужно, или изменение данного аспекта может привести к Бог знает чему и лучше не лезть. А про то, что можно тупо написать в документации к коду "Этото не трогать"... Ну не катит. Это же ООП. Мы все обязаны соблюдать правила хорошего кода.
ВЫВОД: Инкапсуляция - механизм сокрытия заведомо ненужных аспектов или замена значений коих может привести к непредвиденным последствиям. В программирование для сокрытия аспектов используется модификатор доступа private, который прекрывает доступ к аспектам везде что вне текущего класса, есть еще public, он делает обратку, все аспекты доступны всем.
Хотя доступ к аспектам скрытым private есть, сеттеры, но тут лучше обратиться к Гуглу, ведь пока не подвернется случай, я так не объясню. Ниже будут представлены открытая и закрытая переменная.
Переменные нужно скрывать :
А: При передаче кода третьим лицам, чтобы никто не сломал механизм (Предварительно в документации к коду лучше написать "Переменные перед которыми стоит модификатор private не трогать!")
Б: При работе в команде.
В: ООП ведь!
Закрытая
Открытая
Надеюсь объяснил более менее сносно.
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
Сообщение отредактировал Alfe - Пятница, 12 Февраля 2016, 22:43 |
|
|
| |
| Xakep | Дата: Пятница, 12 Февраля 2016, 22:39 | Сообщение # 89 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Alfe ( ) А про то, что можно тупо написать в документации к коду "Этото не трогать"... Ну не катит.
Ну не катит как аргумет тоже не катит, можно все это условно обозначить, конечно стоит инкапсулировать, но некоторые личности слишком увлекаются этим, и там где лучше сделать открытую переменную/метод, для того чтобы проще было получить к ней доступ из другого класса к примеру (я вкурсе про friend классы, но бывает что все слишком абстрактно что и friend классы никуда не впишешь), некоторые городят хрен знает что, тем самым усложняя код и снижая производительно, так что я лучше просто напишу в документации что не трогайте это пожалуйста, вместо того, чтобы добавлять лишний оверхед.
|
|
|
| |
| Lapish | Дата: Пятница, 12 Февраля 2016, 22:40 | Сообщение # 90 |
|
частый гость
Сейчас нет на сайте
| Xakep, фактически вы описали паттерн "Фабрика". А что на счет модификаторов доступа, то не спорю, что в разных яп все по-разному. Я говорю лишь за C# и саму идеологию ООП, а у ж как ее реализовали в том или ином языке, я могу и не знать.
ArromanFox, зачем другим классам знать о "ненужных переменных", которые используются для внутренних расчетов класса? Именно. Незачем.
Пример: у нас есть базовый класс и мы не скрываем его переменные и методы, а делаем их публичными. Унаследуем от него класс и добавим несколько переменных. В итоге у нас будет много лишнего мусора из базового класса. Если же мы сделали часть переменных private, часть public и часть protected, то мусора бы не было.
А что будет, если мы унаследуем класс несколько раз, если нам это позволяет сделать яп? Там вообще с ума можно сойти. Полнейший говнокод будет.
Советую почитать лучше про ООП.
P.S Кроме private и public есть и другие важные модификаторы: protected, sealed, internal и другие.
|
|
|
| |
| Xakep | Дата: Пятница, 12 Февраля 2016, 22:42 | Сообщение # 91 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Alfe ( ) Открытая
Код
private int b;
наверное ты хотел написать public int b;Добавлено (12 февраля 2016, 22:42)
---------------------------------------------
Цитата Lapish ( ) Xakep, фактически вы описали паттерн "Фабрика". А что на счет модификаторов доступа, то не спорю, что в разных яп все по-разному. Я говорю лишь за C# и саму идеологию ООП, а у ж как ее реализовали в том или ином языке, я могу и не знать.
я просто привел пример инкапсуляции классов, она не только в паттерне "Фабрика" применяется, да практически любой паттерн создается с целью инкапсулировать классы друг от друга.
|
|
|
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 22:42 | Сообщение # 92 |
|
старожил
Сейчас нет на сайте
| Xakep, если у кого то фанатизм, у того нет логики. Ясно ж написано - инкапсулировать нужно только те объекты изменение которых может привести к неизвестности.
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
|
|
|
| |
| Lapish | Дата: Пятница, 12 Февраля 2016, 22:42 | Сообщение # 93 |
|
частый гость
Сейчас нет на сайте
| Цитата Xakep ( ) Так что я лучше просто напишу в документации что не трогайте это пожалуйста, вместо того, чтобы добавлять лишний оверхед.
Большая вероятность, что документацию никто не прочтет и все полетит. На мой взгляд неправильное решение.
|
|
|
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 22:44 | Сообщение # 94 |
|
старожил
Сейчас нет на сайте
| Lapish, я в курсе про другие модификаторы доступа. В Java их 4. private, public,protected, default. Про последнии 2 я не рассказал... Это пока не нужно.
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
|
|
|
| |
| Xakep | Дата: Пятница, 12 Февраля 2016, 22:45 | Сообщение # 95 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Alfe ( ) Xakep, если у кого то фанатизм, у того нет логики. Ясно ж написано - инкапсулировать нужно только те объекты изменение которых может привести к неизвестности.
То что я описал выше, может привести к неизвестности, если кто-то их трогать начнет.
Цитата Lapish ( ) Большая вероятность, что документацию никто не прочтет и все полетит.
Это уже его проблемы, надо читать документацию )
Цитата Lapish ( ) На мой взгляд неправильное решение.
Скажи это создателем python (между прочем автор в то время работал в Google, да и google в большинстве своих проектов его использует), у которых вообще нет инкапсуляции, она лишь на уровне соглашения между программистами, что если я сделаю нижнее подчеркивание перед переменной/методом, то ее лучше не трогать, но никто не мешает в общем-то.
|
|
|
| |
| Lapish | Дата: Пятница, 12 Февраля 2016, 22:45 | Сообщение # 96 |
|
частый гость
Сейчас нет на сайте
| Цитата Alfe ( ) если у кого то фанатизм, у того нет логики. Ясно ж написано - инкапсулировать нужно только те объекты изменение которых может привести к неизвестности.
Инкапсулировать нужно абсолютно все, к чему не должны иметь доступ остальные классы.
|
|
|
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 22:47 | Сообщение # 97 |
|
старожил
Сейчас нет на сайте
| Lapish, Цитата Большая вероятность, что документацию никто не прочтет
Нельзя просто так взять и Код Переменные, методы, с модификатором private не трогайте, т.к при незнании архитектуры кода полезая в private переменные есть риск сломать механизм
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
Сообщение отредактировал Alfe - Пятница, 12 Февраля 2016, 22:48 |
|
|
| |
| Xakep | Дата: Пятница, 12 Февраля 2016, 22:49 | Сообщение # 98 |
|
めちゃくちゃちゃ
Сейчас нет на сайте
| Цитата Lapish ( ) Инкапсулировать нужно абсолютно все, к чему не должны иметь доступ остальные классы.
см. пост выше. некоторые проекты вообще обходятся без классов и инкапсуляции, но при этом используют ООП, к примеру - Blender, написан он на Си. Нет такого правила что обязательно нужно все инкапсулировать, от этого моя программа по другому работать не перестанет, другое дело что я могу закрыть все что не нужно от программистов которые будут поддерживать те или иные участки кода.
|
|
|
| |
| Lapish | Дата: Пятница, 12 Февраля 2016, 22:50 | Сообщение # 99 |
|
частый гость
Сейчас нет на сайте
| Цитата Xakep ( ) Скажи это создателем python (между прочем автор в то время работал в Google, да и google в большинстве своих проектов его использует), у которых вообще нет инкапсуляции, она лишь на уровне соглашения между программистами, что если я сделаю нижнее подчеркивание перед переменной/методом, то ее лучше не трогать, но никто не мешает в общем-то.
К сожалению, с python, так и не посидел плотно, но представляю тот ужас, если в классе 100 переменных, 90% из которых _name + точно также с методами, свойствами, событиями и прочими наворотами. Так и посидеть можно. Может к этому можно привыкнуть, но для меня было бы дико.
Как-то доводилось писать сервак на C, так от его подзагрузки абсолютно всех методов, которые мне нужны и не нужны плохо становилось. Думаю тут примерно также.
|
|
|
| |
| Alfe | Дата: Пятница, 12 Февраля 2016, 22:50 | Сообщение # 100 |
|
старожил
Сейчас нет на сайте
| Lapish, ну я почятай так и написал. Под фанатизмом я имел ввиду то, что все подчистую загребать под private. А говоря о инкапсулировании объектов измение которых может привести к неизвестности, я подразумевал то, что и другой класс тоже имеет место изменить незаинкапсулированный объект, подгрузить его, что ненадо, низзя, плохо.
Группа нашей команды. Там есть интересная рубрика... иногда игры выходят
Моя первая игpa - Crazy Penguin
Сообщение отредактировал Alfe - Пятница, 12 Февраля 2016, 22:51 |
|
|
| |
|
