Extra Problems + Solutions

Transcription

1 Extra Problems + Solutions 1. The following four sentences define language L. This house is big. This barn stinks. This dog smiles. This student gets good grades. Here are two grammars, G1 and G2, with missing tokens, identifiers, and rule names whose language is L. Fill in the missing holes, where hole h is denoted by <h>: Grammar with holes G1 :- <h1> <h2> <h3> ; <h2> :- <h4> <h5> <h6> <h7> ; G2 :- <p0> <p14> ; N :- <p1> <p6> <p2> <p7> <p3> <p8> <p4> <p9> ; <p6> :- <p10> ; <p7> :- <p11> ; <p8> :- <p12> ; <p9> :- <p13> ; Grammar without holes G1 :- This nv. ; nv :- house is big barn stinks dog smiles student gets good grades ; G2 : N. ; N :- This house v1. This barn v2 This dog v3 This student v4 ; v1 :- is big ; v2 :- stinks ; v3 :- smiles ; v4 :- gets good grades ;

2 2. Here is some application code and 2 classes of a package that it references. Draw the result of moving method doit() of class A to class B via field A.bb, leaving behind a delegate doit() in class A. (a) what is the absolute function of doit( ) A doit(a a, B b) { // parameter (A a) was this in class A // absolute call looks like: doit(alpha,beta) where alpha A and beta B (b) what is the absolute function of doit( ) after the move-via-field refactoring: A doit(a a, B b, B bb) { // move-via-field adds parameter (B bb) so that doit() can be moved to class B (via parameter bb) // note that parameter bb is not used. // absolute call looks like: doit(alpha,beta,gamma) where alpha A, beta B, gamma B application before refactoring class A before refactoring class B before refactoring void main(string[] args) { B b; b = new B(); a2 = new A(); a2.doit(b); A doit(b b) { counter++; return this;

3 move A.doit() to class B via field/parameter bb. application after refactoring class A after refactoring class B after refactoring B b; b = new B(); a2 = new A(); a2.doit(b); // main unchanged since // delegate is called. A doit(b b) { bb.doit(this,b); A doit(a a, B b) { 3. Here is some application code and 2 classes of a package that it references. Draw the result of move method more() of class A to class B via field A.bb. (NO DELEGATE IS TO BE CREATED). See notes on move polymorphic and delegate, even though there isn t much polymorphism in this example. Hint: the answer is not obvious. I suggest that you use Netbeans to type in the problem and perform the move and delegate to see what the real answer is so that you can understand why it is what it is! (a) what is the absolute function of more( ) A more(a a) { a.b a.b (b) what is the absolute function of more after the move via field A more(a a, B bb) { a.b a.b // note param (B bb) was added, but it is NOT used.

4 perform the refactoring: application before refactoring class A before refactoring class B before refactoring a1.more(); a1.more(); a2 = new a().doit(); A more() { b b counter++; return this; (c) after refactoring, an absolute call is more(a,a.bb). When more is in class B, the call is a.bb.more(a); application after refactoring class A after refactoring class B after refactoring void main(string[] args) { a1.bb.more(a1); a1.bb.more(a1); a2 = new A; a2.bb.more(a2); A more(a a) { a.b a.b

5 4. Consider the following application and class hierarchy: application before refactoring class hierarchy before refactoring Visitor before refactoring Poly p1 = new Square(); Poly p2 = new Octagon(); p1.draw(); p2.draw(); class Poly { void center() {.. void draw() { center(); // algorithm to draw // polygon class Square extends Poly { Points p[4]; void draw() { center(); // algorithm to draw square class Octagon extends Poly { Points p[8]; void draw() { center(); // algorithm to draw octagon Show this codebase after a visitor for method draw() has been created: application after refactoring class hierarchy after refactoring Visitor after refactoring Poly p1 = new Square(); Poly p2 = new Octagon(); Visitor v = Visitor.sgl; p1.accept(v); p2.accept(v); class Poly { void center() {.. void accept(visitor v) { v.visit(this); class Visitor { public static Vistor sgl = new Vistor(); void visit(poly p) { p.center(); // alg to draw // polygon class Square extends Poly { Points p[4]; void accept(visitor v) { v.visit(this); class Octagon extends Poly { Points p[8]; void accept(visitor v) { v.visit(this; void visit(square s) { s.center(); // alg to draw // square void visit(octagon o) { o.center(); // alg to draw // octagon

6 5. Given the following class diagram, translate it into Java code (as you d expect a tool to do). Note that field Manifold.all is a static linked list of all Manifold objects that have been created. Now, association fields are by definition private, as indicated below. Override such modifiers as needed (explain justification). Manifold -name -all : LinkedList<> +draw() -inmanifold 1 -segments * Segment -name +draw() -inseg 1 -points * Point -x -y +drawto(in p : Point) class Manifold { private String name; public LinkedList<Segment> segments; // public to be updatable by leaking C. private static LinkedList<Manifold> all = new LinkedList<>(); public Manifold(String n) { name = n; segments = new LinkedList<>(); all.add(this); public draw() { /* TODO */ class Segment { private String name; private Manifold inmanifold; public LinkedList<Point> points; // public to be updatable by leaking C. public Segment(String n, Manifold m){ name = n; inmanifold = m; points = new LinkedList<>(); m.segments.add(this); // leaking public draw() { /* TODO */ class Point { private int x; private int y; private Segment inseg; public Point( int x, int y, Segment s) { this.x = x; this.y = y; inseg = s; s.points.add(this); // leaking public void drawto(point p) {...