Классы

у меня в рогалике на данный момент нет ни одно класса. Везде обхожусь методами.

/0

man ООП

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

Зачем нужны классы?

ну, в первом читать-считать учат, например

Зачем нужны классы?

Удобно.

Гугли OOP, Design Patterns.

Зачем они нужны, если всегда вместо них можно обойтись методами?

Можно конечно, но иногда ООП или ФВП прилично упрощают код.

ты ещё шаблонов не видел...

Ты забыл выложить код. Тогда тебе бы явно указали, почему и зачем тебе нужны классы.

Кто такой рогалик и чем знаменит?

Классы нужны для
1. Наследования
2. Инкапсуляции
3. Полиморфизма

для этого нужны объекты

Инкапсуляция

Модули.

Полиморфизм

Классы типов.

Наследования

Включения?
---
А нужны ли классы?

Классы в большинстве случаев удобнее методовфункций.

Инкапсуляция

Модули.
> Полиморфизм
Классы типов.
> Наследования
Включения?

Но это будет уже не С++

Зачем они нужны

Иногда нужны. Но я, например, в них не нуждаюсь: слишком сложные программулины я не пишу. Только по-маленькому быдлокожу ☺

Классы в большинстве случаев удобнее функций.

чем? Да и не функций, а методов. В классе может быть несколько функций как и в методах.

http://ru.wikipedia.org/wiki/Roguelike

Лучше для восприятия, и как следствие - для больших проектов, где кучи кода.

В классе может быть несколько функций как и в методах.

Метод - это функция, являющаяся частью класса.

class trololo
{
    int beshelme(); //метод
};

int shekerberelme()
{
//а это уже не метод
}

Ты забыл выложить код.

Скоро выложу как запилю хоть какой-то геймплей.

ну да опять тупак постю.

Лучше для восприятия,

где там лучше?

Одинаково.

В классе может быть несколько функций как и в методах.

Методы класса замыкаются на конкретный набор данных. Если юзать класс, то

1. Не надо при каждом вызове функции передавать контекст (читай private и protected поля класса).

2. За счёт private и protected устраняем (если всяких там грязных хаков не делается) возможность некорректной работы с полями класса (полезно, когда идёт работа с захватываемым ресурсом).

Ada 95 имеет ООП, но не имеет классов.

Вот у меня в рогалике на данный момент нет ни одно класса.

Скоро выложу как запилю хоть какой-то геймплей.

хоть какой-то геймплей.

Ну ты понел :)

Ada 95 имеет ООП, но не имеет классов.

tagged-типы - это те же классы.

Да не нужны.
Мне еще дед говорил, что все нужно писать в опкодах.
Тогда программы получаются намного теплее и ламповее.

Да ваще ничо не нужно.

Можно одной конструкцией выбора альтернативы обходиться. И фсё.

Не очень понял.
Уж наследование точно для классов, а не для объектов, во всяком случае в контексте С++.

Вот у меня в рогалике на данный момент нет ни одно класса.

Скоро выложу как запилю хоть какой-то геймплей.

хоть какой-то геймплей.

Ну ты понел :)

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

во всяком случае в контексте С++

вы так говорите, будто C++ - эталон ООП

Просто по другому было делать костыльно.

Теперь ты знаешь, зачем нужны классы.

Зачем нужны классы?

Поскольку классы - одно из базовых понятий ооп, то вопрос идентичен следующему: «Зачем нужно ооп?». На что википедия (да-да!) отвечает:

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

Формирование КОП от ООП произошло, как случилось формирование модульного от процедурного программирования: процедуры сформировались в модули — независимые части кода до уровня сборки программы, так объекты сформировались в компоненты — независимые части кода до уровня выполнения программы.

Теперь ты знаешь, зачем нужны классы.

Ты и вправду так думаешь?

Ты и вправду так думаешь?

Да. Таков был вопрос в ОПе.

А как ими правильно пользоваться, поймёт с опытом.

Угу... Твоими бы устами...

Будущее покажет...

Тред то про плюсы.

хмм, не заметил. Тада ок

Рано или поздно встает необходимость иметь несколько одинаковых сущностей внутри программы. У всех сущностей одного «типа» одинаковый набор данных, но значения этих данных у каждой сущности уникальны. Как реализовать обработку таких данных? Зависит от реализуемой языком парадигмы программирования. В C например для этого используются структуры, которые хранят состояние сущностей и передаются в обрабатывающие их функции. C++ исповедует ООП, поэтому в нем такое внутреннее состояние обычно хранят внутри классов. А обойтись можно вообще без всего этого, пример тому ассемблер. Другое дело, что заниматься разработкой будет на порядки сложнее.

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

#include <stdio.h>
#include <stdlib.h>

struct monster {
    char *name;
    int health;
};

struct monster *new_monster(char *name, int health)
{
    struct monster *mst = calloc(1, sizeof(struct monster));
    mst->name = name;
    mst->health = health;
    return mst;
}

