Delphi vs C++ vs C#
, ну и Java немножко, где-то ближе к старшему байту номеров страниц
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.156] |
|
|
Правила раздела:
| Страницы: (495) « Первая ... 305 306 [307] 308 309 ... 494 495 ( Перейти к последнему сообщению ) |
Delphi vs C++ vs C#
, ну и Java немножко, где-то ближе к старшему байту номеров страниц
|
Сообщ.
#4591
,
|
|
|
|
Почему? Как раз видит, что сигнатура подходит - значит, оно |
|
Сообщ.
#4592
,
|
|
|
|
Тогда нужна какая-нибудь такая плюшка, которая может "разрешать" использовать указанный класс, как поддерживающий указанный интерфейс.
Или явный каст, как вариант: ![]() ![]() bar(interface_cast<B>(new C())); |
|
Сообщ.
#4593
,
|
|
|
|
Цитата MyNameIsIgor @ Утиная типизация должна посмотреть только на сигнатуры методов, а не пространства имён. Иначе она вообще на хэ не нужна. в общем-то не обязательно, считайте имя пакета частью имени метода Добавлено Цитата Romkin @ Почему? Как раз видит, что сигнатура подходит - значит, оно ![]() так а в чем проблема-то? |
|
Сообщ.
#4594
,
|
|
|
|
Нет. Я этого нигде не говорил. Я говорил что абстрактный класс может быть интерфейсом, наоборот я напротив говорил что не может быть. Ну ок, вбил, нашол вот это http://www.codeproject.com/KB/cs/abstractsvsinterfaces.aspx: Цитата What is an Abstract Class? An abstract class is a special kind of class that cannot be instantiated. So the question is why we need a class that cannot be instantiated? An abstract class is only to be sub-classed (inherited from). In other words, it only allows other classes to inherit from it but cannot be instantiated. The advantage is that it enforces certain hierarchies for all the subclasses. In simple words, it is a kind of contract that forces all the subclasses to carry on the same hierarchies or standards. What is an Interface? An interface is not a class. It is an entity that is defined by the word Interface. An interface has no implementation; it only has the signature or in other words, just the definition of the methods without the body. As one of the similarities to Abstract class, it is a contract that is used to define hierarchies for all subclasses or it defines specific set of methods and their arguments. The main difference between them is that a class can implement more than one interface but can only inherit from one abstract class. Since C# doesn�t support multiple inheritance, interfaces are used to implement multiple inheritance. Правда с точки зрения шарпа все излагается, но обрати внимание даже на эти, главные отличия. |
|
Сообщ.
#4595
,
|
|
|
|
Цитата korvin @ так а в чем проблема-то? А в том, что это может быть случайным/частичным совпадением, писалось для другого интерфейса, и работает немного по другому алгоритму. И вперед, в отладку ![]() А вот явное указание интерфейса говорит о том, что при написании интерфейс был известен, и было известно его описание. Я понимаю, что это больше теоретизирование, но, кряк, если что-то можно сделать неправильно - сделают, рано или поздно. И компилятор должен максимально ограничивать или хотя бы просить каст. И еще не вижу причин динамически искать совпадение с интерфейсом, вместо того чтобы просто посмотреть на заголовок класса. Для скрипта это проходит, но для компилируемого языка неудобно. |
|
Сообщ.
#4596
,
|
|
|
|
Цитата scorpion @ Я говорил что абстрактный класс может быть интерфейсом На что тебе показали концептуальные различия - интерфейс не является классом и не участвует в наследовании. |
|
Сообщ.
#4597
,
|
|
|
|
Цитата Romkin @ А в том, что это может быть случайным/частичным совпадением, писалось для другого интерфейса, и работает немного по другому алгоритму. еще раз: пихающий не видит, что он пихает? |
|
Сообщ.
#4598
,
|
|
|
|
Цитата scorpion @ Я говорил что абстрактный класс может быть интерфейсом, наоборот я напротив говорил что не может быть. |
|
Сообщ.
#4599
,
|
|
|
|
Цитата Romkin @ А в том, что это может быть случайным/частичным совпадением, писалось для другого интерфейса, и работает немного по другому алгоритму. Как оно работает и по какому алгоритму - клиента интерфейса не касается. Цитата А вот явное указание интерфейса говорит о том, что при написании интерфейс был известен, и было известно его описание. В этом и проблема - если при создании класса не учли интерфейс, то придется или менять класс, или писать обертку. Что в случае совпадения сигнатур выглядит не очень хорошо. И по-моему такая ситуация более вероятна, чем ситуация с ошибочной передачей не того объекта. |
|
Сообщ.
#4600
,
|
|
|
|
Цитата korvin @ еще раз: пихающий не видит, что он пихает? Видит. И как правило видит он объявление класса. Где гарантия, что подразумевался именно этот интерфейс? |
|
Сообщ.
#4601
,
|
|
|
|
Цитата Romkin @ Цитата korvin @ еще раз: пихающий не видит, что он пихает? Видит. И как правило видит он объявление класса. Где гарантия, что подразумевался именно этот интерфейс? Подразумевался где? Пихающий в любом случае должен знать что он пихает и куда, иначе ему лучше ничего никуда пихать |
|
Сообщ.
#4602
,
|
|
|
|
Цитата D_KEY @ В этом и проблема - если при создании класса не учли интерфейс, то придется или менять класс, или писать обертку. Что в случае совпадения сигнатур выглядит не очень хорошо. И по-моему такая ситуация более вероятна, чем ситуация с ошибочной передачей не того объекта. По моему они равновероятны ![]() В общем, я уже запутался. Обертка, кстати, выглядит не так уж плохо, явное указание на связь, и скорее связь разных частей системы: в том же неймспейсе сокрее всего можно поменять класс. |
|
Сообщ.
#4603
,
|
|
|
|
Цитата D_KEY @ На что тебе показали концептуальные различия - интерфейс не является классом и не участвует в наследовании. Вы показали не концептуальные различия, вы показали конкретную фичу, конкретного яп, и утверждаете, что без этой фичи, абстрактные классы не могут ни при каких обстоятельствах являться интерфейсами. Другое дело, если бы вы начали приводить в качестве концептуальных различий то, что абстрактный класс может содержать в себе некую реализацию, тогда бы да. Тут уж не поспоришь. Но ведь речь идет о том, что если мы напишем такую сущность, которая удовлетворяет концепции интерфейсов, то мы можем смело назвать ее интерфейсом. Это частный случай. Это не делает абстрактные классы интерфейсами, ил инаоборот. Это всего лишь говорит, что эта сущность ведет себя как интерфейс. И поэтому, может вполне так называтся. Всякие же плюшки, приведеные вами ранее, никак не связаны с концепцией интерфейсов. Вот давай, спросим у присутствующих, пишуших на C#. Когда лучше использовать интефрейс, а когда лучше использовать абстрактный класс в рамках именно C# ? Добавлено Цитата Romkin @ Цитата Я говорил что абстрактный класс может быть интерфейсом, наоборот я напротив говорил что не может быть. ![]() Что конкретно вас смутило? Пример абстрактного класса, который выступает в роли интерфейса я приводил, вы с чемто не согласны? |
|
Сообщ.
#4604
,
|
|
|
|
Цитата D_KEY @ Подразумевался где? Пихающий в любом случае должен знать что он пихает и куда, иначе ему лучше ничего никуда пихать Подразумевался при создании класса. Таки интерфейс подразумевает не просто сигнатуры, но еще и область его применения. А по второму возражению см. закон Мерфи ![]() Опять же: не вижу я причин не указывать интерфейс в объявлении класса. Это не мешает. Добавлено Цитата scorpion @ Цитата (Romkin @ Сегодня, 16:45) Цитата Я говорил что абстрактный класс может быть интерфейсом, наоборот я напротив говорил что не может быть. Что конкретно вас смутило? Пример абстрактного класса, который выступает в роли интерфейса я приводил, вы с чемто не согласны? Я долго пытался понять фразу Добавлено Цитата scorpion @ Вот давай, спросим у присутствующих, пишуших на C#. Когда лучше использовать интефрейс, а когда лучше использовать абстрактный класс в рамках именно C# ? Вот, от MS: Recommendations for Abstract Classes vs. Interfaces Цитата Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components. If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface. If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes. If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class. If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members. |
|
Сообщ.
#4605
,
|
|
|
|
Цитата Romkin @ Я долго пытался понять фразу ![]() Смысл фразы состоит в том, что в С++, с помощью абстрактных классов, я могу сделать некую сущность, которая будет удовлетворять концепции интерфейсов. |