Ну вот хочется мне, допустим, чему-нибудь там что-нибудь присвоить, или кого-нибудь там вызвать. Бывает. Так нет же. Приват. Не трожь руками генофонд. А почему?

Вот модуль. Сделанный года 4 назад. Когда и мысли не возникало о необходимости вызова метода ХХХ. Ну, не было такой задачи. А теперь - модуль переписывать. Немного, но обидно.

Да, я понимаю свою заботу 4-летней давности. Все внутреннее внутрь. Как же. А вот зачем? Чтобы глупый пользователь не вызвал? Ну, ёлы палы, назвать этот метод не ХХХ, а _ХХХ, или _DO_NOT_CALL_XXX для совсем дебилов. Ну все равно ж совсем дебил вызовет. Исходники поправит накрайняк (они, разумеется, доступны). А умный не вызовет. Или хотя бы подумает, и вызовет осознанно.

Ну, зачем, зачем сознательно ограничивать свободу??????

> Ну, зачем, зачем сознательно ограничивать свободу??????


Свобода есть разумные ограничения - вроде Линкольн.
Жень это судьба такая.

Перенеси в protected, какие проблемы?

> Перенеси в protected, какие проблемы?


Суть она в багах -  private  только в том - же файле перекрывать и повышать видимость можно.

> Свобода есть разумные ограничения - вроде Линкольн.

Дисциплина, как осознаная необходимость.

TUser ©   (15.01.09 12:50)  

>Вот модуль. Сделанный года 4 назад. Когда и мысли не возникало о >необходимости вызова метода ХХХ. Ну, не было такой задачи. А теперь - >модуль переписывать. Немного, но обидно.

В таком случае лучше переписать.

Поверь - ты как автор модуля и ты как его
пользователь - это совсем разные люди.
:-)

> Не трожь руками генофонд. А почему?

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


> Ну, зачем, зачем сознательно ограничивать свободу??????

если есть исходники, то помещение метода в private ничуть не ограничивает твою свободу в его вызове, ведь сорцы ты всегда можешь поменять.  с другой строрны, если ты не хочешь вызывать этот метод(то есть согласен с придуманными тобой же соглашениями), то лудше чтобы за коректностью вызова следил компилер.  Потому что через 4 месяца ты забудешь, что решил не вызывать извне этот метод.

А сделать для него обёртку в зоне видимости public? И первоначальная функциональность сохраняется, и цели достигнуты.

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

> Marser ©   (16.01.09 01:06) [7]

О и тёзка появился на форуме.
Привет Серёга. Сколько лет сколько зим!

P.S.
Может и газ теперь пойдёт? :)

> Германн ©   (16.01.09 01:10) [9]
>
>
> > Marser ©   (16.01.09 01:06) [7]
>
> О и тёзка появился на форуме.
> Привет Серёга. Сколько лет сколько зим!

Да, здрасте :-)
Тут уж добрая традиция, как я с полуночи ни объявлюсь, меня тёзка всегда встретит... И напоит... Виртуально :-))

> Marser ©   (16.01.09 02:11) [10]
> Тут уж добрая
> традиция, как я с полуночи ни объявлюсь, меня тёзка всегда
> встретит... И напоит... Виртуально :-))

Да не оскудеет чаша твоя, о тезка :-)

> TUser ©   (15.01.09 12:50)  

Вы как автор шедевра логично желаете, чтобы шедевр работал в соответствии с обещаным интерфейсом и, что очень немаловажно - стабильно. Потому часть полей/методов благоразумно засунули в privаte, чтобы никто через опубликованный интерфейс не мог нарушить целостность шедевра.

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

В общем и целом - это 2 разных подхода. Один мы видим в VCL, где все хорошо, но пока стандартная функциональность тебя устраивает. Ну чуть зазочешь шаг вправо-влево - и приехали. Или все переписыывай от TComponent или извращайся обходными медотами, фактически находи какие-нибудь лазейки (зачастую это просто перехват сообщений), постоянно натыкаясь на все новые траблы и недоступностью очередной внутренней переменной.
И вторая парадигма, ее можно наблюдать в MFC, например: в классе есть минимальная обертка, спрятано - минимум, все остальное торчит наружу, вызывать нужные методы в нужном порядке, следить за внутренней целостностью - и т.д.

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

