SE 333/433 Software
Testing & Quality Assurance Code-smells and bad-design practices
1
Last Week
2
Functional vs Non-Functional Requirements
Functional Requirements
Non-Functional Requirements
Execution Time
Size
Battery
Functionality of the program
Memory
3
– Text chat
– Friends list
4
– Text chat – Voice
– Friends list Communication
5
– Text chat – Voice
– Friends list Communication
6
– Text chat – Voice
– Friends list Communication
-Execution time
-Battery consumption
-Size
7
– Text chat – Voice
– Friends list Communication
-Execution time
-Battery consumption
-Memory leak
-Size
8
Functional Requirements
humans have to define these
Non-Functional Requirements
a machine can optimize these
9
Functional Requirements
humans have to define these
Non-Functional Requirements
a machine can optimize these
10
• Software Refactoring:
• Antipatterns Detection
• Antipatterns Correction (Refactoring Recommendation)
11
Another System Model (Data- Bases)
Model transformation
System Model (in UML)
Program (in Java)
Forward engineering
Model space
Source code space
12
Reverse
engineering m
Refactoring
Anothe r Progra
(Java)
• Refactoring
– The process of improving a code after it has been written by changing its internal structure without changing the external behavior (Fowler et al., ‘99)
– Examples: Move method, extract class, move attribute, …
• Two main refactoring steps
1.detection of code fragments to improve (e.g., Anti pattern) 2.identification of refactoring solutions
13
Learning objectives
• Anti-patterns: Overview
• Examples of anti-patterns
• How to detect anti-patterns using quality metrics?
Design defects/antipatterns
• Design defects/antipatterns are poor coding and design choices introduced during different phases of software development
• Anomalies, code smells , bad smells…
• Make the design harder to understand, to change
• Design situations that adversely affect the development of a software (not bugs)
15
Management Antipatterns
16
Examples of antipatterns
• Duplicated code
• Long method
• God class
• Long parameter list • Message chain
• Data class
• Functional decomposition •…
17
• Definition
The Blob (God Class)
– Procedural-style design leads to one object with numerous responsibilities and most other objects only holding data or executing simple processes.
• Symptoms
– A Blob is a controller class, abnormally large, with almost no parents and no children. It mainly uses data classes, i.e. very small classes with almost no parents and no children (Brown et al. ’98).
18
• Causes
• Lack of an object-oriented architecture.
• Inadequate understanding of OO principles • Lack of (any) architecture
• Design, interaction between object etc. • Too limited intervention
19
Duplicate Code or
Cut and Paste Programming
• Code reused by copying source statements leads to significant maintenance problems.
• Duplicate methods in subclasses
• Duplicate expressions in same class
• Duplicate expressions in different classes
20
21
Large method
• A method that does more than one thing • Many things, sometimes unconnected things
• Problems
• Could indicates low levels of abstraction, low level of class design,
reduced re-usability
• Harder to test, poor readability
22
Long Parameter List
• Introduce parameter object
• Only worthwhile if there are several methods with same
parameter list, and they call each other
user= userManager.create(USER_NAME,group, USER_NAME, “test”, Language, false, false, new Date(), “blah”, “new Date())
23
Message Chain
• Long list of method calls:
• customer.getAddress().getState()
• window.getBoundingbox().getOrigin().getX()
24
Message Chain
25
Data Class/Lazy Class
• Class has no methods except for getter and setters
26
Switch statements
• Switch statements are very rare in properly designed object- oriented code
• Therefore, a switch statement is a simple and easily detected “bad smell”
• Of course, not all uses of switch are bad
• A switch statement should not be used to distinguish between various kinds of object
27
Example 1, continued
• class Animal {
final int MAMMAL = 0, BIRD = 1, REPTILE = 2; int myKind; // set in constructor
…
String getSkin() {
switch (myKind) {
case MAMMAL: return “hair”; case BIRD: return “feathers”; case REPTILE: return “scales”; default: return “skin”;
} }
}
Example 1, improved
class Animal {
String getSkin() { return “skin”; } }
class Mammal extends Animal {
String getSkin() { return “hair”; } }
class Bird extends Animal {
String getSkin() { return “feathers”; } }
class Reptile extends Animal {
String getSkin() { return “scales”; } }
Dead Code/ Old Baggage
• Description
• System contains many classes whose purpose is not known
• Lava Flow, Dead Code
• Much of the code is left over from previous ideas and no longer has a purpose
• was once fluid and useful, now is solid lava that you are afraid to remove
• Consequences
• difficult to maintain, just gets worse
30
Comments?
• The purpose of comments should be only “why you are doing something (to help future modifiers_ rather than “what code is doing”
• Whenever possible make your code express the intent of the comment and remove the comment.
• Comments are to provide intent that is not expressible in code
• Any comment that duplicates what the code says should be deleted
31
32
Shotgun Surgery
• This happens when, you want to make some kind of change, your are forced to make a lot of changes to a lot of different classes
• And when changes are all over the place, they are hard to find, and it’s easy to miss an important change
33
Functional Decomposition
• Description
• Classes with names ‘’functions”
• All class attributes are private and are used only inside the class • Classes with a single action similar to a procedural function.
• Consequences
• No O/O benefits such as inheritance and polymorphism • Expensive to maintain
• Complexity of testing software • Complexity of reuse of the code
34
Spaghetti code
• Description
• System hard to debug, modify
• Bunch of code similar in structure to a bowl of spaghetti.
• Bad coding practices
• Consequences
• Low readability
• Impossible to understand how it exactly works
35
Feature envy
• When a method seems more interesting in a class, other than the one in actually it is
• Example : a method that invokes half a dozen getting methods on another object to calculate some value.
36
37
Class Activity
See additional file added on d2l
38