Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Для новичков > классы

Автор: 555shiro 14.4.2010, 18:25

здравствуйте! подскажите пожалуйста где можно найти и изучить самую простенькую программу на "Классы" в качестве примера ? вообщем чем больше тем лучше!  поискал в инете ничего путного не нашёл =(

Автор: ИванМ 14.4.2010, 18:33

Цитата(555shiro @  14.4.2010,  18:25 ) где можно найти и изучить самую простенькую программу на "Классы" в качестве примера 555shiro, на этом форуме

Автор: azesmcar 14.4.2010, 20:07

Классы - это наверное самая сложная часть C++ для новичков после указателей. Не потому что сложно понять как они работают, а сложно понять зачем они нужны. Большинство программ с использованием ООП у новичков (да и у не новичков тоже) сводятся к написанию функций в классах. Ну и какой смысл в такой программе? Чем такой способ программирования отличается от процедурного? Ничем! Очень важно понять саму концепцию ООП и тогда использование классов в программе облегчит вашу задачу. Глубокие понимание ООП придет с изучением шаблонов проектирования, но до этого еще есть время. Начнем с простого понятия класс. Вспомним понятие структуры из языка Си; по сути это объявление нового типа, который состоит из набора объектов определенных типов, например нам нужен тип, хранящих координаты. Код struct Point {    int x;    int y; }; и еще один тип, хранящий информацию о линии. Для линии нам понадобится координаты двух точек, используем уже существующую структуру Point Код struct Line {    Point start;    Point end; }; теперь нам нужна функция, чтобы подсчитать длину этой линии Код unsigned int line_length(Line l) {    return подсчет_длины; // не будем вдаваться в детали реализации } ... Line l; l.start.x = 10; l.start.y = 10; l.end.x = 30; l.end.y = 20; int length = line_length(l); ... теперь представим тоже самое в виде класса, т.е. напишем не глобальную функцию а member функцию Код struct Line { private:    Point start;    Point end; public:     Line(int xf, int yf, int xt, yt) // конструктор {       start.x = xf;       start.y = yf;       end.x = xt;       end.y = yt;    }    unsigned int length() {       return подсчет_длины;    } }; Line l(10, 10, 30, 20); int length = l.length(); в использовании изменилось не многое, но мы теперь представили нашу линию как самостоятельный объект, который умеет считать свою длину. Можем также создать классы типа Rectangle (прямоугольник), Circle (круг) ... и добавить в них свои функции, например подсчета площади. В таком виде классы не почти не отличаются от структур, хотя на самом деле в C++ класс от структуры отличается одним маленьким нюансом, но об этом потом. 3 главные парадигмы объектно-ориентированного программирования - это Инкапсуляция Наследование Полиморфизм пройдемся по очереди Инкапсуляция дает возможность скрывать детали реализации от пользователей вашего класса, предоставляя ему удобный интерфейс для работы с объектом, но скрывая то, что его не касается, например в этом примере Код struct Line { private: // доступ закрыт    Point start;    Point end; ... объекты start и end объявлены как private, это значит, что к этим объектам может обратится только функции самого класса и друзья класса. public означает, что доступ открыт для всех protected открывает доступ только для наследников класса и его друзей например у нас есть функция, которая нужна для внутренней реализации функционала нашего класса и пользователям предоставлять доступ к ней нельзя, в таком случае она объявляется как private, дабы уберечь пользователя от случайных ошибок. Наследование позволяет расширить функционал класса, не меняя основной, например у нас есть класс TV (телевизор) который работает, имеет функции On(), Off() и ChangeChannel(), но мы хотим создать новый, революционный телевизор под маркой CoolTV, который имеет функцию блокирования каналов, в таком случае мы наследуем уже имеющуюся технологию телевизора, с его функционалом (чтобы не изобретать велосипед) и расширяем его. Код class TV { public:    void On();    void Off();    void ChangeChannel(int channel); }; class CoolTV : public TV { public:    void BlockChannel(int channel); }; тогда наш класс CoolTV будет обладать всеми функциями класса TV плюс функцией блокирования канала. Полиморфизм (динамический) позволяет динамически определять функцию, которая должна быть вызвана на основе типа объекта. Допустим у нас в классе TV есть функция show(), которая отвечает за показ изображения и нам хочется в нашей новой, современной модели изменить эту функцию так, чтобы она показывала цветное изображение. Код class TV { public:    void On();    void Off();    void ChangeChannel(int channel);    void show(); }; class CoolTV : public TV { public:    void BlockChannel(int channel);    void show(); // переопределяем функцию }; переопределяем функцию show(), посмотрим что получилось Код TV * v = new TV(); v.show(); // вызывается функция show() из класса TV ... TV * v = new CoolTV(); v.show(); // опять вызывается функция show() из класса TV если мы вызываем функцию show() через указатель базового класса, вызывается функция из базового, несмотря на то, что на самом деле создан класс CoolTV (т.е. наследник). В чем же проблема? Допустим у нас есть класса RemoteControl, который уже работает с классом TV Код class RemoteControl { public:    RemoteControl(TV * tvObject); // создаем пульт и настраиваем на работу с нашим телевизором    void On();    void Off(); }; при включении нажатии на кнопку включения (т.е. вызове функции On() из класса RemoteControl) вызывается функция On() телевизора и функция show(). В вышеупомянутом примере мы не сможем использовать наш пульт ДУ для класса телевизора CoolTV, потому что несмотря на то, что мы написали функцию вывода цветного изображения эта функция не вызывается. Это очень легко исправить и именно этим и занимается полиморфизм. Код class TV { public:    void On();    void Off();    void ChangeChannel(int channel);    virtual void show(); }; достаточно добавить ключевое слово virtual перед определением функции в базовом классе, после этого программа начнет вести себя следующим образом Код TV * v = new TV(); v.show(); // вызывается функция show() из класса TV ... TV * v = new CoolTV(); v.show(); // вызывается функция show() из класса CoolTV <--------------! и тогда нам не придется создавать еще один пульт дистанционного управления для работы с нашим цветным телевизором. Тема очень большая и все тут написать нереально, вот это то, что не поленился описать, все равно часто спрашивают, буду посылать всех сюда   Может потом еще добавлю, надеюсь нигде не ошибся, много текста а я слишком ленивый, чтобы все проверять еще раз

Автор: mes 14.4.2010, 20:48

Цитата(azesmcar @  14.4.2010,  19:07 ) Чем такой способ программирования отличается от функционального? судя по контексту, имелся ввиду процедурный стиль,  а за "функциональным" закреплен несколько иной смысл..

Автор: azesmcar 14.4.2010, 20:51

Цитата(mes @  14.4.2010,  20:48 ) судя по контексту, имелся ввиду процедурный стиль,  а за "функциональным" закреплен несколько иной смысл..  Исправил.

Автор: mes 14.4.2010, 20:54

Цитата(azesmcar @  14.4.2010,  19:07 ) это объявление нового типа, который хранит в себе другие типы, структура не хранит типы..  структура, как объект, состоит из набора объектов  каких-то типов.. ну а как тип, описывает это устройство. P.S. сорри за придирки,  я из хороших побуждений..  P.S.S. на какую статью решился !     правда над ней надо еще хорошо поработать, чтоб можно было отсылать новичков.

Автор: azesmcar 14.4.2010, 21:09

Цитата(mes @  14.4.2010,  20:54 ) структура не хранит типы..  структура, как объект, состоит из набора объектов  каких-то типов.. ну а как тип, описывает это устройство. Ну нет опыта написания книг, могу термины попутать   Цитата(mes @  14.4.2010,  20:54 ) правда над ней надо еще хорошо поработать, чтоб можно было отсылать новичков дополняйте, исправляйте..я отредактирую, у меня нет претензий на идеал, за пол часика полностью отточить не удастся, иначе быть мне писателем а не программистом

Автор: kemiisto 14.4.2010, 21:13

Цитата(mes @  14.4.2010,  21:54 ) правда над ней надо еще хорошо поработать Я даже могу подсказать в каком направлении работать: Удалить всё, что написано.   "Курить" Smalltalk. Увидеть, как оно (ООП) работает в совершенно иной системе. Динамическая типизация, позднее связывание, динамическая диспетчеризация сообщений. "Курить" Oberon-2/Component Pascal (ну можно Fortran, хотя там своих приколов хватает). Увидеть, как оно (ООП) работает в нормальных имеративных языках со строгим контролем типов на этапе компиляции и без всего того хлама, который есть в С++. Осмыслить. Долго и мучительно.   Написать всё "с нуля". Побочные эффекты: уже на стадии осмысления будут весьма и весьма вероятны рефлекторные сокращения ЖКТ даже при беглом взгляде на C++.   Опережая вопрос "Что сам не напишешь?", скажу сразу: я - на стадии осмысления.   P.S. "Ходят слухи", что для полного просветления можно "курнуть" ФП и осознать единство парадигм функционального и объектно-ориентированного программирования. P.P.S. Ещё можно "курнуть" Lua. Понять, что ООП бывает и без классов. Нужны то всего first-class functions и таблички.

Автор: azesmcar 14.4.2010, 21:14

kemiisto Мы тут вроде о C++ говорим. Добавлено через 1 минуту и 12 секунд Цитата(kemiisto @  14.4.2010,  21:13 ) P.P.S. Ещё можно "курнуть" Lua. Понять, что ООП бывает и без классов. Нужны то всего first-class functions и таблички. smile   и вообще-то вопрос был о КЛАССАХ.

Автор: kemiisto 14.4.2010, 21:20

Цитата(azesmcar @  14.4.2010,  22:14 ) Мы тут вроде о C++ говорим. Вижу, вижу. Цитата(azesmcar @  14.4.2010,  22:14 ) и вообще-то вопрос был о КЛАССАХ Да, и вот начало твоего ответа: Цитата(azesmcar @  14.4.2010,  21:07 ) Очень важно понять саму концепцию ООП и тогда использование классов в программе облегчит вашу задачу.

Автор: mes 14.4.2010, 21:33

Цитата(kemiisto @  14.4.2010,  20:13 )     * Удалить всё, что написано. smile      * "Курить" Smalltalk. Увидеть, как оно (ООП) работает в совершенно иной системе. Динамическая типизация, позднее связывание, динамическая диспетчеризация сообщений.     * "Курить" Oberon-2/Component Pascal (ну можно Fortran, хотя там своих приколов хватает). Увидеть, как оно (ООП) работает в нормальных имеративных языках со строгим контролем типов на этапе компиляции и без всего того хлама, который есть в С++.     * Осмыслить. Долго и мучительно. smile      * Написать всё "с нуля". Побочные эффекты: уже на стадии осмысления будут весьма и весьма вероятны рефлекторные сокращения ЖКТ даже при беглом взгляде на C++. smile  Опережая вопрос "Что сам не напишешь?", скажу сразу: я - на стадии осмысления. smile  P.S. "Ходят слухи", что для полного просветления можно "курнуть" ФП и осознать единство парадигм функционального и объектно-ориентированного программирования. P.P.S. Ещё можно "курнуть" Lua. Понять, что ООП бывает и без классов. Нужны то всего first-class functions и таблички. smile     и все для того, чтоб объснить новичкам, которые не хотят самостоятельно читать литературу,  как работают классы в C++  P.S. Цитата(kemiisto @  14.4.2010,  20:13 ) и осознать единство парадигм функционального и объектно-ориентированного программирования. слово "единство " имхо не очень подходит на эту роль.. правда другого подходящего вспомнить также не могу

Автор: kemiisto 14.4.2010, 21:36

Цитата(mes @  14.4.2010,  22:33 ) и все для того, чтоб объснить новичкам, которые не хотят самостоятельно читать литературу,  как работают классы в C++   Есть тут некий оверхед. Но, но, но... Во-первых, я забыл последний пункт списка: PROFIT??? Во-вторых, ещё раз процитирую: Цитата(azesmcar @  14.4.2010,  21:07 ) Очень важно понять саму концепцию ООП Объясняющему это важно понять в первую очередь. Ничего личного!

Автор: ИванМ 14.4.2010, 21:40

Такое ощущение что перед тем, как отправить свой пост, kemiisto курил не только Smalltalk, Oberon-2/Component Pascal, ФП и Lua, а что-то еще

Автор: mes 14.4.2010, 21:42

Цитата(kemiisto @  14.4.2010,  20:36 ) PROFIT??? ну это  к обсуждаемому напрямую не относится.. Цитата(kemiisto @  14.4.2010,  20:36 ) Во-вторых, ещё раз процитирую: имхо, имелось ввиду :  Очень важно понять саму концепцию ООП_с_точки_зрения_C++  и у автора была поправка на этот счет : Цитата(azesmcar @  14.4.2010,  20:09 ) Ну нет опыта написания книг, могу термины попутать smile  Добавлено @ 21:44 Цитата(ИванМ @  14.4.2010,  20:40 ) Такое ощущение что перед тем, как отправить свой пост, kemiisto курил не только Smalltalk, Oberon-2/Component Pascal, ФП и Lua, а что-то еще  Ну тогда придется предположить, что он курит это "что-то" чуть ли не постоянно  даже беглый просмотр высказываний "прошлых лет" поможет убедиться в этом..

Автор: mes 14.4.2010, 21:57

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

Автор: kemiisto 14.4.2010, 22:08

Цитата(mes @  14.4.2010,  22:42 ) Очень важно понять саму концепцию ООП_с_точки_зрения_C++ Тут много мыслей будет.   Во-первых, все беды С++ вот от этого. Строгая_с_точки_зрения_C++ типизация, обобщённое_с_точки_зрения_C++ программирование, уже упомянутое ООП_с_точки_зрения_C++ и многое-многое другое. Это доставляет, ей богу. Во-вторых, концепция, она на то и концепция (парадигма такая парадигма, если хотите) чтоб быть "language agnostic". Суть вот в чём. Существует достаточно распространённая точка зрения, что чем больше языков изучил программист, тем лучше. Изучил, скажем только С++, многие концепции остались незатронутыми совсем, а затронутые могут быть совершенно неверно истолкованы. Поэтому неплохо изучить Java/C#, сверху "прикрыть" Питоном. Ну и там целая плеяда Ruby, Objective-C,  D, ... - по вкусу. И может создаться впечатление, что я советую что-то подобное и с посылом согласен. Впечатление, смею заверить, обманчивое. Дело в том, что необходимость в изучении всей этой (не побоюсь этого слова) кучи только одна - попытка невелировать идиотизмы каждого конкретного языка, увидив их воучию при сравнении с "товарищами по несчастью". Все эти языки - жуткая смесь нормальных идей и бреда, родившегося в головах "творцов". Бреда обычно больше. Причём наблюдается корреляция: чем больше бреда в языке, тем больше ЧСВ у творца. Но что хорошо - бредили все по разному. И вот продираясь через "прелести" этой "могучей кучки" можно, конечно, многое для себя уяснить. Но, "мы пойдём другим путём". Надо смотреть языки концептуально чистые, простые, основанные на небольшом таком списочке идей-концепций. Ухватить суть, поставить технику. И тогда уже при взгляде на представителя кучи, будет не хорошо, но "как стекло протёрли" (с) Вот я примеры таких языков привёл. "Наводку" дал. Дальше - дело добровольное.  P.S. Выдыхаю.

Автор: kemiisto 14.4.2010, 22:28

Цитата(kemiisto @  14.4.2010,  23:08 ) P.S. Выдыхаю. Рано. Не довёл до конца. Так вот. Эти простые языки хороши именно тем, что за деревьями синтаксиса виден лес концепций.  Крыши хлопают в ладоши... Синтаксис не мешает изучать концепции (хоть тоже ООП). Инструменты (компилятор, среда, ...) помогают в изучении, а не мешают. Но дальше уже частности пойдут. Главное - виден лес!

Автор: qweqwe 14.4.2010, 22:29

не удержался и переделал парочку примеров с плюсов на F# (на OCaml будет примерно также) Цитата(azesmcar @  14.4.2010,  20:07 ) struct Point {    int x;    int y; }; Код type Point = {x:int; y:int} Цитата(azesmcar @  14.4.2010,  20:07 ) struct Line { private:    Point start;    Point end; public:     Line(int xf, int yf, int xt, yt) // конструктор {       start.x = xf;       start.y = yf;       end.x = xt;       end.y = yt;    }    unsigned int length() {       return подсчет_длины;    } }; Line l(10, 10, 30, 20); int length = l.length(l); Код type Line (xf, yf, xt, yt) =    let start = {x = xf; y = yf}   let end   = {x = xt; y = yt}      member this.Length = sqrt <| (xf - xt)^2 + (yf - yt)^2   new (p1 : Point, p2 : Point) =      new Line(p1.x, p1.y, p2.x, p2.y) здесь даже на один конструктор больше, мечта любого плюсовода - вызвать один конструктор из другого

Автор: ИванМ 14.4.2010, 22:32

kemiisto, а теперь, если не сложно, тоже самое только с ориентиром на практику. Как ваши идеи помогут лучше питаться и больше позволять излишеств? Добавлено через 2 минуты и 41 секунду kemiisto, о, у вас уже последователи появились

Автор: qweqwe 14.4.2010, 22:35

Цитата(ИванМ @  14.4.2010,  22:32 ) Как ваши идеи помогут лучше питаться и больше позволять излишеств? если вам это не понятно, то, по всей видимости вы не заслуживаете всего этого

Автор: mes 14.4.2010, 22:48

Цитата(ИванМ @  14.4.2010,  21:32 ) у. Как ваши идеи помогут лучше питаться и больше позволять излишеств? они позволят освободить мысли, и при програмировании не зависить от языка, а использовать его  я практически полностью подерживаю kemiisto  в высказанных мыслях, кроме одного.. того по какому поводу было все это высказано

Автор: azesmcar 14.4.2010, 22:48

Цитата(kemiisto @  14.4.2010,  21:20 ) Да, и вот начало твоего ответа: Не помешало бы понять, что мы говорим об ООП в контексте C++   Неужели я должен был это указать находясь в самом разделе C/C++? Я вообще-то начинал писать ответ, а потом из одного следовало другое ... ну и вышла такая вот статья или называйте ее как хотите. kemiisto, ну не знаю я оберон, прости грешного (исправится не обещаю, будем считать что я неисправимый грешник)..я C++ программист  это меня бес попутал  Добавлено @ 22:56 ИванМ kemiisto ярый ненавистник языка C++, я тоже конечно не в восторге, у него много минусов, но что делать? за что платят на том и пишем.

Автор: ИванМ 14.4.2010, 22:57

qweqwe, уж куда мне до вас (что за хамство?) azesmcar, а идея у вас была благая  . Теперь чтобы новичков сюда отправить, их нужно будет сперва морально подготовить   Цитата(mes @  14.4.2010,  22:48 ) они позволят освободить мысли, и при програмировании не зависить от языка, а использовать его  все равно ничего не понял) видимо qweqwe прав)

