Почему заявление, что c# люди не получают объектно-ориентированное программирование? (по сравнению с ориентированным на класс)

Существует три столба ООП

1. Инкапсуляция
2. Наследование
3. Полиморфизм

, Если язык может сделать те три вещи, это - язык ООП.

я вполне уверен, аргумент языка X делает ООП лучше, чем язык A продолжится навсегда.

IMO, это действительно чрезмерно определяет "объектно-ориентированный", но к чему они обращаются, то, что Ruby, в отличие от C#, C++, Java, и др., не использует определение класс - Вы действительно только когда-либо работаете непосредственно с объектами. С другой стороны, в C#, например, Вы определяете классы , что Вы затем должны инстанцировать в объект посредством нового ключевого слова. Так как ключевой пункт - Вы, должен объявлять класс в C# или описывать это. Кроме того, в Ruby, все - четные числа, например - является объектом. Напротив, C# все еще сохраняет понятие типа объекта и типа значения. Это на самом деле, я думаю, иллюстрирует мнение, которое они высказывают о C# и других подобных языках - объект тип и оценивают , тип подразумевает система типа , означая, что у Вас есть вся система описание типы в противоположность просто работе с объектами.

Концептуально, я думаю, что дизайн OO - то, что обеспечивает абстракцию для использования для контакта сложности с программными системами в эти дни. Язык является использованием инструмента для реализации дизайна OO - некоторые делают его более естественным, чем другие. Я все еще утверждал бы, что из более общего и более широкого определения, C# и другие все еще объектно-ориентированы языки.

OO иногда определяется как , сообщение ориентировалось . Идея состоит в том, что вызов метода (или доступ свойства) является действительно сообщением, отправленным в другой объект. То, как объект recieveing обрабатывает сообщение, полностью инкапсулируется. Часто сообщение соответствует методу, который затем выполняется, но это - просто деталь реализации. Можно, например, создать всеобъемлющий обработчик, который выполняется независимо от имени метода в сообщении.

Статическое OO как в C# не имеет этого вида инкапсуляции. Массаж имеет для соответствия существующему методу или свойству, иначе компилятор будет жаловаться. Динамические языки как Smalltalk, Ruby или Python действительно однако поддерживает "основанное на сообщении" OO.

, Таким образом, в этом смысле C# и другими языками OO со статическим контролем типов не является истинное OO, синус thay испытывают недостаток в "истинной" инкапсуляции.

Обновление: это - новая волна.. которые предлагают все, что мы делали, до настоящего времени passe.. Кажется, поддерживает вполне немного в подкастах и книгах.. Возможно, это - то, что Вы слышали.

До настоящего времени мы были обеспокоены статическими классами, а не развязал питание объектно-ориентированной разработки. Мы делали 'класс базирующийся dev'. Классы являются фиксированными/статичными шаблонами для создания объектов. Все объекты класса создаются равные.

, например, Только проиллюстрировать, о чем я был болтлив... позволенный меня, одалживают отрывок кода Ruby у скринкаста PragProg, у меня просто было полномочие наблюдения. 'Основанная на прототипе разработка' стирает грань между объектами и классами.. нет никакого различия.

animal = Object.new                  # create a new instance of base Object

def animal.number_of_feet=(feet)     # adding new methods to an Object instance. What?
  @number_of_feet = feet
end
def animal.number_of_feet
  @number_of_feet
end

cat = animal.clone          #inherits 'number_of_feet' behavior from animal
cat.number_of_feet = 4

felix = cat.clone           #inherits state of '4' and behavior from cat
puts felix.number_of_feet   # outputs 4

идея, являющаяся, это - более мощный способ наследовать состояние и поведение, чем традиционное основанное на классе наследование. Это дает Вам больше гибкости и управления в определенных "специальных" сценариях (что я должен все же понять). Это позволяет вещи как Соединение-ins (ре с помощью поведения без наследования классов)..

Путем оспаривания основным примитивам того, как мы думаем о проблемах, 'истинное ООП' похоже 'на Матрицу' способом... Вы продолжаете идти WTF в цикле. Как этот.. где базовым классом Контейнера может быть или Массив или Хеш, на основе которой стороны 0,5 сгенерированное случайное число.

