Пытаюсь понять ООП, помогите спроектировать класс

[Страшный Злодей]

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

Для пробы хочу написать простенький скрипт автомобильного каталога. Допустим, каждый автомобиль имеет всего три свойства - "модель", "год выпуска" и "цена". Работа скрипта сводится к следующему: занесение автомобилей в базу, их редактирование и выборка по указанным выше критериям (свойствам автомобилей).

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

 

[fixxxer]

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

Вот тут описаны основополагающие принципы проектирования http://wiki.agiledev.ru/doku.php?id=ooad:principles

Понятно, что сходу ничего не понятно. Это сложно объяснить, понимание приходит с опытом.

 

[Страшный Злодей]

Дорогой fixxxer! Я действительно благодарен за внимание к моему вопросу, но должен констатировать, что даже несколько раз перечитав ваше сообщение и посетив указанную вами ссылку, смысл сказанного остаётся от меня скрытым наглухо Есть ли возможность объяснить более доступным языком? Возвращаясь к примеру, который я предложил в начале темы, какую бы структуру предложили вы?

 

[флоппик]

Допустим, каждый автомобиль имеет всего три свойства - "модель", "год выпуска" и "цена".

Вот эта фраза - правильное ООП сформулированное на русском языке. Есть некоторый объект — «автомобиль» который имеет три свойства, ага.

 

[Вурдалак]

Я где-то ещё видел интересную статью, где демонстрировалась своего рода «эволюция» от процедурного подхода к объектно-ориентированному. Я не могу её найти, но могу примерно передать суть (код Си вперемешку с псевдокодом):

char *username;
int birthDay, birthMonth, birthYear;

int getAge(int birthDay, int birthMonth, int birthYear)
{
    // ...
}

// ...

printf("Username '%s' is %d years old\n", username, getAge(birthDay, birthMonth, birthYear));

struct Date
{
    int year;
    int month;
    int day;
}

struct User
{
    char *name;
    struct Date *birthday;
};

int getAge(struct User *user)
{
    // ...
}

printf("Username '%s' is %d years old\n", user->name, getAge(user));

class Date
{
    protected int year;
    protected int month;
    protected int day;
}

class User
{
    protected string name;
    protected Date birthday; 
    public int getAge();
}

Console.writeline("Username '%s' is %d years old\n", user.name, user.getAge());

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

 

[Страшный Злодей]

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

Например:

класс Автокаталог 
{
    добавляем_в_базу (модель, год выпуска, цена) 
    {
    ...
    }
    редактируем (модель, год выпуска, цена) 
    {
    ...
    }
    выборка (массив_параметров_запроса) 
    {
    ...
    }
}

Или по другому как-то, например каждый метод в отдельный класс? В каком месте надо описывать объект, в начале или в каждом методе?

 

[fixxxer]

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

 

[Страшный Злодей]

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

Буду весьма признателен, если кто-нибудь найдет возможность подсказать детально - какой, в данном случае, должна быть структура классов и объектов?

 

[С.]

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

 

[cDLEON]

ООП это, как правило, не один объект. Взаимодействие разных объектов, каждый из которых, решает какую то задачу узкой направленности. Как пример: Автомобиль\Пассажир\Дорога.
В рамках веб-программирования это чаще всего паттерн проектирования MVC.
А то о чём говоришь ты - больше похоже на то же функциональное программирование. Только классы используются как нэймспейсы. Т.е. я веду к тому, что просто начав использовать слово "class", ты не будешь сразу писать объектно. Объектно писать нужно учиться. )

 

[freeek]

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

 

[Страшный Злодей]

В мелком приложении ООП конечно никакого выигрыша не дает.

Объектно писать нужно учиться. )

в ооп мы работаем с объектами а не классами.

