
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
13.03.2018, 17:47
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Следует ли считать хорошей практикой использование strict private вместо private ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:06
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Имеет смысл использовать если ты делаешь платные компоненты и распространяешь в dcu Мне кажется protected - самое то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:10
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
SOFT FOR YOUИмеет смысл использовать если ты делаешь платные компоненты и распространяешь в dcu Мне кажется protected - самое то. При чем тут "protected и "распространение в dcu"? Речь о strict private . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:10
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Если ты делаешь классы исключительно для внутреннего потребления - сугубо пофиг. У классов для сторонних пользователей любое private смердит, поскольку не позволяет использовать полиморфизм ради которого (в том числе) классы и задумывались. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:20
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Из одной мертвой галактики, Притом, что private вообще не нужен. Ни обычный, ни strict. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:29
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Еретики... и private нужен, и strict. Я везде применяю strict, чтобы в подсказках лишние методы не маячили. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:41
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Dimitry SibiryakovУ классов для сторонних пользователей любое private смердит, поскольку не позволяет использовать полиморфизм ради которого (в том числе) классы и задумывались. И каким же образом доступность кишок класса связана с полиморфизмом? Вообще. Я вижу так: public и protected - это интерфейс, API. Менять его может быть затруднено и болезненно. А private - это внутренняя реализация, которую можно менять как вздумается. И без этой области свободных манипуляций внесение изменений в класс взрастит такой геморрой у разработчика, что ну вас нафиг с такими идеями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:52
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Василий №2И каким же образом доступность кишок класса связана с полиморфизмом? Приватные методы нельзя оверрайдить. К приватным полям нельзя достучаться. Изменить поведение базового класса, автор которого злоупотреблял приватностью, невозможно. Полиморфизм недоступен. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 18:59
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Из одной мертвой галактикиСледует ли считать хорошей практикой использование strict private вместо private ?Следует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 19:02
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Из одной мертвой галактикиСледует ли считать хорошей практикой использование strict private вместо private ? Если у вас на каждый класс отдельный unit, то необязательно. Если у вас более одного класса в модуле, и они могут пересекаться, то лучше strict. Иначе от такого вы не будете защищены. К тому же IntelliSense не будет показывать мусор из strict private Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 19:05
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Из одной мертвой галактикиСледует ли считать хорошей практикой использование strict private вместо private ?Нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 19:22
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Dimitry SibiryakovПриватные методы нельзя оверрайдить. К приватным полям нельзя достучаться. Изменить поведение базового класса, автор которого злоупотреблял приватностью, невозможно. Полиморфизм недоступен. Полиморфизм вполне себе доступен в рамках, отведенных для этого автором. Всё, что свыше этого, - от лукавого либо результат совсем уж убогой реализации. А вот доступ к кишкам класса куда вреднее. Например: Код: pascal 1. 2. 3. 4. 5. 6. При этом FSomeObj всегда создается в конструкторе и потому предполагается, что всегда не nil. Но условному апологету безграничного полиморфизма не нравится доступ по свойству, и он использует FSomeObj. А потом автор понимает, что FSomeObj нужен далеко не всегда и не сразу, поэтому встраивает создание перед использованием, меняя объявление на Код: pascal 1. И вот тут апологет ловит AV at address $000000 и идет курить бамбук. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 19:25
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Действительно, странно противопоставлять полиморфизм механизмам инкапсуляции. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 19:50
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
Василий №2Полиморфизм вполне себе доступен в рамках, отведенных для этого автором. Проблема в том, что автор, отдавая компоненты на сторону, обычно сам не знает, что именно может потребоваться перекрыть. Мне пару раз приходилось переписывать штатные VCL-компоненты только лишь потому, что авторы не добавили директиву virtual в одном месте. Даже в приведенном примере лучше сразу делать виртуальный геттер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 20:17
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Не просто же так частные поля делают. И закрывают информацию внутри класса. Так то можно, конечно, всё наружу или почти наружу вытащить, говоря - делайте что хотите, сломаете - ваши проблемы. Только, мне кажется, это плохой подход. Вообще. В крайнем случае можно сырцы поправить. А код без исходников лучше вообще не применять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 20:35
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
makhaonВ крайнем случае можно сырцы поправить.Эта практика намного хуже, напрочь убивает идею сопровождения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 20:42
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Соколинский БорисmakhaonВ крайнем случае можно сырцы поправить.Эта практика намного хуже, напрочь убивает идею сопровождения. в реальной жизни гораздо быстрее исправить ошибку в исходниках, чем бесконечно переписываться с аффтаром, который может бюыть вообще недоступен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 20:56
|
|||
|---|---|---|---|
|
|||
Strict private |
|||
|
#18+
defecator, это понятно. Но как же бесит при этом муторная сверка исходников после обновления... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 20:57
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
всем противникам strict private рекомендую вспомнить о class sealed, он вообще явно запрещает любых наследников класса)))) шах и мат полиформизму и его безумным поклонникам))) strict private вызывает ненависть? храните все в public!))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 21:01
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
asutp2всем противникам strict private рекомендую вспомнить о class sealed, он вообще явно запрещает любых наследников класса)))) шах и мат полиформизму и его безумным поклонникам))) strict private вызывает ненависть? храните все в public!))) пиши процедурно, безумец, не стесняйся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 21:09
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
defecatorasutp2всем противникам strict private рекомендую вспомнить о class sealed, он вообще явно запрещает любых наследников класса)))) шах и мат полиформизму и его безумным поклонникам))) strict private вызывает ненависть? храните все в public!))) пиши процедурно, безумец, не стесняйсяпочему же, я как раз сторонник классов, но считаю, что ВСЕГДА разрешать давать наследникам перекрывать ВСЕ свойства и методы мягко говоря неправильно. Так вообще можно дойти до того, что будет единственная ветка наследования класс1<-класс2<-класс3<-....<-класс9999999999999999 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 21:12
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
asutp2defecatorпропущено... пиши процедурно, безумец, не стесняйсяпочему же, я как раз сторонник классов, но считаю, что ВСЕГДА разрешать давать наследникам перекрывать ВСЕ свойства и методы мягко говоря неправильно. Так вообще можно дойти до того, что будет единственная ветка наследования класс1<-класс2<-класс3<-....<-класс9999999999999999 ты же назвал сторонников полиморфизма безумными а ведь полиморфизм это другое, не то, что ты только что описал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 21:17
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
Буч - это голова. И Фаулер - это голова. Фаулер и Буч - это две головы. Читайте классиков, вопросы отпадут сами собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 21:33
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
defecatorasutp2пропущено... почему же, я как раз сторонник классов, но считаю, что ВСЕГДА разрешать давать наследникам перекрывать ВСЕ свойства и методы мягко говоря неправильно. Так вообще можно дойти до того, что будет единственная ветка наследования класс1<-класс2<-класс3<-....<-класс9999999999999999 ты же назвал сторонников полиморфизма безумными а ведь полиморфизм это другое, не то, что ты только что описаля назвал безумными не тех, кто адекватно использует различные области видимости в классах/необходимые элементы для перекрытия в зависимости от задачи, а тех, кто желает изменять все что вздумается наследному классу и ненавидит strict private))). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.03.2018, 21:39
|
|||
|---|---|---|---|
Strict private |
|||
|
#18+
авторНо как же бесит при этом муторная сверка исходников после обновления... Дифф в помощь. Автоматический или руками пробежаться. Винмержем я, например, инди свожу за час-полтора. У меня правок десятка два мест. Шансов, что их добавят, я думаю, около нуля. Быстрее руками свести. Особенно если надо не часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=58&mobile=1&tid=2041140]: |
0ms |
get settings: |
11ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
169ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
82ms |
get tp. blocked users: |
1ms |
| others: | 279ms |
| total: | 581ms |

| 0 / 0 |