class Container < (rand < 0.5 ? Array : Hash)
end

Ruby, JavaScript и новая бригада, кажется, те ведущие это. Я все еще отсутствую на этом... читающем и пытающийся понять это новое явление. Кажется, мощен.. слишком мощный.. Полезный? Мне нужны мои глаза, открытые немного больше. Интересные времена.. они.

Я только слушал первые 6-7 минут подкаста, который зажег Ваш вопрос. Если их намерение состоит в том, чтобы сказать, что C# не является чисто объектно-ориентированным языком, это на самом деле корректно. Все в C# не объект (по крайней мере, примитивы не, хотя упаковка создает объект, содержащий то же значение). В Ruby все - объект. Daren и Ben, кажется, покрыли все основания в их обсуждении "ввода утки", таким образом, я не повторю его.

, Материально ли это различие (все объект по сравнению со всем не объект)/значительно, вопрос, на который я не могу с готовностью ответить, потому что у меня нет достаточной глубины в Ruby для сравнения его с C#. Те из Вас, кто на здесь, кто знает Smalltalk (я не делаю, хотя мне жаль, что я не делал), вероятно, смотрел на перемещение Ruby с некоторым развлечением, так как это был первый чистый язык OO 30 лет назад.

Возможно, они ссылаются на различие между утиным вводом и иерархиями классов?

, если это идет как утка и шарлатаны как утка, просто притворитесь, что это - утка, и ударьте его.

В C#, Java и т.д. компилятор раздражает много чрезмерной заботой: Вам разрешают сделать эту операцию на том объекте?

Объектно-ориентированный по сравнению с Ориентированным Классом мог поэтому означать: язык волнуется об объектах или классах?

, Например: В Python, для реализации повторяемого объекта только необходимо предоставить метод __iter__(), который возвращает объект, который имеет метод, названный next(). Вот и все: Никакая интерфейсная реализация (нет такой вещи). Никакое разделение на подклассы. Просто говоря как утка / итератор.

РЕДАКТИРОВАНИЕ: Это сообщение было upvoted, в то время как я переписал все. Извините, никогда не будет делать этого снова. Исходное содержание включало совет выучить как можно больше языков и к беспокойству не о том, что врачи языка думают / говорят о языке.

Это действительно, вероятно, переходит к тому, что эти люди видят, что другие делают в c# и Java в противоположность c# и ООП поддержки Java. Большая часть тростника языков использоваться в различных парадигмах программирования. Например, можно написать процессуальный код в c# и схему, и можно сделать программирование функционального стиля в Java. Это больше, о каком Вы пытаетесь сделать и что поддерживает язык.

Я попробую это.

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

Успешное внедрение зависимости зависит от на наличии довольно хорошей объектной модели. Эти два являются видом двух сторон той же монеты. Если Вы действительно понимаете, как использовать ООП, то необходимо по умолчанию создать проекты, где зависимости могут быть легко введены.

, поскольку внедрение зависимости легче на динамически типизированных языках, разработчики Ruby/Python чувствуют, что их язык понимает уроки OO намного лучше, чем другие дубликаты со статическим контролем типов.

Это было абстрактным подкастом действительно!
, Но я вижу то, что они достигают - они просто ослепленный Блеском Ruby. Ruby позволяет Вам делать вещи, о которых программисты на базе С и программисты Java даже не думали бы +, комбинации тех вещей позволяют Вам достигнуть не мечтавший о возможностях. Добавление новых методов к встроенному Строковому классу, потому что Вы чувствуете себя подобно ему, раздавая блоки кода без имени для других для выполнения, mixins... Стандартные люди не привыкли к объектам, изменяющимся слишком далекий от шаблона класса. Это - совершенно новый мир там наверняка..

Что касается парней C#, не являющихся OO достаточно..., не принимают его близко к сердцу.. Просто возьмите его в качестве материала, который Вы говорите, когда Вы изумлены для слов. Ruby делает это большинству людей.
, Если я должен был рекомендовать одному языку для людей учиться в текущее десятилетие.. это был бы Ruby. Я рад, что сделал.. Хотя некоторые люди могут требовать Python. Но как мое мнение.. человек! :D

