Четверг, 05 Декабря 2024, 19:47

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
Курс:"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 не трогать!")
Б: При работе в команде.
В: ООП ведь!

Закрытая
Код
private int a;

Открытая
Код
public int b;

Надеюсь объяснил более менее сносно.


Группа нашей команды. Там есть интересная рубрика... иногда игры выходят

Моя первая иг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
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг