|
![]() |
#1 |
Участник
|
Вообще говоря, ценность internal не в том, чтобы поставить железобетонный забор и никого не пускать, а в том, чтобы отделить публичный API от особенностей реализации: поставщик может сказать, что вот это он обещает не менять (ну или менять только по очень уважительной причине), а вот это он изменит как хочет. Пользователь может понять как ему строить модификации чтобы свести работу по обновлению к минимуму.
|
|
![]() |
#2 |
Участник
|
|
|
![]() |
#3 |
Участник
|
|
|
![]() |
#4 |
Участник
|
|
|
![]() |
#5 |
Участник
|
Цитата:
и 3) Как без internal предотвратить неумышленное использование особенностей реализации с учетом того, что (2) для того, чтобы создать экземпляр интерфейса все равно нужен класс. |
|
![]() |
#6 |
Участник
|
Цитата:
пойми и меня - для внутренних классов совсем не обязательно использовать интерфейсы. достаточно обычных классов. internal - не нужен, дядя Вова. http://coub.com/view/138x2 но если так хочется, и если уж пошли по пути public-полей. то и фиг с ними. |
|
![]() |
#7 |
Участник
|
Цитата:
![]() Интерфейсы кое-где, например, могут быть удобнее тем, что позволяют множественное наследование. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|