Я не думаю, что это конкретно об утином вводе. Например, поддержки C# уже ограничили ввод утки - пример будет то, что можно использовать foreach на любой класс, который реализует MoveNext и Текущий.

понятие ввода утки совместимо со статически типизированными языками как Java и C#, это - в основном расширение отражения.

Это действительно имеет место помех по сравнению с динамическим контролем типов. Оба - надлежащее OO, в так же, как существует такая вещь. За пределами академии это действительно не стоит обсудить.

Мусорный код может быть написан в также. Большой код может быть написан в также. Нет абсолютно ничего функционального, которое может сделать одна модель, это другой не может.

реальная разница находится в природе сделанного кодирования. Статические типы уменьшают свободу, но преимущество состоит в том, что все знают то, с чем они имеют дело. Возможность изменить экземпляры на лету очень мощна, но стоимость - то, что становится трудно знать то, с чем Вы являетесь deaing.

, Например, для Java или C# intellisense легко - IDE может быстро произвести список отбрасывания возможностей. Для JavaScript или Ruby это становится намного более твердым.

Для определенных вещей, например, производя API, с которым кто-то еще кодирует, существует реальное преимущество в статическом контроле типов. Для других, например, быстро производя прототипы, преимущество переходит к динамическому.

стоит иметь понимание обоих на Вашей панели инструментов навыков, но нигде рядом столь же важный как понимание того, которое Вы уже используете в реальной глубине.

В объектно-ориентированном языке объекты определяются путем определения объектов, а не классов, хотя классы могут предоставлять некоторые полезные шаблоны для конкретных Определения данной абстракции. В языке, ориентированном на классы, как, например, C #, объекты должны быть определены классами, и эти шаблоны обычно консервируются и упаковываются и становятся неизменяемыми до времени выполнения. Это произвольное ограничение, заключающееся в том, что объекты должны быть определены до времени выполнения и что определения объектов являются неизменяемыми, не является объектно-ориентированной концепцией; он ориентирован на класс.

хотя классы могут предоставлять некоторые полезные шаблоны для конкретных определений данной абстракции. В языке, ориентированном на классы, как, например, C #, объекты должны быть определены классами, и эти шаблоны обычно консервируются и упаковываются и становятся неизменяемыми до времени выполнения. Это произвольное ограничение, заключающееся в том, что объекты должны быть определены до времени выполнения и что определения объектов являются неизменяемыми, не является объектно-ориентированной концепцией; он ориентирован на класс.

хотя классы могут предоставлять некоторые полезные шаблоны для конкретных определений данной абстракции. В языке, ориентированном на классы, как, например, C #, объекты должны быть определены классами, и эти шаблоны обычно консервируются и упаковываются и становятся неизменяемыми до времени выполнения. Это произвольное ограничение, заключающееся в том, что объекты должны быть определены до времени выполнения и что определения объектов являются неизменяемыми, не является объектно-ориентированной концепцией; он ориентирован на класс.

Это произвольное ограничение, заключающееся в том, что объекты должны быть определены до времени выполнения и что определения объектов являются неизменяемыми, не является объектно-ориентированной концепцией; он ориентирован на класс.

Это произвольное ограничение, заключающееся в том, что объекты должны быть определены до времени выполнения и что определения объектов являются неизменяемыми, не является объектно-ориентированной концепцией; он ориентирован на класс.

Объектно-ориентированный подход - это концепция. Эта концепция основана на определенных идеях. Технические названия этих идей (на самом деле, скорее, принципы, которые развивались с течением времени и отсутствовали с первого часа) уже были даны выше, я не буду их повторять. Скорее, я объясняю это настолько просто и нетехническо, насколько могу.

