Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Разложение на классы
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
hadrov
Начинаю изучать ООП и пробую представить нижеследующую таблицу в виде классов/класса.


Например:
Код
const int N = 3;

// описание одной ячейки
class Cell
{
protected:
    int value;    
};

// описание группы из максимумов и минимумов
class Group
{
protected:
    Cell max[N];
    Cell min[N];
};

// описание строки
class Row
{
protected:
    float y[N];
    Group group;
};

// описание таблицы
class Table
{
protected:
    Row rows[N];
};


Для упрощения описал только поля данных. Вопрос состоит в следующем: когда в конкретном случае нужно остановится при разложении классов? ИМХО, уж слишком громоздко вышло. Возможно, класс Group стоит исключить и описывать Cell max[N] и Cell min[N] сразу в классе Row.

А может, вообще, не морочить голову и просто описать вместо классов структуры и запихать их в класс Table. Вот только правильно ли это будет с точки зрения ООП?
dxp
Цитата(hadrov @ Dec 4 2008, 00:57) *
Начинаю изучать ООП и пробую представить нижеследующую таблицу в виде классов/класса.


А может, вообще, не морочить голову и просто описать вместо классов структуры и запихать их в класс Table. Вот только правильно ли это будет с точки зрения ООП?

ООП'а тут вас нет. Есть просто объекты. ООП'ом оно станет, когда будет построена иерархия классов во главе с абстрактным базовым классом. Например:

Код
class TElement
{
public:
    virtual void draw() = 0; // отрисовка элемента таблицы
    ... // еще какие-то методы, общие для элементов таблицы
}

class TCell : public TElement
{
   ...
}

class TGroup : public TElement
{
    ...

private:
    TCell cells[N];
    ....
}

class THeader : public TGroup // группа ячеек, выполняющая функцию заголовка в таблице
{
}


И так далее. Конкретная реализация зависит о того, что хотите. Но путь такой. В итоге должна получиться иерархия классов, которая предоставит простую и прозрачную управляемость, что и является целью применения ООП.
hadrov
Пока просветления не наступило. Пойду-ка я еще почитаю Страуструпа.
rvk
Он имеет ввиду, что все участники вложений являются наследниками одного базового класса.
Хотя я считал что ООП это не то как именно вкладываются классы,
а что главной целью является обьект, экземпляр какого то класса.
Неважно наследуемый он там или нет. И вот доступ к ресурсам обьекта, т.е. данным и функциям идет через экземпляр.
Есть класс TClass, есть обьект tObject экземпляр класса TClass.
И до сих пор я полагал, что возможность вызывать функции и массивы из экземпляра tObject.func(), или tObject.array[]
И есть суть ООП, т.е. обьектно ориентированного программирования
или говоря по русски, программирования которое нацелено на обьект.
А наследование, на мой взгляд не является определяющим фактом ООП. Может я чото не так понял?

Да, а по вопросу насколько глубоко вкладывать друг в дружку классы, наверное ограничений нет.
Но и делать 20 вложений без особых оснований тоже не имеет смысла, потому что самому потом
труднее будет разобраться, откуда ноги растут...
amaora
Цитата(rvk @ Dec 4 2008, 22:30) *
...
Хотя я считал что ООП это не то как именно вкладываются классы,
а что главной целью является обьект, экземпляр какого то класса.
Неважно наследуемый он там или нет. И вот доступ к ресурсам обьекта, т.е. данным и функциям идет через экземпляр.
Есть класс TClass, есть обьект tObject экземпляр класса TClass.
И до сих пор я полагал, что возможность вызывать функции и массивы из экземпляра tObject.func(), или tObject.array[]
И есть суть ООП, т.е. обьектно ориентированного программирования
или говоря по русски, программирования которое нацелено на обьект.
А наследование, на мой взгляд не является определяющим фактом ООП. Может я чото не так понял?
...


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

По теме, думаю от ООП тут будет мало пользы, ООП надо использовать для упрощения кода а не для усложнения.
dxp
Цитата(hadrov @ Dec 5 2008, 01:06) *
Пока просветления не наступило. Пойду-ка я еще почитаю Страуструпа.

Еще Буча до кучу почитать, очень внятно дядька описывает прикладные вещи по теме.

Цитата(rvk @ Dec 5 2008, 01:30) *
Он имеет ввиду, что все участники вложений являются наследниками одного базового класса.
Хотя я считал что ООП это не то как именно вкладываются классы,
а что главной целью является обьект, экземпляр какого то класса.
Неважно наследуемый он там или нет. И вот доступ к ресурсам обьекта, т.е. данным и функциям идет через экземпляр.

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

Согласен с amaora в выводе: "По теме, думаю от ООП тут будет мало пользы, ООП надо использовать для упрощения кода а не для усложнения." Особенно по поводу второй фразы цитаты. a14.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.