void delete_monster(struct monster *mst)
{
    free(mst);
    mst = NULL;
}

void hit_monster(struct monster *mst, int buf)
{
    mst->health -= buf;
}

void show_monster(struct monster *mst)
{
    printf("{monster :name %s :health %i}\n", mst->name, mst->health);
}

int main()
{
    struct monster *ogr = new_monster("Ogr", 100);
    struct monster org = { "Org", 50 };

    show_monster(ogr);
    hit_monster(ogr, 10);
    show_monster(ogr);

    show_monster(&org);
    hit_monster(&org, 100);
    show_monster(&org);

    delete_monster(ogr);
}

// {monster :name Ogr :health 100}
// {monster :name Ogr :health 90}
// {monster :name Org :health 50}
// {monster :name Org :health -50}

#include <string>
#include <iostream>

using namespace std;

class Monster {
    string name;
    int health;
public:
    Monster(string name_) : name(name_), health(100) {}
    Monster(string name_, int health_) : name(name_), health(health_) {}
    ~Monster() {}
    void hit(int buf) { health -= buf; }
    void show() { cout << "Monster name = " << name << ", health = " << health << endl; }
};

int main()
{
    Monster ogr("Ogr");
    Monster *org = new Monster("Org", 50);

    ogr.show();
    ogr.hit(10);
    ogr.show();

    org->show();
    org->hit(100);
    org->show();

    delete org;
}

// Monster name = Ogr, health = 100
// Monster name = Ogr, health = 90
// Monster name = Org, health = 50
// Monster name = Org, health = -50

И делать иерархию классов вроде такого - http://stackoverflow.com/questions/1212149/class-diagram-examples-for-rpg-rol.... Ну и для прочих сопутсвующих вещей - RAII на конструкторах/деструкторах (в случае С++), перегрузки методов (вроде одного hit на разных игровых объектах вместо набора hit_this, hit_that или hit(THIS, ...) hit(THAT, ...) т.д.), интерфейсов в виде абстрактных классов с только виртуальными методами (Showable, Hitable, Movable).

И чем второй пример отличается от первого?

зря ты применил f(a, ...) <-> a.f(...) дуализм. Теперь не отделаешься :)

Видел этот тред.

Да и вообще ООП проще объяснить на примере моноидов и прочих Абелевых групп будь ОП хотя бы на 1 курсе института.

Поясните, пожалуйста, каким образом Абелевы группы и моноиды помогают понять ООП? Можно ссылкой :)

Я бы ответил так: классы/объекты являются понятиями которые присутствуют в реальном мире и с которыми мы имеем дело каждую секунду жизни. Соответственно для мозга человека это интуитивно понятная и очень знакомая абстракция.

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

Адепты процедурного программирования могут сказать, что все это лишнее, что все это можно реализовать с помощью процедур/модулей/структур. Я считаю, что глупо вручную проделывать работу компилятора, когда есть удобные и мощные средства out-of-the-box. И эта ручная работа добавляет дополнительные требования к самодисциплине разработчика и к производимому коду чтобы не получить быдлокод... а зачем этот оверхед? Мне кажется это имеет смысл только когда речь идет о производительности, во всех остальных случаях использовать процедурный подход вместо ООП по религиозным соображениям мне кажется глупым.

Кстати, еще мне кажется, что одна из причин большого кол-ва ужасного кода в PHP — это именно его изначальная ориентация на процедурный стиль. Толпам юных кодеров не хватило выдержки и контроля качества. С приходом в PHP фреймворков и активная пропаганда среди PHP разработчиков ООП и паттернов в корне меняет ситуацию.

скастуй йогурта, он тебе расскажет про ооп

Мне тоже интересно. А то, скажем, в Карделлиевской Theory of Object, по-моему, абелевых групп нет.

auto_ptr<Monster> org(new Monster(«Org», 50));

А то, скажем, в Карделлиевской Theory of Object, по-моему, абелевых групп нет.

Кстати, не подскажешь, можно ли где-нибудь скачать электронную версию?

Зачем нужны классы?

Точно можно сказать, что абстракция, инкапсуляция, наследование и полиморфизм реализуются в C. Пример.
Шаблоны, вероятно, можно реализовать define-ами, хотя шаблоны - зло, имхо.
Касательно остальных механизмов, нужно изучать паттерны проектирования, чтобы понять как всё легко и просто в ООП.

абстракция, инкапсуляция, наследование и полиморфизм реализуются в C

Только ценой потерь в скорости и/или уймы рутинного кода. И не всё можно сделать, что есть в C++.

Пример

Это helloworld, и то всё вышеназванное в наличии.

Шаблоны, вероятно, можно реализовать define-ами

Только простейшие случаи.

классы/объекты являются понятиями которые присутствуют в реальном мире и с которыми мы имеем дело каждую секунду жизни

Откуда ж эта глупость берётся?