ООП для самых маленьких

oop-scheme1 Сегодня на мозг будем натягивать/насаждать всю концепцию ООП разом/целиком, а именно такие понятия как Наследование, Полиморфизм, Инкапсуляция и Абстракция данных, из которых и состоит сама концепция ООП (ака Объектно-ориентированное программирование) почти любого языка прграммирования.

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

С наступлением "притворного влияния загнивающего запада" и его активно развивающихся "вражеских" ИТ технологий, в нашем дремучем и брутальном славянском мэжик-пипл-вуду-пипл сообществе появилось множество всяких там заумных "буржуйских" словечек, типа: менеджер (манагер, manager - ака просто управляющий), курьер (фр. courrier - ака посыльный, ходок, шнырь) и т.п. - от которых у самых (dummy) маленьких (много думающих:) часто возникает масса вопросов и недоумений.

Прим. ред.: "Таких мужиков как он почти не осталось. Они все переквалифицировались в артистов, дизайнеров и программистов, - побрили подмышки и аста-ла-виста...". Исполнитель "Джин-Тоник - Водитель КАМАЗа".

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

Для облегчения понимания ООП (ака Объектно-ориентированное программирование) для самых маленьких расшифруем ключевые его составляющие понятия:

  • Концепция ООП - ака система понятий, в которую входят дочерние понятия Объект, Наследование, Полиморфизм, Инкапсуляция и Абстракция данных;
  • Наследование - наследовать двушку в центре от усопшей бабушки. Многие стремятся не заработать что-то, а унаследовать;
  • Полиморфизм - многообразный, разнообразный, универсальный. Все работодатели хотят заполучить полиморфных (универсальных) рабочих - т.е. если устраиваешься водилой КамАЗа, то в твои обязанности будет входить не только его вождение, ты ещё должен будешь быть автослесарем, грузчиком, мойщиком, экспедитором, инкассатором, и, ещё чёрт знает кем.., короче полиморфным (универсальным) водилой;
  • Инкапсуляция - изолирование, например моего/твоего кореша инкапсулировали в колонии строгого режима;
  • Абстракция - отделение, например закинулся галаперидолом, курнул или зелья какого выпил и на пару часов/суток получил абстракцию сознания от окружающего мира.

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

kalyan-kreativ

Концепция ООП и Инкапсуляция

Пупом в системе понятий (ака концепция) является Объект, без наличия которого ООП не ООП вовсе, - имхо программирование то Объектно-то ориентированное. Объект же получается при создании экземпляра класса (в PHP например ака $myObj = new MyClass();), а когда у нас есть объект, то он автоматически выполняет сокрытие/изолирование (ака Инкапсуляция) данных от остальных частей программы до тех пор, пока они не будут извлечены из объекта и не будут переданы другому объекту или программе.

Наследование в ООП

Что же касается наследования двушки в центре от усопшей бабушки, то здесь проблем никаких нет, - а нет, как нет проблем и у наследования классом свойств и методов другого класса. На примере того же РНР делается так:

<?php
// Снимаем комментарий ели нужно отображать все ошибки
ini_set('display_errors', 'On'); error_reporting(E_ALL);
 
class MyClass extends ArrayObject {
    // здесь наш полиморфный говнокод
 
    public function whoAmI() {
        return __METHOD__;
    }
 
    public static function print_data($data) {
        if (is_array($data)||is_object($data)) {
            echo '<pre>';
            print_r($data);
            echo '</pre>';
        } else {
            echo $data;
        }
    }
 
}
 
$testObj = new ArrayObject();
 
MyClass::print_data($testObj);

Здесь мы пополнили/расширили/унаследовали свой класс MyClass уже не "двушкой" усопшей бабушки, а глобальным классом ArrayObject и теперь в нашем классе/объекте MyClass будут доступны все свойства и методы класса в зависимости конечно от того, какая определена им видимость (global, static, public, protected, private).

К сожалению в РНР, в отличии от иных языков программирования, не поддерживается множественное наследование классов ака "class MyClass extends MyClass1, MyClass2, MyClass3", - на момент написания сего эпоса в РНР множественное наследование возможно только для интерфейсов (ака class MyClass extends MyClass1 implements Interface1, Interface2, Interface3).

Полиморфизм в ООП

Методы класса MyClass, whoAmI и print_data, получились очень даже полиморфненькими (универсальненькими), - первая выдаёт название используемого класса и метода, а вторая распечатывает на экран данные независимо от их типа.

