Первый раз первый Класс!

[Guest_]

Я программирую на VisualBasic. Довольно хорошо вник в концепцию объектно-ориентированного программирования. Однако, не имею чёткого представления зачем нужны классы. Это представление отсутствует из невидимых пока преимуществ их. По ходу дела возник такой вопрос: есть ли такие задачи, которые нельзя решить без создания классов? По-другому: класс - что это: необходимость и/или упрощение понимание кода?

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

10 INPUT A
20 INPUT B
,,,
100 INPUT J
110 S=A+B+C+D+E+F+H+I+J
120 END

и

10 DIM A(10):S=0
20 FOR I=1 TO 10
30 INPUT A(I):S=S+A(I)
40 NEXT I
50 END

Вот хочется так же "визуально" понять все прелести создания собственных классов.

mind: я, конечно, понимаю, что проблема стоит остро =)) , но зачем злоупотр*цензура*ть тегами размера шрифтов?

 

[Guest]

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

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

 

[Guest_]

Согласен с пунктами! Только мотивировка ответа не ясна. При чём тут ассемблер?
Есть ли какие-то готовые примеры явной выгоды (структура кода, быстрота написания) создания класса. Пусть хоть и небольшой пример, но не "теоритезированный", ясный для начинающего.

 

[Guest]

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

CBaseGraphics* aSet;
int nCount;
...
for (int i=0; i<nCount; i++)
{
 if (aSet[i])
  aSet[i]->Draw(context);
}
...
CRectangle::Draw()..
CCircle::Draw()..
CHexagon::Draw()..

Попробуй это реализовать без ООП, учитывая необходимость различных данных для каждой фигуры. Как я уже сказал, реализовать можно, но код будет выглядеть далеко не так ясно. Это полиморфизм(кажется). Кроме того, разработку дополнительных фигур можно поручить другим людям, и для этого не придется править код рисовки и базовые классы. Это наследование. Далее, представь себе что у прямоугольника есть координаты TopLeft+BottomRight. Используя инкапсуляцию, мы можем только в конструкторе их получить, нормализовать и далее работать, считая что TopLeft действительно левее и имеет положительные значения. Без этого мы должны каждый раз проверять, не изменил ли кто значений параметров. Как бы ты не описывал в документации большими буквами, что для изменения положения прямоугольника надо вызвать функцию MoveRect, рано или поздно найдется умник, который изменит координаты одной вершины, считая что все остальное система сделает за него. А безопасное прогаммирование требует, чтобы все такие умники были учтены. Так вот ООП позволяет таким людям ручки шаловливые пообрубать

Написал сумбурно, но надеюсь мысль ясна.

 

[Guest_]

Вот! Ещё более ясно стало. А может есть где на сайте или в сетке такие сравнительные примеры. Опять-таки: пример реализации какой-то задачи с созданием своего класса и пример реализации той же задачи без создания класса. И простой.otvet@hotmail.ru

 

[Kernel]

какой-то задачи с созданием своего класса

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

А в примере выше я так понимаю есть абстрактный интерфейс с виртуальным методом draw - пример на самом деле очень хороший для понимания (нам всем проще понять что то нарисованное - разве что не хватает описаний классов чтоб понять новичку