Идея объектно-ориентированного программирования состоит в том, что существуют объекты. Объекты - это небольшие независимые сущности. Эти объекты могут иметь встроенную информацию, а могут и не иметь. Если у них есть такая информация, только сама организация может получить к ней доступ или изменить. Сущности общаются друг с другом, отправляя сообщения друг другу. Сравните это с людьми. Люди - это независимые сущности, у которых в мозгу хранятся внутренние данные, и они взаимодействуют друг с другом посредством общения (например, говорить друг с другом). Если вам нужны знания из чужого мозга, вы не можете напрямую получить к ним доступ, вы должны задать ему вопрос, и он может ответить вам на него, рассказав вам то, что вы хотели знать.

И это в основном все. Это реальная идея объектно-ориентированного программирования. Записывая эти сущности, определите связь между ними и заставьте их взаимодействовать вместе, чтобы сформировать приложение. Это понятие не привязано ни к какому языку. Это просто концепция, и если вы пишете код на C #, Java или Ruby, это не важно. После некоторой дополнительной работы эта концепция может быть реализована даже на чистом C, хотя это функциональный язык, но он предлагает все необходимое для этой концепции.

В настоящее время различные языки приняли эту концепцию объектно-ориентированного программирования, и, конечно же, концепции не всегда равны. Например, некоторые языки позволяют то, что запрещено другими языками. Теперь одна из задействованных концепций - это концепция классов. У некоторых языков есть классы, у некоторых нет. Класс - это схема того, как выглядит объект. Он определяет внутреннее хранилище данных объекта, он определяет сообщения, которые объект может понять, и, если существует наследование (которое не является обязательным для объектно-ориентированного программирования!), Классы также определяют, из какого другого класса (или классов) если разрешено множественное наследование) этот класс наследует (и какие свойства, если существует выборочное наследование). После того, как вы создали такую ​​схему, вы можете теперь сгенерировать неограниченное количество объектов, построенных в соответствии с этой схемой.

Однако есть ОО-языки, у которых нет классов. Как тогда строятся объекты? Ну обычно динамично. Например вы можете создать новый пустой объект, а затем динамически добавлять к нему внутреннюю структуру, такую ​​как переменные экземпляра или методы (сообщения). Или вы можете продублировать уже существующий объект со всеми его свойствами, а затем изменить его. Или, возможно, объединить два объекта в новый. В отличие от языков, основанных на классах, эти языки очень динамичны, поскольку вы можете динамически генерировать объекты во время выполнения способами, о которых даже разработчик не подумал, когда начинал писать код.

Обычно эта динамика имеет свою цену: чем динамичнее язык чем больше памяти (RAM) объекты будут тратить впустую и тем медленнее все будет работать, поскольку поток программы также чрезвычайно динамичен, и компилятору сложно сгенерировать эффективный код, если у него нет возможности предсказать код или поток данных. Компиляторы JIT могут оптимизировать некоторые части этого во время выполнения, однако, как только они узнают поток программы, поскольку эти языки настолько динамичны, поток программы может измениться в любое время, вынуждая JIT отбрасывать все результаты компиляции и повторно компилировать один и тот же код снова и снова.

Но это так. крошечная деталь реализации - она ​​не имеет ничего общего с основным принципом объектно-ориентированного программирования. Нигде не сказано, что объекты должны быть динамическими или изменяемыми во время выполнения. В Википедии об этом довольно хорошо сказано:

Методы программирования могут включать Нигде не сказано, что объекты должны быть динамическими или изменяемыми во время выполнения. В Википедии об этом довольно хорошо сказано:

Методы программирования могут включать Нигде не сказано, что объекты должны быть динамическими или изменяемыми во время выполнения. В Википедии об этом довольно хорошо сказано:

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

http://en.wikipedia.org/wiki/Object-oriated_programming

Они могут или они не могут . Все это не обязательно. Обязательным является только наличие объектов и то, что у них должны быть способы взаимодействия друг с другом (иначе объекты были бы бесполезны, если бы они не могли взаимодействовать друг с другом).

Вы спросили: "Может ли кто-нибудь показать мне пример удивительной вещи, которую я могу сделать с помощью ruby, но не могу сделать с помощью c#, и которая иллюстрирует этот другой подход oop?"

Одним из хороших примеров является active record, ORM, встроенный в rails. Классы моделей динамически создаются во время выполнения, основываясь на схеме базы данных.