Обратите внимание на то, что одна функция/метод (whoAmI) обычная, а вторая (print_data) статическая (static) - print_data мы без проблем вызвали статически (т.е. без создания объекта), а при вызове второй таким же образом мы получим ошибку "Strict Standards: Non-static method MyClass::whoAmI() should not be called statically in ...".

Статические методы экономят РАМу и как следствие способствуют повышению производительности, но в таком случае мы будем не полными ООП программильщиками имхо, как мы помним, пупом концепции ООП является объект, а при использовании статических классов/методов создавать объект нет надобности;)

Абстракция в ООП

Обычно, когда говорят "Абстракция" автоматом подразумевается "абстрактный класс". "Абстрактный класс" по сути не представляет из себя никакой практической пользы, - т.е. из него нельзя создать объект (экземпляр класса), к нему нельзя обратиться статическим путём. Полностью абстрактные классы называются "интерфейсами".

Цель "интерфейсов" (абстрактных классов) является определение того, что должно быть обязательно реализовано (implements). Поэтому не зря и слово implements подобрано, - в переводе означающее "реализует". Различие между "Абстрактным классом" и "Интерфейсом" в том, что абстрактный класс может содержать в себе как обычные, так и абстрактные методы. На примере того же РНР:

// абстрактный класс
abstract class AbClass1 {
    abstract function method1();
 
    static function method2(){
        //...
    }
}
 
// интерфейс
interface Interface1 {
    public function method1();
    public function method2();
}

Когда создаётся интерфейс, то отпадает необходимость писать слово abstract перед методами (функциями) имхо все методы в интерфейсе по-умолчанию считаются абстрактными. В абстрактных методах никогда не представляется их {//...кода...} реализация.

Нужно запомнить, что интерфейс, как и абстрактный класс, является по сути шаблоном без реализации {//...кода...} методов. Шаблоны (паттерны, интерфейсы) призваны для того, чтобы следовать их структуре.

MyClass implements Interface1 {
    // наш собственный независимый метод
    public static function method(){//...код...};
 
    // практическая реализация методов интерфейса Interface1
    public static function method1(){//...код...};
    public static function method2(){//...код...};
}

Создавая класс MyClass мы пожелали реализовать (implements) методы интерфейса (шаблона) Interface1, для чего мы обязаны переопределить method1 и method2 в нашем классе, а в противном случае получим ошибку.

Итоги

Как видим, всё познаётся в сравнении и ООП не является исключением.

Если с Концепцией ООП, Инкапсуляцией, Наследованием и Полимрфизмом всё более или менее определённо, то с понятием "Абстракция" и "Абстракция данных" не всё так однозначно...

Абстракция в ООП - это понятие довольно обширное и холиварное.

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

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

Абстракция же данных в ООП, в моём личном понимании, - выполняется приложением, которое построено по шаблону MVC (Model-view-controller, модель-представление-контроллер), где с момента получения запроса от пользовательской части идёт реальная абстракция данных, которые вначале поступают в контроллер (C, Controller), где после обработки некоторые из них передаются в модель (M, Model) делающую запросы в БД или производящую некоторые вычисления, снова возвращаются в контроллер и потов в представление/браузер (V, View) - таким образом некоторая часть наших данных абстрагировалась и зависла в БД, вторая пошла в кеш, иная в браузер пользователя, а остальная была сброшена вовсе.

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

  • Абстракция логики приложения - с использованием шаблонов (design pattern) проектирования (ака интерфейсы, абстрактные классы) и различных концепций типа MVC (модель, отображение, контроллер);
  • Абстракция данных - как результат работы приложения, в результате работы которого данные разбиваются (абстрагируются друг от друга) на части, которые имеют разное функциональное предназначение и свой персонал их обслуживающий (программист, веб-мастер). Т.е. абстракции данных без самого, уже готового, приложения происходить не может.

Также в корне неверным считаю утверждение, что (interface) интерфейсы могут в РНР решить проблему невозможности множественного наследования классов! ИМХО наследовать (extends) и реализовать (implements) являются такими же разными понятиями, как - без напряга "унаследовать двушку от усопшей бабули" чем расширить (extends) перечень своего имущества, и, пойти работать грузчиком, чтобы "заработать или построить (implements) её (двушку т.е.)".

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

govnocod-comics-1

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

Надеюсь в этой статье я на пальцах ответил на вопрос: "Что такое ООП? Прочитал википедрию - ни черта непонятно. Объясните мне на пальцах".


Добавить комментарий


Защитный код
Обновить

no-script
[ Подробнее... ]
27.25 megabytes