Зачем нужен ООП?

Собственно сабж. Не понимаю зачем нужен ООП, пишу на php/python, часто сталкиваюсь с всяческими классами при работе с CMS/Фреймворками, но сам никогда не пишу никаких классов, т.к. совершенно не понимаю пользы. Разве что разграничивание пространства имен, в остальном получается только увеличение количества строк и ухудшение читабельности кода.
  • Вопрос задан
  • 23902 просмотра
Решения вопроса 1
EvilsInterrupt
@EvilsInterrupt
System programming, Reversing Engineering, C++
Не везде и не всегда нужны классы. Вы верно заметили. НО! Прежде чем принять решение о том, что в конкретном месте кода класс только вредит, нужен профайлер или другие инструменты позволяющие принять такое решение. К примеру в Python словарь значительно выигрывает по скорости чем класс с методами.

Фишка ООП в том, что человек уже думает классами! Поднимаем голову к небу и видим "Птица летит", другими словами "У объекта "Птица" был вызван метод "Лететь"", но мы так сложно не думаем и для нас это просто "Летящая птица".
Вспомните детство и моменты когда родители посылали за хлебом. Как это происходило? Возможно это было так: "Объект сын в твое поле ложу объект "Задача" с полями "хлеб", "комод" и "100 рублей", в поле "результат" ложу "Хлеб". Объект сын вызываю метод "Купить"". Не думаю что это было так, мне кажется это было так: "Сын возьми 100 рублей и купи хлеба". В неявном виде обратились к объекту "Сын", вызвали метод "Взять" и передали аргумент "100 рублей" и ожидаем результат вызова в виде значения "Хлеб".

Попробуйте процедурный подход переложить в нашу естественную жизнь? ;) Попробуйте так общаться, процедурно. Это очень сложно. Потому что человек привык думать объектами! Самолет, кошка, лошадь, дерево и др. Для нас вроде есть концепция "кошка", но конкретная кошка "Масяня" сильно отличается от другой конкретной кошки "Машка".

Изучая задачу мы прежде всего должны задать вопрос : "Что является условием завершения задачи?" и вторым не менее важным "Что используется при достижении результата?". Вот это "что используется" как правило и есть объекты.
Ответ написан
Пригласить эксперта
Ответы на вопрос 10
@dklokov
php developer
Был период когда точно как автор не понимал,а учил только потому что везде требовался. Осознание необходимости приходит, с ростом проектов, росте команды разработки. Есть проекты и работы, где вам в принципе не понадобится эти знания.
Ответ написан
ibnteo
@ibnteo
Чтобы добавить много лишних уровней абстракции, и потом лазить по мегабайтам кода, искать где что собирается для простой HTML странички. И чтобы сайты еле-еле работали, тормозили на мощных серверах даже при минимальной нагрузке, загружались не за долю секунды, а зачастую даже за десятки секунд. И всё это ради якобы красивого кода, повторяемости кода, в котором правда трудно разобраться, некому оценить его красоту и повторно использовать, ведь для этого нужно ещё и документацию писать, но никто этим заниматься не хочет.
Ответ написан
Комментировать
FanatPHP
@FanatPHP
Чебуратор тега РНР
Объект объективно функциональнее функции.
Если ты когда-нибудь использовал функции, ты обязательно сталкивался с их неудобствами - невозможностью вернуть больше одного результата, нагромождением параметров, невозможность работать с разным набором параметров и прочее.
Заменив же функцию на объект, все эти проблемы легко решить.
Если же ты функций не писал, то надо начать с них.
Ответ написан
@Mercury13
Программист на «си с крестами» и не только
Я хотел спросить: вы что, студент? Потом посмотрел: нет, вебист. Вебистам действительно ООП нужно крайне редко; если не связывался с хитрой поддержкой сложных протоколов или со сложными моделями данных — в памяти, не в БД — можно писать без ООП и быть успешным вебистом.

Я и сам долгое время не понимал, на что нужны эти объекты. Главный вопрос: ДЛЯ ЧЕГО?

Для того, чтобы передать взаимодействие кучи вещей. Где нет взаимодействия, там нет ООП, и можно заниматься, например, научными расчётами, на которые мало кто из нас способен, высший пилотаж, и вообще про ООП ничего не знать. Помню, как Вассерман — тот самый, некогда программист техпроцессов — долго-долго вспоминал, что такое ООП.

Предлагаю начать с простого.

1. Объектный синтаксис. Было…
iDog : integer;
iDog := SpawnMonster(world, mtDog, x, y);
ChargeAtPlayer(iDog);