Автор: limelight 14.4.2010, 23:19

Исправьте, плз в куске кода Код struct Line { private:    Point start;    Point end; public:     Line(int xf, int yf, int xt, yt) // конструктор {       start.x = xf;       start.y = yf;       end.x = xt;       end.y = yt;    }    unsigned int length() {       return подсчет_длины;    } }; Line l(10, 10, 30, 20); int length = l.length(l); в последней строке должно быть ведь  Код int length = l.length(); , а не  Код int length = l.length(l); ??

Автор: qweqwe 14.4.2010, 23:20

Цитата(ИванМ @  14.4.2010,  22:57 ) все равно ничего не понял) видимо qweqwe прав) вон из профессии!

Автор: ИванМ 14.4.2010, 23:27

qweqwe, уже вещи собрал)

Автор: azesmcar 14.4.2010, 23:38

kemiisto Понимаешь, вообще-то моей целью было рассказать частично о концепциях ООП в C++ и о классах и я попытался сделать это доступным образом. Если ты считаешь, что я не смог уместить в двести строк книгу GOF в вольной интерпретации то ты совершенно прав  но я, несмотря на прогрессирующую манию величия к этому и не стремился   Я не рассказал и половину того, что поддерживает C++, а говорить о том, что он НЕ поддерживает было бы смешно в конкретной ситуации. Если ты считаешь что в описании того, что есть на данный момент есть ошибка то укажи, я ее с удовольствием исправлю, я и не утверждал что их нет, коды писал тут, текст тоже, даже в книгах ошибаются..мало ли, всякое случается, а если есть что дополнить то милости просим, с удовольствием почитаю.  Добавлено через 3 минуты и 23 секунды limelight, да, поганый копи-паст   исправил, спасибо.

