Можете пояснить принципы ООП?

Question

[safenoob]

Принципы из статьи: https://habrahabr.ru/post/140827/

5. Классы должны быть открыты для расширения, но закрыты для изменения.
Класс это не переменная, которая была 1 а стала 2. Как класс может измениться?

6. Взаимодействуйте только с близкими друзьями.
Что такое близки и дальние друзья, как отличить их друг от друга? Есть же MVC в которой чётко прописывается что контроллер взаимодействует с моделью (односторонне) а модель с видом (тоже односторонне). Так вот же они все друзья уже прописаны )

8. Класс (или метод) должен иметь только одну причину для изменения.
Тут вопрос как и в п.5 выше про изменения, но в описании фраза:
"Принцип указывает на то, что классу (как и методу) должна быть выделена только одна обязанность" - это понятно, класс должен делать только одно действие, но при чём тут изменение тогда?

Answer 1

[Арсений Ефремов]

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

Comments

[safenoob]

Я это понимаю. Я как раз и занимаюсь обучением правильной архитектуре приложений.

> не лезть в MVC без базового понимания этих принципов
Ну вот MVC у меня уже на носу так что надо чётко понять принципы как их не смешивать и вперёд

[Михаил]

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

[safenoob]

Михаил: Что толку много программировать на говнокоде? Так и по 5 лет некоторые программируют и потом ничего не знают... А в больших проектах особо ничего не понятно...

[Михаил]

safenoob: когда вы будете много программировать, у вас будут появляться проблемы, их решение вы и будете искать, вам будет понятно в чем именно эта проблема заключается и почему она решается вот так сложно и почему если делать проще, ничего не прокатит, потому что уже делали так сами и видите суть. Без опыта, никак. Попробуйте прочесть книгу, если уверены в своих силах.
"Объектно-ориентированное конструирование программных систем" Бертран Мейер
Если будет что-то не понятно, это говорит только об отсутствии опыта, этого самого говнокода, как вы пишете.

Answer 2

[jacksparrow]

Вы выбрали не лучшую статью по смыслу
5 . Класс имеется ввиду как сущность, а не экземпляр класса
6. Мутная формулировка малой зависимости от других классов
8. Опять непонятна формулировка . Ключевое - одна обязанность

А так читайте про grasp и solid

Answer 3

[Максим Тимофеев]

Странные формулировки, прочитайте еще 5 таких статей и придет понимание. а лучше параллельно пробуйте. Пробуйте и читайте.
Вот для примера:
https://megamozg.ru/post/6908/
https://megamozg.ru/post/6910/

Comments

[safenoob]

В статьях на мегамозге примеров как раз и нет ))

Answer 4

[newpy]

Какие то принципы в вашей статье странные, и больше запутывают. Пробуйте проще.

Фигуры. Эллипс, Круг, Квадрат, Ромб, Треугольник, Прямоугольник. Что их объединяет? Что отличает? У всех есть площадь, но у всех она разная, у Круга нет Сторон, но она есть у остальных. У Треугольника их три, у остальных четыре. У некоторых есть Периметр, у Круга длина окружности. Вычисляются периметры, площади, длина окружности по-разному. При этом все они относятся к фигурам. Какие из них мы можем расширить? Да все практически. Добавить им какие-то методы, например Треугольнику метод для вычисления биссектрисы, или угла. Но мы не можем сделать тоже самое для круга например. Более того мы не можем позволить экземпляру класса Прямоугольник менять или задавать стороны Треугольника. Т.к. у них разное количество сторон, и не можем по формуле вычисления площади ромба, вычислить площадь Круга. Зато мы можем еще расширить немного класс Треугольников. Например создать класс Равнобедренных треугольников и Равносторонних треугольников. И те и другие будут треугольниками, и те и другие еще и Фигурами. Но свойства Равнобедренного и Равностороннего будут несколько отличаться. Например тем, что Стороны равны, а еще Углы могут быть равны. А еще мы можем вообще создать Классы Угол и Сторона, наделить их свойствами, действиями и передавать их в наши Фигуры! Или например из двух Равнобедренных треугольников создать Ромб! Для этого мы можем расширить Ромб методом, который умеет создавать из двух только Равнобедренных треугольников Ромб. Тому же самому мы можем научить Квадрат! Можем создать еще Прямоугольный треугольник, и из двух прямоугольных составлять Прямоугольник! Мы можем "прятать" свойства наших фигур от посторонних глаз, и чтобы никто не смог изнутри взглянуть как вычисляется площадь, зато мы можем предоставить метод, чтобы сразу узнать площадь, мы можем попросить что-то взамен. Например передать нам для вычисления площади стороны, или угол и стороны. Мы можем запретить менять площадь нашей фигуры. Или запретить менять стороны. Чтобы мы всегда знали наши стороны, ведь если каждый будет их менять, то это будет хаос, кто-то неграмотный попадется, и Квадрату сделает разные стороны! Что тогда будет? Площадь и периметр тоже сломаются, сломается сам Квадрат. Вот и попробуйте объяснить себе ответы на ваши вопросы.

Краткий геометрический экскурс закончил. Пытайтесь представить себе все на примерах из жизни. Вокруг вас столько объектов. Автомобили, Люди, Животные и жЫвотные, сложно себе представить более простое понимание объектов.

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

(Предполагаю желающих сказать что можно и из человека сделать животное, и изменить цвет глаз и волос, но мы все таки о программировании и условно :) )

Comments

[safenoob]

Ответ достойный и с младенцем пример отличный, но можно как-то пример привести что в реальном проекте у нас "открыто к расширению, но закрыто к изменению"

[newpy]

реальный проект слабо чем отличается от того что я описал.

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

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

class A
{
    private $internalPrice; // скрытое свойство
    private $coefficient; // скрытое свойство
    public $externalPrice;

    private function getCoefficient() //скрытый метод
    {  
        return 10;
    }

    private function getInternalPrice()
    { 
        return $this->a;
    }
    
    public function getExternalPrice()
    {
        $coeff = $this->getCoefficient();
        $innerPrice = $this->getInternalPrice();
        $this->externalPrice = $innerPrice * $coeff;
        return $this->externalPrice;
    }
};

$foo = new A();
echo $foo->internalPrice; // фатальная ошибка, никто не сможет посмотреть внутреннюю цену 
или поменять так:
$foo->internalPrice = 28; // фатальная ошибка

echo $foo->coefficient; // фатальная ошибка, те же причины, свойство объявлено как приватное

// зато
echo $foo->getExternalPrice() // работает

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

public setCoefficient($coeff)
{
    $this->coefficient = $coeff;
}
// тогда 
$foo->setCoefficient(15); // никакой ошибки, но при попытке изменить напрямую
$foo->coefficient = 15; // по прежнему фатальная ошибка

// чем менять метод расчета внешней цены (повлечет за собой изменения везде), вы можете расширить класс и написать метод расчета цены для друзей:

public function getPriceForFriends()
{
     // например, так:
    $externalPrice = $this->getExternalPrice();
    return $externalPrice - 100;
    // в этом случае от посторонних глаз скрыто как именно происходит расчет скидки для друзей, и мы напрямую не меняем коэффициенты, внутреннюю цену, методы расчета.
    
}

Answer 5

[Владимир Олохтонов]

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

Начинайте с маленьких проектов и с опытом начнет приходить понимание базовых принципов. Другого пути нет.