n We have discussed classes in previous lectures n Here, we discuss design of classes n Library design considerations

Transcription

1 Chapter 14 Graph class desig Bjare Stroustrup Abstract We have discussed classes i previous lectures Here, we discuss desig of classes Library desig cosideratios Class hierarchies (object-orieted programmig) Data hidig 2 Ideals Our ideal of program desig is to represet the cocepts of the applicatio domai directly i code. If you uderstad the applicatio domai, you uderstad the code, ad vice versa. For example: Widow a widow as preseted by the operatig system Lie a lie as you see it o the scree Poit a coordiate poit Color as you see it o the scree Shape what s commo for all shapes i our Graph/GUI view of the world The last example, Shape, is differet from the rest i that it is a geeralizatio. You ca t make a object that s just a Shape Ideals SPOT Pricipal : Sigle Poit of Truth Never do aythig more tha oce Ecapsulate commoly-occurrig sets of actios as fuctios, which ca be re-used Why? Why make more work for yourself? "We will ecourage you to develop the three great virtues of a programmer: laziess, impatiece, ad hubris." -- LarryWall, Programmig Perl (1st editio) Eases maiteace If we eed to chage the way a operatio works, oly eed to chage it i oe place. It s easier to chage data defied oce tha redudatly-defied data (Bak accout example) 3 4 1

2 Logically idetical operatios have the same ame For every class, draw_lies() does the drawig move(dx,dy) does the movig s.add(x) adds some x (e.g., a poit) to a shape s. For every property x of a Shape, x() gives its curret value ad set_x() gives it a ew value e.g., Color c = s.color(); s.set_color(color::blue); p1: p2: Logically differet operatios have differet ames Lies l; Poit p1 100,200 Poit p2 200,300 l.add(p1,p2); wi.attach(l); // add poits to l (make copies) // attach l to widow Why ot wi.add(l)? add() copies iformatio; attach() just creates a referece we ca chage a displayed object after attachig it, but ot after addig it (100,200) (200,300) add() l: (100,200) (200,300) attach() wi: &l 5 6 Expose uiformly Data should be private Data hidig so it will ot be chaged iadvertetly Use private data, ad pairs of public access fuctios to get ad set the data c.set_radius(12); // set radius to 12 c.set_radius(c.radius()*2); // double the radius (fie) c.set_radius(-9); // set_radius() could check for egative, // but does t yet double r = c.radius(); // returs value of radius c.radius = -9; // error: radius is a fuctio (good!) c.r = -9; // error: radius is private (good!) Our fuctios ca be private or public Public for iterface Private for fuctios used oly iterally to a class What does private buy us? We ca chage our implemetatio after release We do t expose FLTK types used i represetatio to our users We could replace FLTK with aother library without affectig user code We could provide checkig i access fuctios But we have t doe so systematically (later?) Fuctioal iterfaces ca be icer to read ad use E.g., s.add(x) rather tha s.poits.push_back(x) We eforce immutability of shape Oly color ad style chage; ot the relative positio of poits cost member fuctios The value of this ecapsulatio varies with applicatio domais Is ofte most valuable Is the ideal i.e., hide represetatio uless you have a good reaso ot to 7 8 2

3 Regular iterfaces Lie l Poit100,200,Poit300,400 Mark m Poit100,200, 'x' // display a sigle poit as a 'x' Circle c Poit200,200,250 // Alterative (ot supported): Lie l2 x1, y1, x2, y2 // iteger argumets: from (x1,y1) to (x2,y2) // How about? (both supported): Rectagle s1 Poit100,200,200,300 // width==200 height==300 Rectagle s2 Poit100,200,Poit200,300 // width==100 height==100 // but (a error): Rectagle s3 100,200,200,300// is 200,300 a poit or a width plus a height? A library A collectio of classes ad fuctios meat to be used together As buildig blocks for applicatios To build more such buildig blocks A good library models some aspect of a domai It does t try to do everythig Our library aims at simplicity ad small size for graphig data ad for very simple GUI We ca t defie each library class ad fuctio i isolatio A good library exhibits a uiform style ( regularity ) 9 10 All our shapes are based o the Shape class E.g., a Polygo is a kid of Shape Shape Shape is a base class Defies what is commo to all Shapes class Shape public: void draw() cost; // deal with color ad draw lies virtual void move(it dx, it dy); // move the Shape: +=dx ad +=dy Circle Ellipse Ope_polylie Axis Lies Marked_polylie Closed_polylie Marks Image Rectagle Text Fuctio Lie void set_color(color col); color color() cost; Polygo Mark