Я все-таки не понимаю, чни private лучше соглашения об именованиях. Дурак (если он дурак) все равно использовать будет. Умный тоже. Только подумает сначала. Называли бы все скрываемые методы с подчеркивания ...

> Ну, зачем, зачем сознательно ограничивать свободу??????


Инкапсуляция - кит ООП. Тебе ничего не мешает объявить Friend процедуру в модуле того класса.

> TUser ©   (16.01.09 10:27) [13]
> Я все-таки не понимаю, чни private лучше соглашения об именованиях.

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

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

Вот прикинь, сел в авто, дернул ручку - а оно рассыпалось...
Умный скажет "какого хрена ты ее дергал, она ж красная!"
Прав ли он будет?

Так и тут.

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

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

Собственно, не нравится инкапсуляция - не пользуйся :) Делай всё public и не парься. Заодно много новых и интересных слов узнаешь от людей, которым выпадет с твоим кодом работать :)

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


от подчеркиваний это не зависит

> Alkid ©   (16.01.09 15:51) [18]

Вот. Это самый правильный способ проверить свою философию. :)

А еще можно писать все без классов, в своих юнитах рекордами и процедурами. А для придания красоты пользовать {$i бла-бла}.

Тогда можно о себе многое узнать. От других. Или от себя через пару лет.

>>TUser ©   (16.01.09 10:27) [13]
>>Я все-таки не понимаю, чни private лучше соглашения об именованиях.

приблизительно тем же, чем отсутствие в самолете кнопки "уничтожить самолет" лучше ее наличия с табличкой "не нажимать!!! кто нажмет, тот дурак"

> TUser ©   (16.01.09 10:27) [13]
>
> Я все-таки не понимаю, чни private лучше соглашения об именованиях.
>  Дурак (если он дурак) все равно использовать будет. Умный
> тоже. Только подумает сначала. Называли бы все скрываемые
> методы с подчеркивания ...


Вот у меня есть класс по обработке документа хитрой структуры. Или ещё чего-нибудь.
Пользователю нужно всего 4 метода и одно свойство:



А в привате - сто тыщь мильёнов вспомогательных методов.
Вопрос: а надо их пользователю видеть?

> Ega23 ©   (16.01.09 17:59) [22]
> А в привате - сто тыщь мильёнов вспомогательных методов.
> Вопрос: а надо их пользователю видеть?

Олег, ты не понимаешь. Вот есть у тебя в этом классе, скажем, какой-нибудь метод для удобной трансформации какой-нибудь строки в структуру с данными, или сортировки какой-нибудь хитрой или форматирования текста, а тебе потом потребовался этот функционал в другой части программы. Модуль переписывать обидно => рефакторинг - это не для пацанов и вынести нужный функционал в общедоступное место впадлу. Гораздо проще дать доступ к приватным методам :)

P.S. Ну это так, пример только :)

Кстати, реальный случай с прошлой работы - сотрудники одного отдела (отдел А) жалуются на другой отдел (отдел Б), мол библиотека ваша что-то глючит. Пришли ребята из отдела Б разбираться, и что же они видят? Борясь со вселенским злом, ребята из А просто взяли и влезли в код библиотеки, открыв несколько приватных членов классов библиотеки и оперировали ими в обход методов в своё удовольствие. Только, вот, авторы такого подвоха не ожидали и их детище стало поглюкивать. Такие дела.

> Alkid ©   (16.01.09 18:12) [24]
> Только, вот, авторы такого подвоха не ожидали и их детище стало глюкивать.

Бракоделы и ущемители вселенской свободы

> TUser ©   (16.01.09 10:27) [13]
>
> Я все-таки не понимаю, чни private лучше соглашения об именованиях.
>  Дурак (если он дурак) все равно использовать будет. Умный
> тоже. Только подумает сначала. Называли бы все скрываемые
> методы с подчеркивания ...