Автор: kemiisto 15.4.2010, 08:38

azesmcar, OK. Сделаем так. Сегодня до полудня (т.е. до 2 МСК) я напишу сюда первую часть опуса о классах. Чтоб не было ощущения, что я тут из пустого в порожнее...

Автор: azesmcar 15.4.2010, 08:48

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

Автор: Shaggie 15.4.2010, 09:51

Цитата(kemiisto @  14.4.2010,  22:13 ) P.S. "Ходят слухи", что для полного просветления можно "курнуть" ФП и осознать единство парадигм функционального и объектно-ориентированного программирования. А теперь под бравурную музыку в форуме C/C++: для новичков появляется описание Haskell type classes    Цитата(kemiisto @  14.4.2010,  22:13 ) P.P.S. Ещё можно "курнуть" Lua. Понять, что ООП бывает и без классов. Нужны то всего first-class functions и таблички. В скриптовых языках отчётливо видно, что все объекты являются не более чем словарями ключей и значений. Вместо Lua можно взять JavaScript. Или Perl. Или Python, в нём, правда, уже меньше заметно. А можно нарисовать полную объектность на C и осознать лишний раз, что все эти парадигмы - лишь навороты над голым ассемблером, причём, по большей части, запрещающие. Надеюсь, трава кончится раньше. Вообще в этой теме по существу только azesmcar ответил, за что ему заслуженный плюс в репутацию, остальное можно будет со временем вынести в религиозные войны (надо только ответа kemiisto дождаться).

