Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Как правильно работать с классами?  (Прочитано 43788 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Alf
Гость
« Ответ #30 : 20-02-2006 14:34 » 

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

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

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

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

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

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

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

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

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

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

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

А вообще критерий истины - практика. Предложенный мной шаблонный вариант представляется мне простым изящным, надежным, легким в реализации и легко пригодным для расширения, ежели такая потребность возникнет.  Приведи решение с глобальными объектами, которое не уступит предложенному по совокупности этих параметров, в особенности в части строгой типизации, и я охотно признаю поражение ООП.
« Последнее редактирование: 20-12-2007 16:11 от Алексей1153++ » Записан
Михалыч
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #31 : 20-02-2006 17:15 » 

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

Поживем - увидим... Доживем - узнаем... Выживу - учту  Улыбаюсь
Alf
Гость
« Ответ #32 : 20-02-2006 17:52 » 

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

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

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

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

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #33 : 21-02-2006 14:57 » 

Alf, я стараюсь быть по возможности точным в своих словах Улыбаюсь Это же твои?
Цитата
...знание паттернов и умение их применять - одно из отличий профессионала от любителя.
И я полностью с тобой согласен - "одно из". Не более того. Несколько лет назад, когда о паттернах еще никто и слыхом не слыхивал профессионалы были. Другое дело сейчас - паттерны вошли в "обиход" и без них уже кое-где совсем никак. Но в очень многих случаях и сейчас вполне без них обходятся при создании программ отнюдь не любительского уровня (и через несколько лет возможно будут обходится, а там глядишь еще чего нового придумают Улыбаюсь - появятся новые профессионалы - это жизнь...). Поэтому я считаю, что знание паттернов желательно, но не жизненно необходимо профессионалу, а вот владение основными алгоритмами, логикой, теорией автоматов
необходимо бесспорно...
Цитата
Весь юмор в том, что данные-то я еще никак не предлагал хранить, я предложил лишь общую структуру объектов.
Глядя на все уже написанное теперь понимаю, что скорее по своему невниманию понял мысль не до конца. Меня смутило вот это:
Цитата
Класс CLine - обычный, неабстрактный. Класс включает в себя набор точек, образующих ломаную.
А поскольку, ради экономии траффика, картинки у меня не грузятся без острой необходимости, то диаграммы классов я не увидел Улыбаюсь Ну и понял буквально Отлично
Статический массив - ясное дело не вариант. Я скорее всего просто ошибся, поскольку - вот оно - процитирую сам себя:
Цитата
Мне лично импонирует идея глобального массива точек, м.б. и статического, хотя и не обязательно. И указатель на массив в любом дочернем классе. Во всяком случае я не стал бы заводить сразу 2 объекта дочерних классов и заполнять каждому из них свой массив. Ладно бы еще когда их только 2...3...10. А если их фиг знает сколько - читай очень много? А еще лучше вообще неизвестно сколько. Создавать динамически по мере надобности - мне так кажется
Смешно - ведь в этом случае мы говорим об одном и том же Улыбаюсь
Записан

Поживем - увидим... Доживем - узнаем... Выживу - учту  Улыбаюсь
Olegator
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #34 : 21-02-2006 21:54 » 

Еще о паттерне "стратегия" можно узнать здесь (фактически это глава из той самой книги без примеров кода): http://ooad.asf.ru/patterns/patterninfo.asp?ID=22
Это как понимать:
Цитата
клиенты должны «знать» о различных стратегиях. Потенциальный недостаток этого паттерна в том, что для выбора подходящей стратегии клиент должен понимать, чем отличаются разные стратегии. Поэтому наверняка придется раскрыть клиенту некоторые особенности реализации. Отсюда следует, что паттерн стратегия стоит применять лишь тогда, когда различия в поведении имеют значение для клиента;
Возможное нарушение инкапсуляции? А клиент это один из видов паттерна?
Записан
Alf
Гость
« Ответ #35 : 21-02-2006 23:20 » 

Цитата: Михалыч link=topic=8222.msg121046#msg121046 daА зачем мнеte=1140533845
Alf, я стараюсь быть по возможности точным в своих словах Улыбаюсь Это же твои?
Цитата
...знание паттернов и умение их применять - одно из отличий профессионала от любителя.
И я полностью с тобой согласен - "одно из". Не более того.

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

Цитата: Михалыч link=topic=8222.msg121046#msg121046 daА зачем мнеte=1140533845
Несколько лет назад, когда о паттернах еще никто и слыхом не слыхивал профессионалы были.

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

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

Цитата: Михалыч link=topic=8222.msg121046#msg121046 daА зачем мнеte=1140533845
Другое дело сейчас - паттерны вошли в "обиход" и без них уже кое-где совсем никак. Но в очень многих случаях и сейчас вполне без них обходятся при создании программ отнюдь не любительского уровня (и через несколько лет возможно будут обходится, а там глядишь еще чего нового придумают Улыбаюсь - появятся новые профессионалы - это жизнь...). Поэтому я считаю, что знание паттернов желательно, но не жизненно необходимо профессионалу, а вот владение основными алгоритмами, логикой, теорией автоматов
необходимо бесспорно...

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

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

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

Записан
Alf
Гость
« Ответ #36 : 21-02-2006 23:36 » 

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

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

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #37 : 23-02-2006 06:33 » 

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

Поживем - увидим... Доживем - узнаем... Выживу - учту  Улыбаюсь
nikedeforest
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #38 : 25-02-2006 00:56 » 

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

ещё один вопрос ...
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #39 : 25-02-2006 01:21 » 

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
nikedeforest
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #40 : 25-02-2006 01:35 » 

Ну я делал так:
Код:
int Arr_Point[2][100];
ArrPoint[0]--x
ArrPoint[1]--y
ArrPoint[][0] - значение координаты
Т.е. создава двумерный массив.
Но мне кажется что вам (тебе, Альфу) этот способ не понравится. Мне бы хотелось знать воше мнение.
И кстати, Альфу почему-то не понравилось, что я использовал структуру.
Записан

ещё один вопрос ...
Михалыч
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #41 : 25-02-2006 04:25 » 

Нет, класс 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, в защищенном или нет, виде Улыбаюсь
« Последнее редактирование: 25-02-2006 04:27 от Михалыч » Записан

Поживем - увидим... Доживем - узнаем... Выживу - учту  Улыбаюсь
nikedeforest
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #42 : 26-02-2006 08:12 » 

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

ещё один вопрос ...
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines