воскресенье, 15 ноября 2015 г.

Светлые идеи ООП

Введение


Мой друг объясняет это так. Когда заводят двигатель в машине, то поворачивают ключ. Никто же не лезет под капот и не замыкает провода в ручную?
Классы (а подход программирования, связанный с их созданием и активным использованием называется объектно-ориентированным программированием или ООП) сделаны для того, чтобы во время будущей разработки программисту было проще.
Например, нужно написать математическую программу (вот эта задача актуальна -- хороших мало), и программисты отдельно пишут классы для матриц, всяких хитрых чисел и прочего.
И с этими очень сложными классами работает очень простая (правда, по сравнению с кодом классов) функция или опять же класс.
Вообще слово «класс» - хреновое, в компьютерном английском оно значит то что надо, а в русском - непонятно дерьмо. Лучше бы называть это «объект», но всем как всегда... пофиг.
Представим, что мы инженер. И у нас есть класс - машина. Что мы можем позволить делать пользователю? Завести машину, залить топливо, воду, масло, еще чего-нибудь, сесть в неё, поехать, погрузить вещи, тещу. Это все «публичные функции» - то, что мы разрешаем делать всем с нашим объектом (классом) - «машина». Еще мы можем публично распространять данные о машине - марку, цвет, объем бака - это «публичные данные».
А то, что пользователю делать нельзя, нужно самой машине. К примеру, цикл простейшего двигателя внутреннего сгорания состоит из нескольких фаз: подача топлива, сжатие поршнем до возгорания, использование полученной энергии и выпуск газов. Вот такие функции называются «приватными», пользователю их вызывать не нужно.
class car{ //класс "автомобиль"
  int key;
public:
  car(string wanted); //конструктор
  ~car(); //деструктор

  string type; //тип машины
  string tank_volume; //объем бака
  bool start(int key); //завести
  void fuel(int volume); //заправить
  void drive(); //вести машину
};

Теперь, если мы захотим использовать наш автомобиль, надо будет создать автомобиль, сесть в него и поехать.
car first_car;
fisrt_car.start(1337);
fisrt_car.drive();

Конструктор и деструктор

Когда ты пишешь int a=48 компьютер из своих 4 Гб (или сколько там у тебя ОЗУ, %username%) выделяет место для хранения числа 48 (может быть 2 байта).
Когда ты пишешь класс, тебе тоже нужно место, где можно хранить свои данные. Для этого и создан конструктор. Чтобы выделить память под новое значение и туда еще может быть чего-нибудь записать.
У тебя 4 Гб памяти у компа. но на одну програму по умолчанию дается далеко не 4 Гб. И даже не 512 Мб. а что-то около 20 Мб. А если ты будешь создавать много-много объектов, то памяти начнет занимать все больше... и это грозит тем, что программа забъет всю отведенную ей память данными, которые ей быть может и не нужны.
Для этого и нужен деструктор - чтобы удалять уже ненужный хлам.
Замечание! В некоторых языка есть система, которая сама удаляет из памяти ненужные данные и работает сама по себе. называется она «уборкой мусора», правда о её эффективности ходят слухи и шутки.... Например, если бы в Java нормально работала уборка мусора, то она бы выкинула в корзину саму себя.
Конструктор и деструктор у разных классов могут быть внешне похожи, но работать совсем по разному.
car::car(string wanted){ //конструктор нашего автомобиля, хотя погодите-ка.. OH SHI
  type = wanted;
  key = generate_key(); //создаем ключ к автомобилю. считаем что такая функция есть
}
car::~car(){ //деструктор автомобиля
  delete(); //отправим его на переплавку
}

Перегрузка

Это понятие означает, что с разными данными мы работаем по разному, а называем эти действия одинаково. Разные действия выполняются при отправке электронного письма и отправке бумажного письма (кто-нибудь помнит о такой вещи?).

А теперь о грустном

Считается, что ООП увеличивает скорость разработки программ путем абстрагирования от конкретной реализации задачи, следовательно - решение меньшего числа подзадач, а посему - трата меньшего числа времени. А чем больше вы сделаете за меньший промежуток времени -- тем больше будет скорость. Но тут же появляется несколько проблем.
Электронно-вычислительная машина -- главная проблема. Да, ведь мы пишем программу для неё, а не для себя. Чем отдаленней исходный код от машины, тем больше труда приходится приложить компилятору (и программистам компилятора) или интерпретатору (о боже!) чтобы выполнить этот код. Таким образом, решение элементарных задач проходит через несколько слоёв абстракций (которые, возможно, и полезны при проектировании масштабных проектов), вместо того, чтобы сразу задействовать ресурсы вычислительный машины.
Компилятор (или интерпретатор). Как бы не были сложны и совершенны алгоритмы компиляторов (add eax, 0x1), они никогда не не сравнятся с силой человеческого ума, наличие которого безусловно повышает «уровень вхождения» в язык, избавляет от толп непрофессионалов-спекулянтов и переводит программирование из «ремесла» в искусство.
При написании объектно-ориентированного кода постоянно возникает следующая ситуация. Сначала разрабатывается и реализуется объектная модель применительно к задаче, затем необходимо спуститься на уровень ниже (методы класса) и реализовать его, а потом еще раз вернуться на объектный уровень.
Изобретенное ООП долго обходили стороной, но когда ЭВМ набрали мощности, псевдо-программисты прознали про перспективную область и ринулись туда породив «бум ООП», который не утихает до сих пор, разлагая умы начинающих программистов.

Комментариев нет:

Отправить комментарий