Автор: kemiisto 15.4.2010, 12:12

Цитата(Shaggie @  15.4.2010,  10:51 ) Надеюсь, трава кончится раньше.    Цитата(Shaggie @  15.4.2010,  10:51 ) надо только ответа kemiisto дождаться "Мы начинаем КВН!" (с) ==================================================================== Часть I. Классы_с_точки_зрения_C++. Пролог. Когда в какой-нибудь книге или статье речь заходит о классах, сразу же "всплывает" нехорошая аббревиатура ООП с ещё кучкой нехороших слов (инкапсуляция, наследование, полиморфизм, ...).   Объектно-ориентированное программирование (ООП) мы оставим "на потом". Сейчас лишь скажем, что в своё время оно появилось как ещё один способ борьбы со всё возраставшей (и по сей день возрастающей) сложностью программного обеспечения. Стоит упомянуть, что структурное программирование - так же способ борьбу со сложностью ПО. Хорошо структурированные программы остаются читабельными и сопровождаемыми при объёме на порядок большем, чем программы плохо структурированные. Про неструктурированные программы и говорит нечего. Спагетти-код такой спагетти.   Давайте поговорим об этой самой борьбе со сложностью, а к ООП вернёмся, но потом. В конце концов, ООП - всего лишь частный приём борьбы со сложностью, да и к тому же domain specific (имеет отношение только к программированию). Итак, сложность и борьба с нею посредством абстрагирования - центральная тема пролога. Поехали!  Самый действенный способ борьбы со сложностью - вушеупомянутое абстрагирование. Позволю себе процитировать свой любимый учебник философии за авторством Алексеева П.В., Панина А.В. Цитата Абстрагирование есть процесс мысленного выделения, вычленения отдельных интересующих нас в контексте исследования признаков, свойств и отношений конкретного предмета или явления и одновременно отвлечение от других свойств, признаков, отношений, которые в данном контексте несущественны. Временное отвлечение от ряда признаков, свойств и отношений изучаемых предметов позволяет глубже понять явление. Добавить тут нечего. Разве вот что. Абстрагирование помогает не только лучше понять предмет/явление, но и лучше его описать (что, конечно же, является следствием глубокого понимания). В конце концов наша конечная цель именно описание предмета/явления для сохранения полученных знаний и передачи благодарным потомкам. Итак, казалось бы, причём тут абстрагирование? Давайте посмотрим, как его использовать в программировании.  Три стека. У нас возникла потребность в стеке целых чисел. Что это можно почитать в той же http://ru.wikipedia.org/wiki/Стек. Итак, если мы абстрагируемся от конкретной задачи (которую я и не сформулировал, кстати говоря), абстрагируемся от типа данных элементов стека (целое число) и ещё много от чего, мы придём к выводу, что наш стек (чем бы он ни был) поддерживал как минимум 2 операции: push - добавление элемента; pop - удаление элемента. Остальное - по вкусу. Существует несолько вариантов реализации стека. Давайте выберем самую простенькую - реализацию на основе массива (array implementation) и напишем уже наконец-то хоть какой-то код! Вариант №1. Абстрактная структура данных. stack_ads.h Код #ifndef STACK_ADS #define STACK_ADS const int capacity = 10; void clear(); int size(); int pop(); void push(int value); #endif STACK_ADS stack_ads.cpp Код #include "stack_ads.h" int items[capacity]; int top = -1; void clear() {   top = -1; } int size() {   return top + 1; } int pop() {   top -= 1;   return items[top + 1]; } void push(int value) {   top += 1;   items[top] = value; } main.cpp Код #include <iostream> #include "stack_ads.h" int main (int argc, char* const argv[])  {   push(1);   push(2);   push(3);      std::cout << pop() << std::endl;   std::cout << pop() << std::endl;   std::cout << pop() << std::endl;      return 0; } Что тут есть что? Так, суффик ads - аббревиатура от abstract data structure (ADS). Абстрактная структура данных. Абстрактна она по нескольким причинам. Стек может иметь в качестве элементов не только целые числа. А любой другой тип данных. Идеалогия работы, реализация и многое-многое другое (почти) не претерпят изменений. Существенно лишь то, что это стек, тип элементов - вторичен. Мы отделили интерфейс от реализации. Сделали мы это в том числе и для упрощения последующих изменений. Но основная цель - зафиксировать в коде факт абстрагирования. Т.е. мы выявили основные признаки-свойства такого предмета как стек и хотим отразить это в коде. Что существенно для такого предмета как стек? Правильно. Существенно наличие возможности добавить элемент "в начало", взять элемент "с конца". Всё остальное - детали реализации. Они конкретны, не абстрактны. По вкусу мы добавили функцию очистки стека и возможность узнать текущее количество элементов. Прежде чем пойдём дальше нужно обратить внимание на константу capacity - максимальное число элементов в стеке. В принципе, это деталь реализации и можно было её не выносить в интерфейс. В таком случае, обязанность отслеживать попытки добавить большее число элементов ложиться на программиста, пищущего stack_ads. По-хорошему, кстати говоря, и обязанность отслеживать попытки взять элемент из пустого стека тоже лежит на нём. Но этот программист ленивый!  Да и задача учебная. Поэтому отслеживать попытки взять элемент из пустого стека он не стал, а обязанность отслеживать попытки добавить большее число элементов переложил на плечи программиста пишущего main.cpp. НО! При этом открыв ему эту важную деталь реализации, чтоб она ему глаза мозолила. Стоп! Один программист, другой программист... Брррр.... Так вас что, двое!? Вот тут весь "цимус". Программистов, работающих над одним проектом может быть не только двое-трое. Тысячи их!!! Даже если программист и один, часть кода может быть написана сейчас, часть - через месяц, и, строго говоря, это уже два разных человека, не то что программиста. В одну реку, как говорится, дважды не войдешь. Вот где важность абстрагирования в плане разделения на интерфейс и реализацию трудно переоценить. Вот где абстрагирование, как сокрытие информации, простите, "рулит". И вот почему. Удобно думать обо всём это в терминах клиентского и серверного модуля. [наброс]Вот только модулей в С++ нет!  Но это ладно.[/наброс] Итак совокупность stack_ads.h и stack_ads.cpp - это наш серверный модуль, а main.cpp - клиентский. Всё как у людей: сервер предоставляет часть функциональности клиенту не раскрывая деталей реализации. Я как то уже писал об этом, http://forum.vingrad.ru/index.php?showtopic=275800&view=findpost&p=1989180. Эх там была красивая картинка. В общем, два модуля (клиент и сервер) прямоугольничками. И от сервера к клиенту треугольничек шёл. Этот треугольничек - наш интерфейс. "Бутылочное горлышко" если хотите, через которое серверный модуль общается с внешним миром. А сам серверный модуль - бутылка из непрозрачного стекла, "чёрный ящик". Так вот существует даже такая методология разработки ПО - http://ru.wikipedia.org/wiki/Контрактное_программирование. Нарошно не привожу русскоязычный термин. Не нравиться мне "контрактное программирование". Уж лучше программирование по контракту. Если отбросить вопросы верификации, то контракт - это соглашение между программистами по поводу интерфейсов. Как только такое соглашение достигнуто и интерфейсы специфицированы, каждый независимый модуль может писать отдельно взятый программист. И сколь бы не была сложна и объёмна задача, программу всегда можно разделить на независимые модули, которые в конце объединить и получить программный продукт. Divide et impera, %username%! Вариант №2. Абстрактный тип данных. Реализация через struct в C-стиле. Но Вернёмя к нашим баранам нашему коду. У первой версии серверного модуля есть (как минимум) один большой недостаток - больше одного стека использовать в клиентском коде не получится. Устраняем. stack_adt.h Код #ifndef STACK_ADT #define STACK_ADT const int capacity = 10; typedef struct {   int items[capacity];   int top; } StackADT; void clear(StackADT* stack); int size(StackADT* stack); int pop(StackADT* stack); void push(StackADT* stack, int value);      #endif STACK_ADT stack_adt.cpp Код #include "stack_adt.h" void clear(StackADT* stack) {   stack->top = -1; } int size(StackADT* stack) {   return stack->top + 1; } int pop(StackADT* stack) {   stack->top -= 1;   return stack->items[stack->top + 1]; } void push(StackADT* stack, int value) {   stack->top += 1;   stack->items[stack->top] = value; } main.cpp Код #include <iostream> #include "stack_adt.h" int main (int argc, char* const argv[])  {   StackADT stack1;   StackADT stack2;   stack1.top = -1;   stack2.top = -1;      push(&stack1, 1);   push(&stack1, 2);   push(&stack1, 3);      std::cout << pop(&stack1) << std::endl;   std::cout << pop(&stack1) << std::endl;   std::cout << pop(&stack1) << std::endl;      push(&stack2, 10);   push(&stack2, 20);   push(&stack2, 30);      std::cout << pop(&stack2) << std::endl;   std::cout << pop(&stack2) << std::endl;   std::cout << pop(&stack2) << std::endl;      return 0; } Что мы тут изменили? Теперь наш серверный модуль предоставляет клиентскому самый настоящий асбстрактный тип данных, abstract data type (ADT). Всё вышеописанное по поводу абстрагирования верно и в этом случае. Преимущества теже + получаем возможность иметь более одной абстрактной структуры данных. Каждая абстрактная структура данных есть елемент множества, которое описывается абстрактным типом данных. Вариант №3. Абстрактная структура данных. Реализация через класс. То были цветочки, а теперь, будьте любезны, ягодки. В смысле, классы. Stack.h Код #ifndef STACK #define STACK const int capacity = 10; class Stack { public:   Stack();   void clear();   int size();   int pop();   void push(int value); private:   int items[capacity];   int top; }; #endif STACK Stack.cpp Код #include "Stack.h" Stack::Stack() {   this->top = -1; } void Stack::clear() {   this->top = -1; } int Stack::size() {   return this->top + 1; } int Stack::pop() {   this->top -= 1;   return this->items[this->top + 1]; } void Stack::push(int value) {   this->top += 1;   this->items[this->top] = value; } main.cpp Код #include <iostream> #include "stack.h" int main (int argc, char* const argv[])  {   Stack stack1;   Stack stack2;      stack1.push(1);   stack1.push(2);   stack1.push(3);      std::cout << stack1.pop() << std::endl;   std::cout << stack1.pop() << std::endl;   std::cout << stack1.pop() << std::endl;      stack2.push(10);   stack2.push(20);   stack2.push(30);      std::cout << stack2.pop() << std::endl;   std::cout << stack2.pop() << std::endl;   std::cout << stack2.pop() << std::endl;      return 0; } Та-да! Всё тот же АТД мы представили теперь классом. А есть ли разница? Ну, что видно невооружённым взглядом: В случае реализации классом, у всех функций ровно на один формальный параметр меньше. Явно нам не надо указывать в качестве параметра, к какому стеку (экземпляру класса Stack) мы обращаемся. Но этот параметр передаётся неявно и всегда доступен в телах этих функциях церез this. this-> в теле этих функций можно (да и нужно) опускать. Но тут я для наглядности оставил. Различается расположение функций. В случае предидущей реализации, функции находятся вне типа данных, а в случае реализации через класс - функции являются частью типа данных. Такие функции называют методами (функция-член_в_терминологии_C++). Различается и синтаксис вызова. стек.функция() вместо функция(стек). Это связано с первым пунктом. Ну или в новых терминах: стек.метод() вместо функция(стек). Это уже из второго пункта. Эпилог. А вот теперь подумаем: стоила ли игра свеч? Перечисленные преимущества, мягко говоря, сомнительны. Ну подумаешь, немного другой синтаксис. Но будут "плюшки"!   Первую "плюшку" в примере с классами я уже показал. Может и зря. Это конструктор, который инициализирует один из членов класса. Обращаю внимание, что в С++ всё тоже самое можно сделать и со struct. Последний пример можно вообще переписать заменив class на struct. Воспринимайте второй пример (ATD "через" struct) как написанный на обычном С, а не на С++. Но это так "плюшечка". А настоящие "плюшки" пойдут во второй части. ООП - эта такая большая корзинка с плюшками.  Ну а названия плющек воистину космические. Но мы их уже где-то слышали... Ах, ну да, в самом начале: инкапсуляция, наследование, полиморфизм, ... Пахнет вкусно, но не сейчас.   P.S. Бета-версия. Должны быть опечатки, описки, неточности, ошибки. Ребята, кто в С++/С больше моего соображает, посмотрите код внимательно.

