Примеры классов в программировании?

На хабре была замечательная статья по этому поводу. В кратце, все эти 4 паттерна спокойно реализуются вообще без капли ООП и не являются необходимыми для реализации ООП (как и понятие "класс", см прототипное ООП).
habrahabr.ru/post/147927

@bromzh: ООП это и есть совокупность паттернов. Да, их можно реализовать без непосредственной поддержки в языке, хоть на машинных кодах. Иногда так и делают, когда пишут, например, на чистом C.

@bromzh: "все эти 4 паттерна ... не являются необходимыми для реализации ООП"

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

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

@cjey:
Вы не можете реализовать ООП без любого из этих паттернов.
Очень смешно. Ты видимо прочитал про эти паттерны, но не разобрался, что есть что. Давай по пунктам:

Инкапсуляция. Проверка прав доступа данных на уровне языка. Нельзя случайно испортить чужую переменную.
В питоне есть ООП, но инкапсуляции нет. Нет там private-полей. По твоей логике, в питоне нет ООП. В javascript тоже нет инкапсуляции в явном виде, она там реализуется замыканиями. Да и вообще, в любом языке с поддержкой замыканий можно очень легко ограничивать уровни видимости переменных. Кроме того, сеттеры и геттеры нарушают инкапсуляцию. А с помощью рефлексии в яве и шарпах можно получить доступ к private полям напрямую. Именно поэтому в питоне отказались от инкапсуляции: вся ответственность лежит на программисте, он сам решает, менять какое-то поле или нет. И дискомфорта не ощущается.

Наследование. Можно породить сущность на основе уже существующей, немного ее изменив.
В javascript нет наследования (в обычном понимании). Там есть делегирование. Да, часто пишут "наследование через прототип", но это не правда. Во-первых, статические поля не наследуются, во-вторых, экземпляр потомка добавляет свои методы и к родителю:

function Foo() {};
Foo.prototype.foo = function() {}
var foo = new Foo();
function Bar() {};
Bar.prototype = Foo.prototype;
Bar.prototype.bar = function() {}
foo.bar // да, метод из дочернего "класса" Bar добавится ко всем "экземплярам" "класса" Foo.

Да, эту проблему можно обойти, если каждый раз создавать новый объект-родитель:
Bar.prototype = new Foo();
Хотя и в таком случае все методы попадут в родитель, просто родитель нигде не используется. К тому же, ещё и вызовется функция-конструктор Foo, что не всегда желательно. Естественно, что это можно обойти. Но в любом случае, делегирование - это не одно и тоже, что наследование. Однако, ООП в javascript есть (но. видимо, не для тебя).

Абстракция. Можно работать с объектами как с черным ящиком, не задумываясь как оно устроено внутри.
Каким боком это относится к ООП? Абстракция есть в любом языке. Я могу написать функцию, решающую уравнения. Как я реализую это: методом простой итерации, методом Ньютона или ещё как-нибудь, конечному пользователю не важно, он использует мою функцию как чёрный ящик: не вход подаёт функцию, на выходе ожидает значение. При этом тоже можно не задумываться о внутреннем устройстве.

Полиморфизм. Можно работать с группой разных сущностный через общий интерфейс.
Полиформизм - понятие теории типов. Таким образом, в любом языке с типами есть полиформизм. При этом, в таких языках, как хаскель и скала, он "более крут" (да к тому же ещё и типобезопасен!), нежели в обычных ООП, типа явы или плюсов.

Что в итоге? Из 4-х пунктов, 2 есть во всех высокоуровневых языках, 2 пункта могут и не реализовываться языком, но при этом такой язык будет поддерживать полноценное ООП (js, например).
Кроме того, язык может поддерживать одновременно все эти 4 пункта, но поддерживать ООП (хаскель, например).
И да, понятие класс вводится для удобства. Если есть смысл использовать ОО-подход, то лучше взять язык с поддержкой ООП, нежели писать всё самому. Но и пихать ООП везде тоже неправильно. Однако, ни понятие "класс", ни один из 4-х пунктов не является ни необходимым ни достаточным условием для того, чтобы язык имел поддержку ООП.

@bromzh:
Мы потеряли нить дискуссии. Не стоит объединять мой ответ на вопрос и мой комментарий вам, это два разрозненных утверждения на разные вопросы.

Как я услышал исходный вопрос:
Зачем вообще придумали эти сложности с классами, почему нельзя писать в модульной парадигме.
Что я хотел сказать ответе:
* Понятие класс добавлено в язык для удобства написание программ с объектно-ориентированной подходом.
* У всех парадигм есть плюсы и минусы.
* А далее я описал некоторые плюсы которые мы получаем используя ОО подход в сравнении модульным подходом сгруппировав их по принципам ОО подхода. Это не принципы ООП. Это те плюсы которые мы получаем используя этот принцип.

@bromzh:
На ваше утверждение: "все эти 4 паттерна ... не являются необходимыми для реализации ООП"
Я делаю свое утверждение: "Вы не можете реализовать ООП без любого из этих паттернов."

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

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

Например вы нарушаете абстракцию и в одном объекте храните данные сразу множества разрозненных сущностей. Опять же будет работать, но это не объектно ориентированный подход.

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