> 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]
> а стол на колесиках? ;)))

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