4 Shape ties our graphics objects to the scree Widow kows about Shapes All our graphics objects are kids of Shapes Shape is the class that deals with color ad style It has Color ad Lie_style members Shape ca hold Poits Shape has a basic otio of how to draw lies It just coects its Poits Shape deals with color ad style It keeps its data private ad provides access fuctios void set_color(color col); Color color() cost; void set_style(lie_style sty); Lie_style style() cost; private: Color lie_color; Lie_style ls; Shape stores Poits It keeps its data private ad provides access fuctios Poit poit(it i) cost; // read-oly access to poits it umber_of_poits() cost; protected: void add(poit p); // add p to poits private: vector<poit> poits; // ot used by all shapes Shape itself ca access poits directly: void Shape::draw_lies() cost // draw coectig lies if (color().visible() && 1<poits.size()) for (it i=1; i<poits.size(); ++i) fl_lie(poits[i-1].x,poits[i-1].y,poits[i].x,poits[i].y); Others (icl. derived classes) use poit() ad umber_of_poits() why? void Lies::draw_lies() cost // draw a lie for each pair of poits for (it i=1; i<umber_of_poits(); i+=2) fl_lie(poit(i-1).x, poit(i-1).y, poit(i).x, poit(i).y);

5 (basic idea of drawig) (implemetatio of drawig) void Shape::draw() cost // The real heart of class Shape (ad of our graphics iterface system) // called by Widow (oly) save old color ad style set color ad style for this shape draw what is specific for this particular shape Note: this varies dramatically depedig o the type of shape e.g. Text, Circle, Closed_polylie reset the color ad style to their old values Note! void Shape::draw() cost // The real heart of class Shape (ad of our graphics iterface system) // called by Widow (oly) Fl_Color oldc = fl_color(); // save old color // there is o good portable way of retrievig the curret style (sigh!) fl_color(lie_color.as_it()); // set color ad style fl_lie_style(ls.style(),ls.width()); draw_lies(); // call the appropriate draw_lies() // a virtual call // here is what is specific for a derived class is doe fl_color(oldc); fl_lie_style(0); // reset color to previous // (re)set style to default is abstract Class shape You ca t make a plai Shape protected: Shape(); For example Shape ss; // protected to make class Shape abstract // error: caot costruct Shape Protected meas ca oly be used from this class or from a derived class Istead, we use Shape as a base class struct Circle : Shape // a Circle is a Shape I class Shape virtual void draw_lies() cost; I class Circle void draw_lies() cost /* draw the Circle */ I class Text void draw_lies() cost /* draw the Text */ Circle, Text, ad other classes Derive from Shape May override draw_lies() // draw the appropriate lies

6 class Shape // deals with color ad style, ad holds a sequece of lies public: void draw() cost; // deal with color ad call draw_lies() virtual void move(it dx, it dy); // move the shape +=dx ad +=dy Display model completed void set_color(color col); // color access it color() cost; style ad fill_color access fuctios Poit poit(it i) cost; // (read-oly) access to poits it umber_of_poits() cost; protected: Shape(); // protected to make class Shape abstract void add(poit p); // add p to poits virtual void draw_lies() cost; // simply draw the appropriate lies private: vector<poit> poits; // ot used by all shapes Color lcolor; // lie color Lie_style ls; // lie style Color fcolor; // fill color draw_lies() draw_lies() Shape Circle draw_lies() Shape Text draw_lies() draw() draw() Widow attach() our code make objects draw() Display Egie wait_for_butto() prevet copyig Laguage mechaisms A simple class hierarchy Most popular defiitio of object-orieted programmig: OOP == iheritace + polymorphism + ecapsulatio We chose to use a simple (ad mostly shallow) class hierarchy Based o Shape Base ad derived classes // iheritace struct Circle : Shape Also called iheritace Virtual fuctios // polymorphism virtual void draw_lies() cost; Also called ru-time polymorphism or dyamic dispatch Circle Ellipse Axis Ope_polylie Shape Lies Image Text Fuctio Lie Private ad protected // ecapsulatio protected: Shape(); private: vector<poit> poits; Marked_polylie Marks Closed_polylie Polygo Rectagle 23 Mark 24 6

