LINUX.ORG.RU

Неужели private методы действительно нужны?

 ,


0

1

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

★★★★★

Проблемы публичных и приватных методов это проблемы инкапсуляции. А инкапсуляция это часть ООП. Все это знают, но я конкретизирую - если не хочешь возиться с инкапсуляцией, то и в оопщину зря полез.

Bfgeshka ★★★★★ ()

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

Sadler ★★★ ()
Последнее исправление: Sadler (всего исправлений: 2)

Обычно в private раздел выносят то, работа с чем нетривиальна и требует глубокого понимания работы класса. Т.е. те переменные и методы, использование которых «в лоб» не имеет смысла с точки зрения здравомыслия.

ZweiStein ★★ ()

Работа через private-методы сродни хирургическому вмешательству на мозге препарируемого объекта.

iZEN ★★★★★ ()
Ответ на: комментарий от Bfgeshka

При чем тут инкапсуляция. Вот допустим есть либа которая внутри формирует и обрабатывает некий список. Но авторы решили во первых не выставлять наружу метод формирования и обработки и что сортировать этот список не нужно. А вот мне нужно чтобы список был сортированным или допустип оттуда нужно выкинуть дубли. Чем бы помешало инкапсуляции возможность переопределить метод формирования списка дописав 1 строку с сортировкой?

И такой фигне куча примеров.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

Разработчики либы не представляют, для чего ещё она может понадобиться. Может для управления ядерным реактором? А они на это не подписывались.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

А если я дохера нейрохирург и пациент и так помирает а тут хоть шансы есть?

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

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

А так придётся чужой код дополнять (в лучшем случае) или просто переписывать.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от Bfgeshka

А почему ты не считаешь protected инкапсуляцией? Оно вполне себе скрывает реализацию. При этом не мешая дополнять код.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

А почему ты не считаешь protected инкапсуляцией?

Шта? Где я такое говорил?

Bfgeshka ★★★★★ ()
Ответ на: комментарий от Bfgeshka

Так у меня то претензии именно к private, что никакими наследниками не разруливается. А отделение внутреннего и внешнего интерфейсоа это вещь полезная. Ты ж гришь мол инкапсуляция то инкапсуляция се.

ya-betmen ★★★★★ ()

Нужны, но программисты зачастую не думают об удобстве кастомизаций или расширения функциональности, а зачастую думают «меньше открыл -> меньше описал -> меньше отвечаешь». Это в закрытом коде, будь благословлён открытый код.

vtVitus ★★★★★ ()
Ответ на: комментарий от ya-betmen

Ты ж гришь мол инкапсуляция то инкапсуляция се.

Так вот именно. Нет где инкапсуляции, там нет и приватных символов (и protected иже с ними).

Живут же как-то люди без этой громистской бюрократии - и будь у тебя на руках такая либа, то ты бы не сокрушался тут, почему ничего нельзя и никакого праздника.

Понимаю, что зона видимости может быть миленьким удобным инструментом, но ни в коем случае не необходимым.

Bfgeshka ★★★★★ ()

Неужели принципы важнее чем удобство использования?

Возможно именно это. Могу быть и не прав, но идея таких либ и таких объектов в том чтобы сделать черный ящик(раз уж приватные методы). То есть код делает только то что нужно. К примеру формирует список и что-то с ним делает.. ну так идея в том, чтобы сначала сформировать/обработать, а уже потом делать с этим что угодно. В том числе сортировать и удалять дубли.

Могу быть неправ конечно, но все книги по ООП имеют примерно такой посыл.

Kronick ()

Чтобы развязать себе руки на случай если вдруг в будущем захочется изменить сигнатуру метода. Чем больше методов в публичном интерфейсе тем сложнее все это хозяйство поддерживать.

shimshimshim ()
Ответ на: комментарий от shimshimshim

Чем больше методов в публичном интерфейсе тем сложнее все это хозяйство поддерживать.

Речь не про публичные интерфейсы же. Ну и как бы тот кто прилепился ко внутреннему апи сам несёт вся тяготы и лишения его смены.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

А как отделить внутреннее от невнутреннего, если и те и другие методы protected и public?

Так оно и отделяется - внутренние это private, нужны они тебе - делаешь копию класса. А в основной репе эти private меняются даже в минорных версиях и отдельных билдах. Если это вынести в public да еще и в динамические модули вся версификация пойдет в женский половой орган. Придется на каждый чих делать новую мажорную версию.

shimshimshim ()

смотрю многие меняют версии либ без всестороннего тестированиря

wxw ★★★★★ ()
Ответ на: комментарий от shimshimshim

А как отделить внутреннее от невнутреннего, если и те и другие методы protected и public?

Ну как же, public это внешние, всё остальное - на страх и риск пользователя же.

ya-betmen ★★★★★ ()
Ответ на: комментарий от ya-betmen

Речь не про публичные интерфейсы же. Ну и как бы тот кто прилепился ко внутреннему апи сам несёт вся тяготы и лишения его смены.

Так не бывает. Либо API публичное (как для прямого использования - public, так и для расширения - protected), либо нет (private). Если оно публичное, разработчик _обязан_ сохранять совместимость, что может сильно усложнить развитие библиотеки. На самом деле создание любой точки кастомизации уже значительно усложняет как интерфейс, так ландшафт для тестирования и количество инвариантов для проверки.

Твои слёзные заверения о том что ты сам несёшь тяготы ничего не стоят, поскольку при изменении этих API такие первыми бегут строчить issue, а ведь кроме тебя есть ещё толпа тех кто даже подписываться на тяготы не собирается.