Автор: kemiisto 15.4.2010, 12:56

Перечитал. Надо вычищать и расширать. А может первые 2 примера на plain C "вкорячить", а не на ++? Хотя...

Автор: mes 15.4.2010, 13:50

kemiisto, ooo.. это что эпидемия ?!   кажется и я заразился, пойду тоже свою писать  шучу ! не дождетесь !    ну а если серьезно, то похвально..   при такой конкурентной борьбе должно получиться нечто хорошее  к коду пока не приглядывался, но Цитата(kemiisto @  15.4.2010,  11:12 ) typedef struct {   int items[capacity];   static int top; откуда взялся static ?!  ну и критика статьи : имхо не стоит уделять время, и место для публикации реализации, достаточно освещать только интерфейс,  ну и лишь некоторые моменты реализации, заслуживающие отдельного внимания.. кстати в этим будет еще раз показан смысл АТД - есть интерфейс и понятно как с ним работать, а какая там реализация клиенту даже задумаваться не надо.

Автор: kemiisto 15.4.2010, 14:26

Цитата(mes @  15.4.2010,  14:50 ) откуда взялся static ?! От балды.  Задача такая  Цитата(kemiisto @  15.4.2010,  13:12 ) инициализировать поле top -1. Только как в С, без конструктора. Я почитал - нельзя никак. Ну кроме как явно для каждой переменной. static - от балды, компилятор "подсказал".

Автор: mes 15.4.2010, 14:34

Цитата(kemiisto @  15.4.2010,  13:26 ) От балды. smile Задача такая  Цитата(kemiisto @  15.4.2010,  11:12 ) У серверного модуля есть один большой недостаток - больше одного стека использовать в клиентском коде не получится. Устраняем. при "статическом top`e" использовать два стека не получится .. сами себе палку в колеса поставили

Автор: kemiisto 15.4.2010, 14:35

Цитата(mes @  15.4.2010,  15:34 ) при "статическом top`e" использовать два стека не получится .. сами себе палку в колеса поставили Да я понял уже. И ведь сказал же - мне не интересно слушать, что это ошибка. Я хочу видеть решение.

Автор: mes 15.4.2010, 14:38

Цитата(kemiisto @  15.4.2010,  13:26 ) Я почитал - нельзя никак.  на то он и Си и в этом его сила  Добавлено через 56 секунд Цитата(kemiisto @  15.4.2010,  13:35 ) Да я понял уже. И ведь сказал же - мне не интересно слушать, что это ошибка. Я хочу видеть решение.  ну так мне казалось решение очевидно... выкинуть static

Автор: kemiisto 15.4.2010, 14:42

Цитата(mes @  15.4.2010,  15:38 ) ну так мне казалось решение очевидно... выкинуть static Да, логично. Бывает.

Автор: mes 15.4.2010, 14:49

Цитата(kemiisto @  15.4.2010,  11:12 )   std::cout << pop(&stack1) << std::endl; также  если следовать правилам хорошего тона, то у стека должен быть метод top() для доступа к верхнему значению.. Цитата(kemiisto @  15.4.2010,  11:12 ) int numberOfItems(); имхо, не очень удачное название.. лучше приучать читателя сразу к общепринятым (по крайней мере для  С++) наименованиям.. Добавлено @ 14:55 Цитата(kemiisto @  15.4.2010,  11:12 ) А вот теперь подумаем: стоила ли игра свеч? Перечисленные преимущества, мягко говоря, сомнительные. Ну подумаешь, немного другой синтаксис. А вот тут я не понял к какому выводу подталкивают читателя... Те "преимущества" представленные перед цитатой, это лишь следствия выбранного способа реализации классов. Ну а основное, ради чего ввели классы, должно будет представлено во второй части статьи : Цитата(kemiisto @  15.4.2010,  11:12 ) . А настоящие плюшки пойдут во второй части.

Автор: kemiisto 15.4.2010, 15:05

Цитата(mes @  15.4.2010,  15:49 ) также  если следовать правилам хорошего тона, то у стека должен быть метод top() для доступа к верхнему значению.. Разве? По-моему нужен только push()/pop(). Остальное - опционально. Я уж и так тут добавил. Ладно, подумаю. Цитата(mes @  15.4.2010,  15:49 ) лучше приучать читателя сразу к общепринятым (по крайней мере для  С++) наименованиям.. Ну можно... size()? Цитата(mes @  15.4.2010,  15:49 )  вот тут я не понял к какому выводу подталкивают читателя... Как это не поняли, если дальше и написали: Цитата(mes @  15.4.2010,  15:49 ) основное, ради чего ввели классы, должно будет представлено во второй части статьи

Автор: mes 15.4.2010, 15:34

Цитата(kemiisto @  15.4.2010,  14:05 ) Как это не поняли, если дальше и написали: Дело в том, что обсуждаемая цитата хотя в общем контексте и понятна и "безопасна", но, мне показалось, несет скрытый подтекст.. хотя может просто сказалось выработанная привычка ожидать от Вас подвоха в сторону С++

Автор: kemiisto 15.4.2010, 15:48

Цитата(mes @  15.4.2010,  16:34 ) просто сказалось выработанная привычка ожидать от Вас подвоха в сторону С++   Я чист!

Автор: bsa 15.4.2010, 17:04

ну развели тут, понимаешь ли... Ладно. продолжайте, если в итоге что-то хорошее выйдет, можно будет в ФАК засунуть.

Автор: mes 15.4.2010, 19:28

Цитата(kemiisto @  15.4.2010,  11:12 ) Стек может иметь в качестве элементов не только целые числа. А любой другой тип данных. Идеалогия работы, реализация и многое-многое другое (почти) не претерпят изменений.  это не отражено в коде.. хотя и не знаю надо ли.. в общем предлагаю для лучшего абстрагитования затайпдефить int к stack_value_t или просто к Т.

Автор: kemiisto 15.4.2010, 19:31

Цитата(mes @  15.4.2010,  20:28 ) это не отражено в коде.. Кому дадено, тот увидит. В парочке мест заменить int на another_type - не проблема.  Ну не шаблонный же класс писать?

Автор: mes 15.4.2010, 19:41

Цитата(kemiisto @  15.4.2010,  18:31 ) Ну не шаблонный же класс писать?  шаблоны лучше приберечь напоследок, но если глава статьи посвящена абстракции, то желательно читателю изначально дать почувствовать ее красоту и силу

Автор: qweqwe 16.4.2010, 13:21

Капитан Очевидность покусал kemiisto

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)