Я ощущаю себя полным болваном, но мне кажется, что по существу вопроса так никто и не высказался... Наверное здесь я виноват, зацепив своим вопросом философское поле "ООП или не ООП", тем самым увеличив границы обсуждения гораздо шире, чем конкретика ожидаемого ответа. Попытаюсь исправиться, вот конкретный вопрос - "какой, в случае реализации описанного автокаталога (как наиболее типичного примера для большинства web-приложений), должна быть структура классов и объектов? Хочется увидеть блок-схему или псевдокод с понятной логикой использования ООП". Благодарю за терпение.

 

[cDLEON]

Это потому, что ты смотришь не в суть того, что пишут, а воспринимаешь только лишь отдельные кусочки сообщений. Переубеждать тебя начать писать код с ООП здесь ни кто не будет.
Конкретно по твоей задаче у тебя есть один объект "автомобиль" с свойствами и функциями сохранения изменений, добавления и удаления. Но в реальной системе кроме объекта автомобиль есть ещё куча прикладных объектов. Вроде объекта User, Controller и т.д. (это уже зависит от конкретно твоего выбора архитектуры) Ради интереса можешь глянуть как всё это реализовано в популярных фреймворках.

 

[Страшный Злодей]

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

 

[С.]

На твой блок-схеме соотношений классов будет один блок "Автомобиль". Надо нарисовать или сам представишь?

Не думай, что ООП это какая-то магия. Ты начал все правильно. Только задача у тебя вырожденная, поэтому не совсем наглядно. Может быть взять себе для пробы другую задачу?

 

[radioheaded]

Понимаете, если сейчас вам точно ответят на ваш вопрос, то вы совсем ничего не поймете и окончательно запутаетесь. Поэтому вас пытаются осторожно подвести к нужной мысли. На самом деле, просто начните с чего-то. Предлагаемый вами вариант не так уж плох. Пусть вначале будет один класс Автомобиль и он будет делать все необходимые операции. Если все будет удобно, то и хорошо. Если начнут появляться новые сущности и связи, вы сразу почувствуете проблемы. После того, как более-менее въедете, почитайте про Active record. Затем, когда наиграетесь с AR, почитайте про Domain model и Data mapper. Это, конечно, только то, что касается вашей задачи взаимодействия сущности в коде и в БД.

 

[Redjik]

Понимаете, если сейчас вам точно ответят на ваш вопрос, то вы совсем ничего не поймете и окончательно запутаетесь. Поэтому вас пытаются осторожно подвести к нужной мысли. На самом деле, просто начните с чего-то. Предлагаемый вами вариант не так уж плох. Пусть вначале будет один класс Автомобиль и он будет делать все необходимые операции. Если все будет удобно, то и хорошо. Если начнут появляться новые сущности и связи, вы сразу почувствуете проблемы. После того, как более-менее въедете, почитайте про Active record. Затем, когда наиграетесь с AR, почитайте про Domain model и Data mapper. Это, конечно, только то, что касается вашей задачи взаимодействия сущности в коде и в БД.

Только не понравилось, что все яйца в одну корзину... пэттерны и AR

ЗЫ. мне кто-то посоветовал прочитать книгу по рефакторингу, а потом уже по паттернам... за что я очень благодарен этому человеку... Именно благодаря такому подходу ООП более менее встало у меня в голове.

 

[radioheaded]

Что значит, «все в одну корзину паттерны и AR»? А AR, по-вашему, не паттерн? И причем тут рефакторинг? Человек еще ничего не написал и спрашивает, с чего бы начать.

 

[Redjik]

Что значит, «все в одну корзину паттерны и AR»? А AR, по-вашему, не паттерн? И причем тут рефакторинг? Человек еще ничего не написал и спрашивает, с чего бы начать.

У меня узколобое предстaвление об AR =)

А рефакторинг тут потому, что там огромное колличество примеров именно как оптимально реализовывать интерфейсы и их взаимодействие...

 

[флоппик]

А рефакторинг тут потому, что там огромное колличество примеров именно как оптимально реализовывать интерфейсы и их взаимодействие...

Рефакторинг - это не разработка. Это методология, описывающая как делать ПЕРЕработку существущего кода с меньшей головной болью.