Я стараюсь почти всегда все нужные методы вводить в зону protected и, если они выполняют небанальные действия, объявлять их как virtual. Потом проблем меньше и нарушения целостности нет. Так как доработчик компонента все равно посмотрит как он устроен внутри, а его пользователь не сможет добраться до того что ему не полагается.

> Alkid ©   (16.01.09 18:09) [23]
>
>

Именно так. Или завтра появился документ похожей структуры. Если [26], то мы пишем наследника. А если [22], то переписываем модуль копипастом.

> Alkid ©   (16.01.09 18:09) [23]
> Вот есть у тебя в этом классе, скажем, какой-нибудь метод
> для удобной трансформации какой-нибудь строки в структуру
> с данными, или сортировки какой-нибудь хитрой или форматирования
> текста,

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

> Petr V. Abramov ©   (18.01.09 07:50) [28]

Кто ж спорит, неправ. Но это лишь пример того, что не все всегда можно заранее продумать. Обычно это исправляется рефакторингом, но по условиям задачи рефакторинг - западло :)

> Alkid ©   (18.01.09 15:18) [29]

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

> Petr V. Abramov ©   (18.01.09 15:31) [30]

Совершенно верно, "наружу" должен торчать только корректный интерфейс, который не должен дать возможности привести объект в неконсистентное состояние (с точки зрения корректности программы, либо бизнес-правил).
Собственно, с автором топика из-за этого и спорим, ибо он утверждает, что запрещать доступ к этим методам не надо а стоит лишь пометить их некоторым образом, что бы разработчики сами не вызывали. Иными словами он предлагает этот контроль перенести механизмов языка в область дисциплины. Я считаю это ошибкой.

>Вопрос: а надо их пользователю видеть?

+1.

>Вот есть у тебя в этом классе, скажем, какой-нибудь метод для удобной трансформации какой-нибудь строки в структуру с данными, или сортировки какой-нибудь хитрой или форматирования текста

Как мы делаем у себя:

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

>Модуль переписывать обидно => рефакторинг - это не для пацанов

Для пацанов - говнокодинг. Рефакторинг - это для лохов, это да.

> TUser ©   (18.01.09 07:40) [27]
> Именно так. Или завтра появился документ похожей структуры.
>  Если [26], то мы пишем наследника. А если [22], то переписываем
> модуль копипастом.

Даже если значительная часть функционала внутри модулей совпадает? Имхо, это неразумно. Любое дублирование кода - зло. Лучше вынести общий функционал в отдельный модуль и ссылаться на него из других модулей, чем плодить копипасту.

Касаемо наследования вопрос сложнее. Я использую наследование только тогда, когда наследный класс можно рассматривать как подтип родительского во всех смыслах - и с точки зрения формальных правил языка и с точки зрения семантики приложения. Т.е. наследовать класс "Автомобиль" от класса "Стол", что бы повторно использовать функционал для обработки четырёх точек опоры я бы не стал (по крайней мере на языках отличных от С++ - в нем есть закрытое наследование), ибо автомобиль не является разновидностью стола.

> TUser ©   (15.01.09 12:50)  

strict private спасет отца русской демократии.

Пару лет назад здесь кем-то поднималась тема:
"Зачем нужна зона private, когда достаточно зоны protected?"
Автору был открыт секрет, что есть более кулльная зона public. Да и public фигня, есть еще круче - publushed.
Вобщем, сошлись на том, что рулят глобальные переменные.

> Alkid ©   (18.01.09 22:38) [33]
> Т.е. наследовать класс "Автомобиль" от класса "Стол", что
> бы повторно использовать функционал для обработки четырёх
> точек опоры я бы не стал

а стол на колесиках? ;)))

>Вобщем, сошлись на том, что рулят глобальные переменные.

Эта пять :)

> Petr V. Abramov ©   (19.01.09 19:09) [36]
> а стол на колесиках? ;)))

Ну, тогда надо делать так: