| |
|
  |
 Разложение на классы |
|
|
|
|
 Dec 3 2008, 18:57
|
Участник
Группа: Участник
Сообщений: 15
Регистрация: 11-11-08
Пользователь №: 41 540
|
Начинаю изучать ООП и пробую представить нижеследующую таблицу в виде классов/класса.  Например: Код 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. Вот только правильно ли это будет с точки зрения ООП?
|
|
|
|
|
|
|
|
Dec 4 2008, 08:40
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(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 // группа ячеек, выполняющая функцию заголовка в таблице
{
} И так далее. Конкретная реализация зависит о того, что хотите. Но путь такой. В итоге должна получиться иерархия классов, которая предоставит простую и прозрачную управляемость, что и является целью применения ООП.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Dec 4 2008, 19:06
|
Участник
Группа: Участник
Сообщений: 15
Регистрация: 11-11-08
Пользователь №: 41 540
|
Пока просветления не наступило. Пойду-ка я еще почитаю Страуструпа.
|
|
|
|
|
|
|
|
Dec 4 2008, 19:30
|
Частый гость
Группа: Свой
Сообщений: 165
Регистрация: 13-05-06
Из: Камышин
Пользователь №: 17 067
|
Он имеет ввиду, что все участники вложений являются наследниками одного базового класса.
Хотя я считал что ООП это не то как именно вкладываются классы,
а что главной целью является обьект, экземпляр какого то класса.
Неважно наследуемый он там или нет. И вот доступ к ресурсам обьекта, т.е. данным и функциям идет через экземпляр.
Есть класс TClass, есть обьект tObject экземпляр класса TClass.
И до сих пор я полагал, что возможность вызывать функции и массивы из экземпляра tObject.func(), или tObject.array[]
И есть суть ООП, т.е. обьектно ориентированного программирования
или говоря по русски, программирования которое нацелено на обьект.
А наследование, на мой взгляд не является определяющим фактом ООП. Может я чото не так понял?
Да, а по вопросу насколько глубоко вкладывать друг в дружку классы, наверное ограничений нет.
Но и делать 20 вложений без особых оснований тоже не имеет смысла, потому что самому потом
труднее будет разобраться, откуда ноги растут...
Сообщение отредактировал rvk - Dec 4 2008, 19:34
|
|
|
|
|
|
|
|
Dec 4 2008, 20:01
|
Местный
Группа: Участник
Сообщений: 421
Регистрация: 2-01-08
Пользователь №: 33 778
|
Цитата(rvk @ Dec 4 2008, 22:30) ...
Хотя я считал что ООП это не то как именно вкладываются классы,
а что главной целью является обьект, экземпляр какого то класса.
Неважно наследуемый он там или нет. И вот доступ к ресурсам обьекта, т.е. данным и функциям идет через экземпляр.
Есть класс TClass, есть обьект tObject экземпляр класса TClass.
И до сих пор я полагал, что возможность вызывать функции и массивы из экземпляра tObject.func(), или tObject.array[]
И есть суть ООП, т.е. обьектно ориентированного программирования
или говоря по русски, программирования которое нацелено на обьект.
А наследование, на мой взгляд не является определяющим фактом ООП. Может я чото не так понял?
... Наследование - это механизм построения абстракций данных, на основе объектов, путём расширения или замены реализации их интерфейса. Использование полученных абстракций есть полиморфизм. В основном ради этого все и делается. А одни только объекты - это модульное программирование. Хотя все понимают ООП по разному. По теме, думаю от ООП тут будет мало пользы, ООП надо использовать для упрощения кода а не для усложнения.
|
|
|
|
|
|
|
|
Dec 5 2008, 06:46
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(hadrov @ Dec 5 2008, 01:06) Пока просветления не наступило. Пойду-ка я еще почитаю Страуструпа. Еще Буча до кучу почитать, очень внятно дядька описывает прикладные вещи по теме. Цитата(rvk @ Dec 5 2008, 01:30) Он имеет ввиду, что все участники вложений являются наследниками одного базового класса.
Хотя я считал что ООП это не то как именно вкладываются классы,
а что главной целью является обьект, экземпляр какого то класса.
Неважно наследуемый он там или нет. И вот доступ к ресурсам обьекта, т.е. данным и функциям идет через экземпляр. Это объектный стиль программирования (парадигма). Когда объекты, инкапсуляция, абстракция. А ООП - это уже дальше, это - полиморфизм, виртуальные функции (методы), иерархии. Согласен с amaora в выводе: "По теме, думаю от ООП тут будет мало пользы, ООП надо использовать для упрощения кода а не для усложнения." Особенно по поводу второй фразы цитаты. 
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