Стало…
dog : TMonster;
dog := world.SpawnMonster(mtDog, x, y);
dog.ChargeAtPlayer;


Уже стало красивее. Да и номер собаки можно случайно передать, например, вместо номера оружия; с типом TMonster такой фокус не пройдёт.

2. Инкапсуляция.
Это мы уже думаем над тем, чтобы вызовы функций не могли привести объект в «ненадлежащее» состояние, а всё, что может объект подпортить,— засунуто в private.

3. Абстракция и наследование. Это уже «сложный пилотаж». Не высший — это неотъемлемая часть навыков хорошего программиста, да и для 80% задач это не нужно, зато в остальных 20-и очень улучшает жизнь. Самый простой пример. В какой-нибудь 2D-игре есть некий TGameObject, у которого виртуальные функции Live и Render. Первая прокручивает такт «жизни» объекта, вторая рисует его на экране. TGameObject можно разбить на TPlayer, TProjectile, TEnemy и TBonus, и т.д.

Ах да. Для ООП не нужен объектно-ориентированный язык и объектный синтаксис, нужно объектно-ориентированное мышление. Например, Doom был написан на Си, но в очень-очень объектном стиле.
Ответ написан
Комментировать
vt4a2h
@vt4a2h Куратор тега C++
Senior software engineer (C++/Qt/boost)
Вот вы говорите, что пользуетесь уже готовыми классами для решения каких-то задач... Прекрасно! А теперь попробуйте реализовать такую же функциональность, но без использования классов (и вообще ООП, т.к. это не только классы на самом то деле), а потом сравните код, который у вас получился с первичной ООП реализацией. Сравнивайте с точки зрения удобства использования, лёгкости сопровождения и восприятия другими разработчиками. Ещё можете сравнить с точки зрения тестирования и простоты добавления нового функционала.
Думаю, что сразу поймёте зачем нужен ООП.

PS
Хотя, тут возможен вариант, что вы ещё не сталкивались с задачами, которые необходимо (ок, удобно) решать с использованием ООП... Так заодно и столкнётесь)
Ответ написан
Комментировать
AxisPod
@AxisPod
Это методология проектирования и разработки. Хотите познать полноценно дзен, читайте Гради Буч "Объектно-ориентированный анализ и проектирование". Или просто забейте и делайте через ..., короче как делали.
Ответ написан
Комментировать
@KingpinRZN
гений миллиардер плейбой программист
Чтобы было удобнее писать.
Ответ написан
Комментировать
@sait4seo
по простому и на практике, например

1)вам нужно подключить платёжку к сайту
а)написать взаимодействие с нуля самому (дорого и не рентабельно)
б)взять готовый класс, если нужно отнаследовать и переписать некоторые методы (быстрее и надёжнее)

2)берёте какую-то библиотеку (или даже CMS), например библ. IdiORM, код ядра (ядро это основные классы) не меняете, а наследуете в свой класс переписываете несколько нужных методов, через 5-10 лет код вашего проекта не устареет, так как ядро можно будет обновлять не поломав проекта, да и все косяки и уязвимости за 10 лет для вас устранятся путём обновление библиотеки или cms

3)ОПП позволить разрабатывать быстрее, например на основе готовых библиотек и фреймворков вставка записи в таблиц может выглядеть так
$obj = new myTable();
$obj->name = 'Ivan';
$obj->phone = '111-111-111';
$obj->save(); 
//этот код нагляден и универсален для sql и  nosql баз и вообще любых хранилищ, не придётся переписывать проект целиком при смене базы

в функциональном стиле такого не реализовать

PS к сожалению не всё что реализовано на ООП, реализовано качественно. Есть примеры злоупотребления ООП и наоборот усложнения понимания кода, но это не значит, что не стоит пользоваться ООП подходом.
Ответ написан
Комментировать
@dom3d
Директор Дом-3D
Я 6 лет программировал на C d 1993-1999.
А потом перешел на C++ и жалел, что раньше не знал про существование языка C++.

Самые вкусности от языка С++ это наследование и виртуальные функции.
Кроме того, закрытые члены класса повышают надежность и предохраняют от ошибок.
Самое ужасное в программировании на языке C это использование глобальных переменных. Не знаешь, где она может измениться и слишком сложно менять поведение программы. А если ее изменение переменной сделать в одном месте (в классе), то очень легко модифицируется поведение класса.

