Ruby и C # легко позволяют создавать методы доступа, указав методы получения / установки для атрибута, как в Python. Тем не менее, это не предназначено для того, чтобы естественно позволить вам написать код для этих методов в другом классе, как это позволяет Python. На практике я не уверен, насколько это важно, поскольку каждый раз, когда я видел атрибут, определенный в протоколе дескриптора, он реализовывался в одном и том же классе.
РЕДАКТИРОВАТЬ: штопать мою дислексию (под которой я имею в виду небрежное чтение). По какой-то причине я всегда читал «дескриптор» как «декоратор» и наоборот, даже когда я один печатал их обоих. Я оставлю свое сообщение без изменений, поскольку оно содержит действительную информацию, хотя и не имеет абсолютно никакого отношения к вопросу.
Сам термин «декоратор» фактически является названием шаблона дизайна, описанного в знаменитой книге «Шаблоны дизайна». Статья Википедии содержит много примеров на разных языках программирования использования декоратора: http://en.wikipedia.org/wiki/Decorator_pattern
Однако декораторы в этой статье объектно-ориентированы; у них есть классы, реализующие предопределенный интерфейс, который позволяет другому существующему классу вести себя как-то иначе и т. д. Декораторы Python действуют функционально, заменяя функцию во время выполнения другой функцией, позволяя эффективно изменять / заменять эту функцию, вставлять код и т. д.
Это известно в мире Java как Aspect-ориентированное программирование, и Java-компилятор AspectJ позволяет вам делать подобные вещи и компилировать ваш код AspectJ (который является надмножеством Java) в байт-код Java.
Я недостаточно знаком с C # или Ruby, чтобы знать, какой будет их версия декораторов.