Как правильно работать с классами?

[Alf]

Ведь одно из основных преимуществ, которое дает ООП - повторное использование кода.

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

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

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

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

Как-то давно, и не помню в какой теме, но абсолютно точно, я уже говорил - что мне, например, паттерны интересны теоритически, но не нужны практически. И STL тоже далеко не всегда нужна. Ну и что? Не профессионально?

Не вижу связи. STL мне вообще практически не нужна, поскольку от использования C++ в новых проектах я отказался полностью. Паттерны - это результат фундаментальной работы четырех не самых глупых людей, перелопативших горы проектов и выделивших наиболее общие и удачные решения. Как их можно сравнивать с частной библиотекой одного из языков программирования, пусть некогда и популярного?

Зачастую (в системах управления например) - чем проще тем лучше - к вопросу о надежности, отлаживаемости, читабельности и т.п.

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

А вообще - была такая тема - Олегатор ее поднимал - границы применения ООП. Это уже наверное туда

Не знаю, не знаю... Человек задал вопрос о работе с классами, следовательно, он уже сделал выбор в сторону ООП, так что границы проводить поздно, мы уже на территории ООП. Конечно, можно фактически писать на FORTRAN'e, используя синтаксис C++. Но нужно ли?

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

[Михалыч]

Alf, ну зачем же так-то? От легких передергиваний до неприятных аналогий
Повторюсь - "одно из основных преимуществ". Я ведь тоже не сказал, что оно основное. И именно ООП я уже много лет успешно использую в "разовых" разработках. По поводу задачи (а не удачи) останусь при своем мнении. Об неудачных на мой взгляд аналогиях скромно умолчу
Ну, паттерны и STL я нигде и ниразу не уравнивал. Просто прозвучало (может мне так показалось) мнение, что без применения STL и паттернов проектирования в профессиональном программировании уже и делать нечего - любительский уровень. Я лишь хотел сказать, что это не так
Предложенное тобой решение и просто и изящно и надежно. Кто бы спорил Однако, хранить данные так, как ты предлагаешь - мне не как-то некомфортно, что-ли... Личные предпочтения   Приводить решение ради "поражения ООП" конечно же бессмысленно, поскольку я и не оспариваю его преимуществ. Всего лишь говорю о том, что применять его можно по-разному

[Alf]

Просто прозвучало (может мне так показалось) мнение, что без применения STL и паттернов проектирования в профессиональном программировании уже и делать нечего - любительский уровень. Я лишь хотел сказать, что это не так

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

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

Однако, хранить данные так, как ты предлагаешь - мне не как-то некомфортно, что-ли... Личные предпочтения

Весь юмор в том, что данные-то я еще никак не предлагал хранить, я предложил лишь общую структуру объектов. Пускай себе класс "линия" содержит в себе указатель на массив точек. Отношение агрегирования вовсе не означает, что все данные нужно физически вколотить в класс-контейнер. Кстати, на C# или Java это и не получится при всем желании. Хотя массив, конечно, далеко не лучший выбор с точки зрения динамического удаления/добавления точек, но как вариант рассмотреть можно.

Статический массив, да еще и глобальный, - это все же не вариант. Заранее не зная, сколько точек в линии, какого размера ты его объявишь? Миллион, чтобы хватило на все случаи жизни? А если не хватит? А если нужны тысячи линий по 4 точки в каждой? Нормальный на мой взгляд подход - это когда данные передаются классу после его создания, а сколько их будет - задача внешнего по отношению к классу приложения.

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

Но не настолько же по-разному, чтобы от идеи ООП ничего не осталось, а на "объектность" программы нам намекало лишь слово "class" в тексте программы. Тем более что принципиальных отличий класса от структуры в C++ нет. Можно взять любую программу на C 20-летней давности, переименовать структуры в классы - и все, хотели объекты - получите. Объектности в такой программе не больше, чем структурности в программе, где каждый второй оператор GOTO.

[Михалыч]

Alf, я стараюсь быть по возможности точным в своих словах Это же твои?

...знание паттернов и умение их применять - одно из отличий профессионала от любителя.

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

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

Глядя на все уже написанное теперь понимаю, что скорее по своему невниманию понял мысль не до конца. Меня смутило вот это:

Класс CLine - обычный, неабстрактный. Класс включает в себя набор точек, образующих ломаную.

А поскольку, ради экономии траффика, картинки у меня не грузятся без острой необходимости, то диаграммы классов я не увидел Ну и понял буквально
Статический массив - ясное дело не вариант. Я скорее всего просто ошибся, поскольку - вот оно - процитирую сам себя:

Мне лично импонирует идея глобального массива точек, м.б. и статического, хотя и не обязательно. И указатель на массив в любом дочернем классе. Во всяком случае я не стал бы заводить сразу 2 объекта дочерних классов и заполнять каждому из них свой массив. Ладно бы еще когда их только 2...3...10. А если их фиг знает сколько - читай очень много? А еще лучше вообще неизвестно сколько. Создавать динамически по мере надобности - мне так кажется