7 Object layout Object layout The data members of a derived class are simply added at the ed of its base class (a Circle is a Shape with a radius) Shape: poits lie_color ls fcolor Virtual fuctio implemetatio Ope_polylie: Circle: poits lie_color ls fcolor vptr draw move Shape::draw_lies() Shape::move() Circle: poits lie_color ls fcolor r 25 poits lie_color ls fcolor vptr r draw move Cicle::draw_lies() 26 Beefits of iheritace Access model Iterface iheritace A fuctio expectig a shape (a Shape&) ca accept ay object of a class derived from Shape. Simplifies use sometimes dramatically We ca add classes derived from Shape to a program without rewritig user code Addig without touchig old code is oe of the holy grails of programmig Implemetatio iheritace Simplifies implemetatio of derived classes Commo fuctioality ca be provided i oe place Chages ca be doe i oe place ad have uiversal effect Aother holy grail A member (data, fuctio, or type member) or a base ca be Private, protected, or public

8 Pure virtual fuctios Ofte, a fuctio i a iterface ca t be implemeted E.g. the data eeded is hidde i the derived class We must esure that a derived class implemets that fuctio Make it a pure virtual fuctio (=0) This is how we defie truly abstract iterfaces ( pure iterfaces ) struct Egie // o data // iterface to electric motors // (usually) o costructor virtual double icrease(it i) =0; // must be defied i a derived class virtual ~Egie(); // (usually) a virtual destructor Egie eee; // error: Collectio is a abstract class Pure virtual fuctios A pure iterface ca the be used as a base class Costructors ad destructors will be described i detail i chapters Class M123 : public Egie // egie model M123 // represetatio public: M123(); // costrutor: iitializatio, acquire resources double icrease(it i) override /* */ // overrides Egie ::icrease ~M123(); // destructor: cleaup, release resources M123 widow3_cotrol; // OK Techicality: Copyig Techicality: Overridig If you do t kow how to copy a object, prevet copyig Abstract classes typically should ot be copied class Shape Shape(cost Shape&) = delete; // do t copy costruct Shape& operator=(cost Shape&) = delete; // do t copy assig void f(shape& a) Shape s2 = a; a = s2; // error: o Shape copy costructor (it s deleted) // error: o Shape copy assigmet (it s deleted) 31 To override a virtual fuctio, you eed A virtual fuctio Exactly the same ame Exactly the same type struct B void f1(); // ot virtual virtual void f2(char); virtual void f3(char) cost; virtual void f4(it); struct D : B void f1(); // does t override void f2(it); // does t override void f3(char); // does t override void f4(it); // overrides 32 8

9 Techicality: Overridig To override a virtual fuctio, you eed A virtual fuctio Exactly the same ame Exactly the same type struct B void f1(); // ot virtual virtual void f2(char); virtual void f3(char) cost; virtual void f4(it); struct D : B void f1() override; // error void f2(it) override; // error void f3(char) override; // error void f4(it) override; // OK 33 Techicality: Overridig To ivoke a virtual fuctio, you eed A referece, or A poiter D d1; B& bref = d1; bref.f4(2); // d1 is a D, ad a D is a B, so d1 is a B // calls D::f4(2) o d1 sice bref ames a D // poiters are i chapter 17 B *bptr = &d1; // d1 is a D, ad a D is a B, so d1 is a B bptr->f4(2); // calls D::f4(2) o d1 sice bptr poits to a D 34 Next lecture Graphig fuctios ad data 35 9