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

Question

[Urukhayy]

Собственно можете привести яркие примеры, зачем нужны классы? Чем не угодила многим обычная, модульная или процедурная конструкция? Я имею ввиду, чем переменная в классе "лучше" глобальной переменной? И как связан enum в C++ с классами?
Ведь можно обойтись без классов..

Answer 1

[aush]

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

Anton van Straaten

Без классов прекрасно можно обойтись. Более того, на примере разработки на объектно-ориентированном C# можно заметить, что если четко следовать принципам Single responsibility и Open/closed из SOLID, то код начинает сильно напоминать функциональный.

Тут нет такого, как лучше/хуже. Есть разные задачи, разные подходы и разные инструменты.

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

Comments

[Urukhayy]

То есть если с кодом работать будет лишь один человек, это снизит необходимость использования классов на какую-то долю?

[aush]

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

[Urukhayy]

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

[aush]

Если у вас есть глобальная переменная, то весь код, который работает с этой переменной - это один большой кусок кода и если вы работаете с какой-то его частью, то вам придется копаться во всех его частях. От того, что этот код у вас будет разбит по классам, инкапсуляция автомагически не появляется. Я потому и делаю акцент на том, что дело не в классах, замыканиях и т.п., а в инкапсуляции. Класс - один из инструментов обеспечения инкапсуляции, но это всего лишь инструмент.

Answer 2

[tsarevfs]

Когда программы становятся большими, очень хочется, чтобы при изменении одного куска не ломалось все остальное. Для этого программы разбиваются на части, взаимодействующие через некоторые интерфейсы. Чем этих связей меньше, тем проще поддерживать такой код.
Переменная(private) в классе лучше глобальной тем, что доступ к ней имеет только сам класс. В таком случае я могу при написании класса рассчитывать, что свои данные меняю только я, поэтому в каждый момент времени они непротиворечивы. Например класс Square описывает квадрат, у которого мы хотим задавать длину стороны и спрашивать его площадь.

class Square
{
  void setSide(double side)
  {
    side_ = side;
    area_ = side * side;
  }
  double getSide()
  {
    return side_;
  }
  double getArea()
  {
    return area_;
  }
private:
  double side_;
  double area_;
}

В процедурном варианте кто-то может изменить длину стороны и забыть (сам дурак, но если параметров не два а несколько десятков, помнить о всех закономерностях затруднительно) изменить площадь, в таком случае, он начнет получать неправильные результаты.
Еще прочитайте про наследование, оно используется очень часто.
Про enum можно не забивать голову пока.

Comments

[Дмитрий]

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

А с применением ключевого namespace Вам не грозит коллизия имен.

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

[tsarevfs]

В случае модуля у нас нет понятия экземпляр. Для моего примера понятно как работать с одним квадратом, если описать его как модуль. Работу с массивом квадратов уже необходимо поддерживать в самом модуле. А мы хотим использовать различные коллекции, то все сильно усложняется.
Обходится без наследования и полиморфизма конечно можно, но очень не хочется.

Answer 3

[Viktor Vsk]

Ассемблер - классная штука. Но жизнь коротка.

Answer 4

[cjey]

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

В вкратце плюсы ООП:
* Инкапсуляция. Проверка прав доступа данных на уровне языка. Нельзя случайно испортить чужую переменную. Объединение данных и методов работы с данными в одну сущность.
* Абстракция. Можно работать с объектами как с черным ящиком, не задумываясь как оно устроено внутри.
* Наследование. Можно породить сущность на основе уже существующей, немного ее изменив. Нет необходимости полного описания новой сущности, достаточно описать только различия.
* Полиморфизм. Можно работать с группой разных сущностный через общий интерфейс.

Comments

[bromzh]

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

[tsarevfs]

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

[cjey]

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

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

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

[bromzh]

@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-х пунктов не является ни необходимым ни достаточным условием для того, чтобы язык имел поддержку ООП.

[cjey]

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

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

[cjey]

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

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

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

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

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

Answer 5

[bromzh]

Да, можно реализовать все паттерны ООП без использования классов, объектов и других вещей. Но по-сути, ООП позволяет это делать наглядее и удобнее в некоторых случаях. Т.е. тебе не нужно реализовывать в своей программе всякие паттерны, это всё сделано в самом языке за тебя. ООП - это некая абстракция для работы с данными, как с объектами реального мира.

Просто есть области, где ООП наиболее лучше подходит для решения задачи. Есть области, где оно не будет оптимальным. Главное - это знать и понимать, где оно нужно, а где нет. Это уже с опытом приходит.

Answer 6

[Ринат Закирьянов]

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