Automatic Detection of Missing Abstract Factory Design Pattern in Object-Oriented Code

1

• Automatic Detection of Missing Abstract Factory
  Design Pattern in Object-Oriented Code

as. eng. Calin-Viorel Jebelean
2
Design Patterns

• Design pattern a general solution to a
  frequently occurring design problem that
  guarantees better flexibility, extendibility and
  maintainability of object-oriented code
• 23 such design problems have been identified and
  documented GoF
• A good design often contains many design pattern
  instances
• A bad design surely needs some design pattern
  instances

3
Goals of the Paper

• To propose a methodology for identifying places
  within object-oriented code where a design
  pattern should have been used, but wasnt
• To simply indicate suspect entities, without
  correcting the underlying problem
• Chosen design pattern Abstract Factory
• Chosen programming language Java

4
Abstract Factory AntiPattern (1)

• Symptoms
• Clients depend on a fixed family of products
• Hard to introduce a new family
• No restriction to use products from different
  families

5
Abstract Factory AntiPattern (2)

• Client code (how it looks)
• if product family 1 is chosen then
• new ProductA1()
• new ProductB1()
• else if product family 2 is chosen then
• new ProductA2()
• new ProductB2()
• end if

Client code (how it should look) Factory
factory new Factory2() factory.createPro
ductA() // will create a ProductA2 factory
.createProductB() // will create a
ProductB2
6
The Approach

• ICP of a method Instantiations along one
  Control Path of a method
• An ICP for a method is a set of classes (no
  duplicates are allowed) instantiated along one of
  the control paths of that method
• A method would typically contain many control
  paths, and also many ICPs
• We should compute the ICPs for every method in
  the target project
• Then, the conceptual algorithm would be

7
Conceptual Algorithm

• Let ICP1 and ICP2 be two different ICPs of the
  system
• Then, ICP1 belongs to some method m1 of class C1
  and ICP2 belongs to some method m2 of class C2
• If
• ICP1 contains 2 classes CA1 (ProductA1) and CB1
  (ProductB1)
• ICP2 contains 2 classes CA2 (ProductA2) and CB2
  (ProductB2)
• CA1 and CA2 are brothers
• CB1 and CB2 are brothers
• Then
• (C1 , m1) is a suspect and so is (C2 , m2)

8
The Approach Quick View
OO code (Java)
automatic
Metamodel (Prolog KB)
automatic
manual
Suspects
9
From Sources to Metamodel

• class C extends SC
• public void m(int x, int y)
• new X()
• if (x gt y)
• if (x gt 0)
• new Y()
• else
• new Z()
• new Z()
• else if (y gt x)
• new W()

Prolog metamodel tool generated class(C).
extends(C, SC). method(m,
C). instantiates(m, C, X,
Y). instantiates(m, C, X,
Z). instantiates(m, C, X,
W). instantiates(m, C, X).
10
From Metamodel to Suspects

• suspect(C1, M1, CA1, CB1, C2, M2, CA2, CB2) -
• instantiates(M1, C1, ICP1),
• member(CA1, ICP1),
• member(CB1, ICP1),
• not(brothers(CA1, CB1)),
• brothers(CA1, CA2),
• brothers(CB1, CB2),
• not(member(CA2, ICP1)),
• not(member(CB2, ICP1)),
• instantiates(M2, C2, ICP2),
• member(CA2, ICP2),
• member(CB2, ICP2).

11
Practical Results

• We ran the tools on 4 medium-size projects, one
  of them containing a planted Abstract Factory
  anti-pattern
• Metamodel generation and suspect identification
  were successful in under 2 seconds each
• The largest project successfully analyzed had 35
  Kloc
• The metamodel generator ran out of memory on the
  JDK 1.4.2 sources

12
Conclusions Future Work

• Conclusions
• Abstract Factory identification is feasible on
  large projects if smarter algorithms are used to
  compute ICPs
• Metamodel generation is exponential in the number
  of conditionals, yet, in practical situations,
  this complexity does rarely show up
• Future work
• Improve ICP computation by disregarding classes
  that do not extend other classes
• Improve ICP computation by factoring out classes
  that are instantiated on all or more control
  paths
• Imagine detection strategies for other design
  patterns