Ну и конечно же очень удобно, когда методы работы с объектом (классом) хранятся в одном месте.
Ответ написан
Комментировать
@m-haritonov
В PHP ООП нужен, когда нескольким функциям требуется обращаться к общим переменным.

Без ООП пришлось бы писать код вида:
<?php
namespace something1 {
    function set($value) {
        $GLOBALS['something1']['someVariable'] = $value;
    }

    function get() {
        return $GLOBALS['something1']['someVariable'];
    }
}

namespace something2 {
    function set($value) {
        $GLOBALS['something2']['someVariable'] = $value;
    }

    function get() {
        return $GLOBALS['something2']['someVariable'];
    }
}

namespace {
    \something1\set(1);
    \something2\set(2);

    print \something1\get();
    print \something2\get();
}

и:
<?php
namespace something {
    function set($instanceName, $value) {
        $GLOBALS[$instanceName]['someVariable'] = $value;
    }

    function get($instanceName) {
        return $GLOBALS[$instanceName]['someVariable'];
    }
}

namespace {
    \something\set('instance1', 1);
    \something\set('instance2', 2);

    print \something\get('instance1');
    print \something\get('instance2');
}


С ООП можно написать:
<?php
class Something1 {
    private $someVariable;

    function set($value) {
        $this->someVariable = $value;
    }

    function get() {
        return $this->someVariable;
    }
}

class Something2 {
    private $someVariable;

    function set($value) {
        $this->someVariable = $value;
    }

    function get() {
        return $this->someVariable;
    }
}

$something1 = new Something1();
$something1->set(1);

$something2 = new Something2();
$something2->set(2);

print $something1->get();
print $something2->get();

и:
<?php
class Something {
    private $someVariable;

    function set($value) {
        $this->someVariable = $value;
    }

    function get() {
        return $this->someVariable;
    }
}

$something1 = new Something();
$something1->set(1);

$something2 = new Something();
$something2->set(2);

print $something1->get();
print $something2->get();


Если брать web приложение на php, задача которого состоит в том, чтобы сгенерировать html код (который будет отправлен браузеру) и предоставить возможность разделения приложения на модули, то ООП в качестве основы такого приложения может быть излишен, т.к. все модули будут выполнять лишь одно действие (возвращать html код) и им не потребуется сохнанять состояние между вызовами, т.к. результат работы модуля не будет больше изменяться во время вызова web приложения (модуль сгенерирует html и отправит его браузеру, а в браузере, где в javascript применяется ООП, этот html код уже будет изменяться во время работы).

Без ООП серверная часть web приложения может выглядеть так:
<?php
namespace modules {
    function layout($title, $contentHtml, $footerHtml) {
        return '<!doctype html>
            <html>
            <head>
                <meta charset="utf-8">
                <title>' . htmlspecialchars($title) .'</title>
            </head>
            <body>
                <div class="content">
                    ' . $contentHtml . '
                </div>

                <div class="footer">
                    ' . $footerHtml . '
                </div>
            </body>
            </html>
        ';
    }

    function contacts() {
        return 'Адрес: ..., телефон: ...';
    }

    function copyright() {
        return '© Моя фирма';
    }
}

namespace {
    if (strtok($_SERVER['REQUEST_URI'], '?') === '/contacts') {
        print \modules\layout('Контакты', \modules\contacts(), \modules\copyright());
    }
}

А с ООП так (как можно заметить, модули реализовалы в виде классов, которые содержат только 1 метод, т.е. класс здесь излишен):
<?php
namespace modules {
    class Layout {
        public $title;
        public $contentHtml;
        public $footerHtml;

        public function execute() {
            return '<!doctype html>
                <html>
                <head>
                    <meta charset="utf-8">
                    <title>' . htmlspecialchars($this->title) .'</title>
                </head>
                <body>
                    <div class="content">
                        ' . $this->contentHtml . '
                    </div>

                    <div class="footer">
                        ' . $this->footerHtml . '
                    </div>
                </body>
                </html>
            ';
        }
    }

    class Contacts {
        public function execute() {
            return 'Адрес: ..., телефон: ...';
        }
    }

    class Copyright {
        public function execute() {
            return '© Моя фирма';
        }
    }
}

namespace {
    if (strtok($_SERVER['REQUEST_URI'], '?') === '/contacts') {
        $layout = new \modules\Layout();
        $layout->title = 'Контакты';
        $layout->contentHtml = (new \modules\Contacts())->execute();
        $layout->footerHtml = (new \modules\Copyright())->execute();

        print $layout->execute();
    }
}


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

Войдите, чтобы написать ответ

Похожие вопросы