|
|
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Следует ли считать хорошей практикой использование strict private вместо private ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 17:47 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Имеет смысл использовать если ты делаешь платные компоненты и распространяешь в dcu Мне кажется protected - самое то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 18:06 |
|
||
|
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:10 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Из одной мертвой галактики, Притом, что private вообще не нужен. Ни обычный, ни strict. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 18:20 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Еретики... и private нужен, и strict. Я везде применяю strict, чтобы в подсказках лишние методы не маячили. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 18:29 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovУ классов для сторонних пользователей любое private смердит, поскольку не позволяет использовать полиморфизм ради которого (в том числе) классы и задумывались. И каким же образом доступность кишок класса связана с полиморфизмом? Вообще. Я вижу так: public и protected - это интерфейс, API. Менять его может быть затруднено и болезненно. А private - это внутренняя реализация, которую можно менять как вздумается. И без этой области свободных манипуляций внесение изменений в класс взрастит такой геморрой у разработчика, что ну вас нафиг с такими идеями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 18:41 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Василий №2И каким же образом доступность кишок класса связана с полиморфизмом? Приватные методы нельзя оверрайдить. К приватным полям нельзя достучаться. Изменить поведение базового класса, автор которого злоупотреблял приватностью, невозможно. Полиморфизм недоступен. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 18:52 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Из одной мертвой галактикиСледует ли считать хорошей практикой использование strict private вместо private ?Следует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 18:59 |
|
||
|
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:02 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Из одной мертвой галактикиСледует ли считать хорошей практикой использование strict private вместо private ?Нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 19:05 |
|
||
|
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:22 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Действительно, странно противопоставлять полиморфизм механизмам инкапсуляции. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 19:25 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Василий №2Полиморфизм вполне себе доступен в рамках, отведенных для этого автором. Проблема в том, что автор, отдавая компоненты на сторону, обычно сам не знает, что именно может потребоваться перекрыть. Мне пару раз приходилось переписывать штатные VCL-компоненты только лишь потому, что авторы не добавили директиву virtual в одном месте. Даже в приведенном примере лучше сразу делать виртуальный геттер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 19:50 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Не просто же так частные поля делают. И закрывают информацию внутри класса. Так то можно, конечно, всё наружу или почти наружу вытащить, говоря - делайте что хотите, сломаете - ваши проблемы. Только, мне кажется, это плохой подход. Вообще. В крайнем случае можно сырцы поправить. А код без исходников лучше вообще не применять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 20:17 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
makhaonВ крайнем случае можно сырцы поправить.Эта практика намного хуже, напрочь убивает идею сопровождения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 20:35 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Соколинский БорисmakhaonВ крайнем случае можно сырцы поправить.Эта практика намного хуже, напрочь убивает идею сопровождения. в реальной жизни гораздо быстрее исправить ошибку в исходниках, чем бесконечно переписываться с аффтаром, который может бюыть вообще недоступен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 20:42 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
defecator, это понятно. Но как же бесит при этом муторная сверка исходников после обновления... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 20:56 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
всем противникам strict private рекомендую вспомнить о class sealed, он вообще явно запрещает любых наследников класса)))) шах и мат полиформизму и его безумным поклонникам))) strict private вызывает ненависть? храните все в public!))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 20:57 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
asutp2всем противникам strict private рекомендую вспомнить о class sealed, он вообще явно запрещает любых наследников класса)))) шах и мат полиформизму и его безумным поклонникам))) strict private вызывает ненависть? храните все в public!))) пиши процедурно, безумец, не стесняйся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 21:01 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
defecatorasutp2всем противникам strict private рекомендую вспомнить о class sealed, он вообще явно запрещает любых наследников класса)))) шах и мат полиформизму и его безумным поклонникам))) strict private вызывает ненависть? храните все в public!))) пиши процедурно, безумец, не стесняйсяпочему же, я как раз сторонник классов, но считаю, что ВСЕГДА разрешать давать наследникам перекрывать ВСЕ свойства и методы мягко говоря неправильно. Так вообще можно дойти до того, что будет единственная ветка наследования класс1<-класс2<-класс3<-....<-класс9999999999999999 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 21:09 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
asutp2defecatorпропущено... пиши процедурно, безумец, не стесняйсяпочему же, я как раз сторонник классов, но считаю, что ВСЕГДА разрешать давать наследникам перекрывать ВСЕ свойства и методы мягко говоря неправильно. Так вообще можно дойти до того, что будет единственная ветка наследования класс1<-класс2<-класс3<-....<-класс9999999999999999 ты же назвал сторонников полиморфизма безумными а ведь полиморфизм это другое, не то, что ты только что описал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 21:12 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
Буч - это голова. И Фаулер - это голова. Фаулер и Буч - это две головы. Читайте классиков, вопросы отпадут сами собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 21:17 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
defecatorasutp2пропущено... почему же, я как раз сторонник классов, но считаю, что ВСЕГДА разрешать давать наследникам перекрывать ВСЕ свойства и методы мягко говоря неправильно. Так вообще можно дойти до того, что будет единственная ветка наследования класс1<-класс2<-класс3<-....<-класс9999999999999999 ты же назвал сторонников полиморфизма безумными а ведь полиморфизм это другое, не то, что ты только что описаля назвал безумными не тех, кто адекватно использует различные области видимости в классах/необходимые элементы для перекрытия в зависимости от задачи, а тех, кто желает изменять все что вздумается наследному классу и ненавидит strict private))). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 21:33 |
|
||
|
Strict private
|
|||
|---|---|---|---|
|
#18+
авторНо как же бесит при этом муторная сверка исходников после обновления... Дифф в помощь. Автоматический или руками пробежаться. Винмержем я, например, инди свожу за час-полтора. У меня правок десятка два мест. Шансов, что их добавят, я думаю, около нуля. Быстрее руками свести. Особенно если надо не часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2018, 21:39 |
|
||
|
|

start [/forum/topic.php?fid=58&fpage=115&tid=2041140]: |
0ms |
get settings: |
8ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 390ms |

| 0 / 0 |