Так что если ты правда готов нести тяготы - форкай код и делай что хочешь, не создавая проблем апстриму.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

разработчик _обязан_ сохранять совместимость, что может сильно усложнить развитие библиотеки

Чё правда что ли?

при изменении этих API такие первыми бегут строчить issue

А разработчики настолько тупы что не могут закрыть их как некондиционные?

форкай код и делай что хочешь, не создавая проблем апстриму.

Да-да, нужно добавить одну строку кода - иди и форкай остальные 100500. Это конечно же гораздо логичнее чем завязавшимся на старую версию либы либо продолжать сидеть на ней либо форкать и бакпортировать нужные фичи.

ya-betmen ★★★★★ ()
Последнее исправление: ya-betmen (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Чё правда что ли?

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

А разработчики настолько тупы что не могут закрыть их как некондиционные?

А они кондиционные. Я же говорю - либо API публичное, и гарантируется совместимость, либо API приватное, и тебя туда никто не пустит, третьего не дано.

Да-да, нужно добавить одну строку кода - иди и форкай остальные 100500. Это конечно же гораздо логичнее чем завязавшимся на старую версию либы либо продолжать сидеть на ней либо форкать и бакпортировать нужные фичи.

Можешь предложить разработчикам добавить точку кастомизации в этом месте. Может оно и имеет право на жизнь, а может это только твоя неадекватная хотелка и ты будешь закономерно послан.

slovazap ★★★★★ ()

Неужели принципы важнее чем удобство использования?

Это защита от дурака. В некоторых ЯП можно обойти защиту, навесив временный костыль.

В конце концов если я сделал что-то не так с чужим кодом это моя проблема.

Это на лоре ты такой смелый. А как всё сломается, пойдешь разработчикам нервы трепать. Мало ли какие шизики пользуются этой библиотекой. Поэтому профит от подобного подхода перекрывает недостатки.

foror ★★★ ()
Ответ на: комментарий от ya-betmen

Ты же понимаешь, будь оно так - тема называлась бы «Неужели так трудно сделать API публичным?»)

Deleted ()
Ответ на: комментарий от slovazap

Вот попробуешь поподдерживать свою библиотеку у которой круг пользователей чуть больше чем один ты

Сколько библиотек поддерживаешь ты?

или поиспользуешь чужую, у которой API ломают в каждом минорном релизе, тогда и вопросов таких задавать не будешь.

Эм а при чем тут ломание апи в минорных релизах?

А они кондиционные.

И с какого перепугу?

Можешь предложить разработчикам добавить точку кастомизации в этом месте. Может оно и имеет право на жизнь, а может это только твоя неадекватная хотелка и ты будешь закономерно послан.

Вот чтобы разработчикам не было необходимости втыкать точки кастомизации в каждую строчку достаточно поменьше использовать private и побольше protected.

ya-betmen ★★★★★ ()
Ответ на: комментарий от foror

Это защита от дурака.

Защита от дурака в случае когда она ему грозит смерть хотя бы как-то оправдана, каков её смысл тут?

Мало ли какие шизики пользуются этой библиотекой. Поэтому профит от подобного подхода перекрывает недостатки.

Какие проблемы могут быть у авторов? Почему их должны интересовать проблемы шизиков?

ya-betmen ★★★★★ ()
Последнее исправление: ya-betmen (всего исправлений: 2)
Ответ на: комментарий от ya-betmen

Вот чтобы разработчикам не было необходимости втыкать точки кастомизации в каждую строчку достаточно поменьше использовать private и побольше protected.

Ты так ничего и не понял.

slovazap ★★★★★ ()
Ответ на: комментарий от ya-betmen

Защита от дурака в случае когда она ему грозит смерть хотя бы как-то оправдана, каков её смысл тут?

Ты сам же обозначил смысл: «в случае когда ему грозит смерть» - только смерть не обязательно физическая, здесь она скорее ментальная. Умные дяди для этого и придумали инкапсуляцию. Даже если ты еще этого не понимаешь, они уже позаботились о тебе. Может в будущем и сам выйдешь на этот уровень понимания.

Какие проблемы могут быть у авторов? Почему их должны интересовать проблемы шизиков?

Вот сразу видно зеленого новичка. Шизики они по всюду и считают, что им все всё должны. Ты даже не представляешь насколько люди бывают наглые и не воспитанные вопреки даже среди погромистов. И порой эти шизики очень навязчивы и засоряют информационное поле авторов библиотеки.

foror ★★★ ()
Последнее исправление: foror (всего исправлений: 3)
Ответ на: комментарий от foror

Особенно когда у них что-то ломается. Вон, посмотри на ту же Java 9 - сколько шизиков повылазило. Но тут как бы без адресно. А в случае библиотеки получается очень адресно.

foror ★★★ ()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от foror

здесь она скорее ментальная.

Ошибаешся тут её нет совсем

И порой эти шизики очень навязчивы и засоряют информационное поле авторов библиотеки.

Так говоришь как бкдто шизиков больше чем нормальных людей.

ya-betmen ★★★★★ ()
Ответ на: комментарий от foror

Вон, посмотри на ту же Java 9 - сколько шизиков повылазило.

Что я пропустил?

ya-betmen ★★★★★ ()

Нужны, но так же нужны и protected методы.

bbk123 ★★★★★ ()

Постоянно сталкиваюсь м ситуацией когда разработчики какой нить либы закрывают все кишки

Значит, они не умеют в ООП.

вместо переопределения одного метода в одном классе приходится копипастить половину класса

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

Wizard_ ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)