В Ruby, что эквивалентно интерфейсу в C #?

Ruby имеет интерфейсы , как и любой другой язык.

Обратите внимание, что вы должны быть осторожны, чтобы не связать концепцию интерфейса , который является абстрактной спецификацией обязанностей, гарантий и протоколов единицы, с концепцией interface, которая является ключевое слово в языках программирования Java, C # и VB.NET. В Ruby мы все время используем первое, но второго просто не существует.

1169 Очень важно различать два. Важным является интерфейс , а не interface. interface говорит вам почти ничего полезного. Ничто не демонстрирует это лучше, чем маркерные интерфейсы в Java, которые являются интерфейсами, которые вообще не имеют членов: просто взгляните на java.io.Serializable и java.lang.Cloneable ; эти две interface означают очень разные вещи, но они имеют точно такую ​​же подпись.

Итак, если два interface, которые означают разные вещи, имеют одинаковую подпись, что точно является interface даже гарантирующим вам?

Другой хороший пример:

interface ICollection<T>: IEnumerable<T>, IEnumerable
{
    void Add(T item);
}

Что такое интерфейс из System.Collections.Generic.ICollection<T>.Add ?

• , что длина коллекции не уменьшается
• , что все предметы, которые были в коллекции прежде, все еще там
• , что item находится в коллекции

И какие из них на самом деле обнаруживаются в interface ? Никто! В interface нет ничего, что говорит о том, что метод Add должен даже добавлять вообще, он может удалить элемент из коллекции.

Это совершенно правильная реализация этого interface:

class MyCollection<T>: ICollection<T>
{
    void Add(T item)
    {
        Remove(item);
    }
}

Другой пример: где в java.util.Set<E> действительно сказано, что это, вы знаете, множество ? Нигде! Точнее, в документации. На английском.

Практически во всех случаях interfaces, как из Java, так и .NET, вся соответствующая информация фактически находится в документах, а не в типах. Итак, если типы не говорят вам ничего интересного, зачем вообще их хранить? Почему бы не придерживаться только документации? И это именно то, что делает Руби.

Обратите внимание, что есть другие языки, в которых интерфейс действительно может быть описан значимым образом. Однако эти языки обычно не называют конструкцию, которая описывает интерфейс , «interface», они называют ее type. В языке программирования с зависимой типизацией вы можете, например, выразить свойства, что функция sort возвращает коллекцию той же длины, что и оригинал, каждый элемент в оригинале также находится в отсортированной коллекции и не больше элемент появляется перед меньшим элементом.

Итак, вкратце: Ruby не имеет эквивалента Java interface. Он , однако, имеет эквивалент интерфейса Java , и он точно такой же, как в Java: документация.

Также, как и в Java, Acceptance Tests можно использовать для указания Interface s.

В частности, в Ruby интерфейс объекта определяется тем, что он может делать , а не тем, чем является class, или тем, что module он смешивает в К любому объекту, имеющему метод <<, можно добавить. Это очень полезно в модульных тестах, где вы можете просто передать Array или String вместо более сложного Logger, даже при том, что Array и Logger не разделяют явное interface отдельно от того, что у них обоих есть метод, названный <<.

Другим примером является StringIO , который реализует тот же интерфейс , что и IO и, таким образом, большую часть интерфейса из File, но без общего предка, кроме Object.

У Йорга есть хорошая точка зрения, у ruby ​​есть интерфейсы, но не ключевое слово. Читая некоторые ответы, я думаю, что это негатив в динамических языках. Вместо применения интерфейса через язык, вы должны создавать модульные тесты, вместо того, чтобы не реализовывать методы перехвата компилятора. Это также усложняет понимание метода понимания, так как вам приходится выслеживать, что такое объект, когда вы пытаетесь вызвать его.

Возьмите в качестве примера:

def my_func(options)
  ...
end

Если вы посмотрите на функцию, вы не будете иметь ни малейшего представления о том, что это за опции и какие методы или свойства следует вызывать без поиска юнит-тестов, В других местах это называется, и даже посмотрите на метод. Хуже того, метод может даже не использовать эти параметры, но передать его другим методам. Зачем писать модульные тесты, когда это должно было быть перехвачено компилятором. Проблема в том, что вы должны писать код по-другому, чтобы выразить этот недостаток в динамических языках.

Есть один плюс в этом, и это то, что динамические языки программирования БЫСТРЫ, чтобы написать кусок кода. Мне не нужно писать какое-либо объявление интерфейса, и позже я могу использовать новые методы и параметры, не обращаясь к интерфейсу, чтобы раскрыть его. Компромисс - скорость обслуживания.

Интерфейсы обычно вводятся в объектно-ориентированные языки со статической типизацией, чтобы восполнить отсутствие множественного наследования. Другими словами, они являются скорее необходимым злом, чем чем-то полезным как таковым .

Ruby, с другой стороны:

1. Это язык с динамической типизацией и «утиной типизацией», поэтому, если вы хотите вызвать метод foo для двух объектов, они не должны наследовать одно и то же. класс-предок, ни реализовать тот же интерфейс.
2. Поддерживает множественное наследование посредством концепции миксинов, опять же, здесь нет необходимости в интерфейсах.

У Руби их на самом деле нет; интерфейсы и контракты обычно живут больше в статическом мире, чем в динамическом.

Существует жемчужина под названием Handshake , которая может реализовывать неформальные контракты, если вам это действительно нужно.

Ruby использует концепцию модулей как замену (своего рода) для интерфейсов. Шаблоны проектирования в Ruby содержат множество действительно отличных примеров различий между этими двумя концепциями и того, почему Ruby выбирает более гибкую альтернативу интерфейсам.

http://www.amazon.com/Design-Patterns-Ruby-Russ-Olsen/dp/0321490452