Смешно - ведь в этом случае мы говорим об одном и том же

[Olegator]

Еще о паттерне "стратегия" можно узнать здесь (фактически это глава из той самой книги без примеров кода): http://ooad.asf.ru/patterns/patterninfo.asp?ID=22

Это как понимать:

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

Возможное нарушение инкапсуляции? А клиент это один из видов паттерна?

[Alf]

Alf, я стараюсь быть по возможности точным в своих словах Это же твои?

...знание паттернов и умение их применять - одно из отличий профессионала от любителя.

И я полностью с тобой согласен - "одно из". Не более того.

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

Несколько лет назад, когда о паттернах еще никто и слыхом не слыхивал профессионалы были.

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

Если прекращаешь идти в ногу со временем, очень быстро к слову  "профессионал" добавляется "бывший". Увы, такова жизнь.

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

А кое-где обходятся FORTRAN-IV, а кое-где счетами и логарифмической линейкой... Я своими глазами видел сложнейшую навигационную систему, которая до сих пор работает на IBM-370 (!!!), потому что заменить нечем, а поддерживать такого монстра в рабочем состоянии, когда запчасти нужно искать не на складе, а в музее, настоящее мучение. И в машинных кодах можно писать, и наверняка можно найти пару-тройку примеров, когда это оправданно. Речь в данный момент идет о разработке типовых программ для типового оборудования, а не каких-то спецвычислителей в реальном времени.

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

Вообще там, где начинается систематизация, шаманство превращается в науку. Паттерны - это тоже систематизация. Мне весьма странно было бы увидеть гроссмейстера, который в ответ на предложение играть защиту Филидора спросит: "А чаво это???". Ничуть не лучше выглядит программист-профи, который в ответ на предложение использовать паттерн "декоратор" недоуменно таращит глаза. Причем, заметь, знание защиты Филидора вовсе не означает, что наш шахматист будет пихать ее куда надо и не надо. Это значит лишь, что когда придется, он сможет применить свои знания, не изобретая велосипед. Точно так же знание паттернов дает тебе: 1) возможность применить их там, где это уместно; 2) возможность избежать их бездумного применения там, где это неуместно. Незнание дает тебе лишь вторую возможность, так что решай сам.

[Alf]

Возможное нарушение инкапсуляции?

Отнюдь. Цитата из раздела "Применимость":

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

Как видишь, с точностью до наоборот. Нарушение инкапсуляции - это очень серьезное ухудшение качества программы, а паттерны предназначены для его улучшения.

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

А клиент это один из видов паттерна?

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

[Михалыч]

Ну, ладно... Спор становится беспредметным. Ососбенно по поводу необходимого и достаточного. Для меня - потому, что я именно не вижу уместности паттернов в своих проблемах, а может я просто не настолько их знаю (как там было про кошек? - "...ты просто не умеешь их готовить..." )
Полечу дальше на деревянно-парусиновом "Фармане"

[nikedeforest]

Один вопрос не дает мне покоя. Зачем нужен класс CPoint?
Я так понимаю, что из-за безопасности, но неужели нельзя защитить массив точек в классе СLine?

[Джон]

А что есть точка? Такого типа данных нет. Таким образом "массив точек" не определён. Т.е. или делать структуру или объект (класс), который инкапсулировал бы данные например int X; и int Y;

[nikedeforest]

Ну я делал так:

Код:

int Arr_Point[2][100];
ArrPoint[0]--x
ArrPoint[1]--y
ArrPoint[][0] - значение координаты

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

[Михалыч]

Нет, класс CPoint только из соображений безопасности - это неправильно, конечно.

А что есть точка?  Такого типа данных нет. Таким образом "массив точек" не определён. Т.е. или делать структуру или объект (класс), который инкапсулировал бы данные например int X; и int Y;

Правильно Джон говорит. В первую очередь для этого - создать тип и инкапсулировать данные.
И почему Альфу не понравилась структура - он уже писал, посмотри еще раз внимательнее:

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

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

Код:

class POINT
{
  public:
    POINT(): X(0), Y(0); //конструктор по умолчанию
    POINT(int a, int b): X(a), Y(b);  //еще конструктор
    POINT(const POINT& P) { X=P.getX(); Y=P.getY(); } //конструктор копирования
    void setX(int C);
    void setY(int C);
    int getX(void);
    int getY(void);
  private:
    int X; //координаты точки
    int Y;
};

 
Потом заводим динамический массив (вовсе не обязательно vector<>, и вовсе не обязательно глобальный ), куда складируем, например, указатели на новые точки:

Код:

vector<POINT *> VP; 
POINT *tp;
tp=new POINT(12, 13);
VP.push_back(tp);

А уже указатель на этот динамический массив удобно поместить (как один из вариантов) в класс CLine, в защищенном или нет, виде

[nikedeforest]

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