Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This presentation provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects.
6. Michael
Feathers
S
Single Responsibility
Principle
Every object should have a single responsibility and
that should be encapsulated by the class
O Open Closed Principle
Software should be open for extension, but closed for
modification
L
Liskov’s Substitution
Principle
Any subclass should always be usable instead of its
parent class
I
Interface Segregation
Principle
Many client specific interfaces are better than one
general purpose interface
D
Dependency Inversion
Principle
Abstractions should not depend upon details. Details
should depend upon abstractions
7. Why Care About Design Quality?
When, due to constraints, I design
quickly and dirty, my project is
loaded with technical debt
9. The City Metaphor
Source: http://indiatransportportal.com/wp-content/uploads/2012/04/Traffic-congestion1.jpg
10. The City Metaphor
“Cities grow, cities evolve, cities
have parts that simply die while other
parts flourish; each city has to be
renewed in order to meet the needs of its
populace… Software-intensive systems
are like that. They grow, they evolve,
sometimes they wither away, and
sometimes they flourish…”
Grady Booch in the foreword for “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014.
19. Initial Journal Paper
Published in Journal of Object Technology (Vol. 12, No. 2, 2013)
S G Ganesh, Tushar Sharma, Girish Suryanarayana. Towards a Principle-based
Classifica4on of Structural Design Smells. In Journal of Object Technology, vol.
12, no. 2, 2013, pages 1:1–29.doi:10.5381/jot.2013.12.2.a1
URL: hLp://www.jot.fm/issues/issue_2013_06/arPcle1.pdf (open access)
33. Discussion Example
// using java.util.Date
Date today = new Date();
System.out.println(today);
$ java DateUse
Wed Dec 02 17:17:08 IST 2015
Why should we get the
time and timezone details
if I only want a date? Can
I get rid of these parts?
No!
34. So What!
Date today = new Date();
System.out.println(today);
Date todayAgain = new Date();
System.out.println(todayAgain);
System.out.println(today.compareTo(todayAgain) == 0);
Thu Mar 17 13:21:55 IST 2016
Thu Mar 17 13:21:55 IST 2016
false
What is going
on here?
37. Refactored Example …
You can use only date,
time, or even timezone,
and combine them as
needed!
LocalDate today = LocalDate.now();
System.out.println(today);
LocalTime now = LocalTime.now();
System.out.println(now);
ZoneId id = ZoneId.of("Asia/Tokyo");
System.out.println(id);
LocalDateTime todayAndNow = LocalDateTime.now();
System.out.println(todayAndNow);
ZonedDateTime todayAndNowInTokyo = ZonedDateTime.now(ZoneId.of("Asia/Tokyo"));
System.out.println(todayAndNowInTokyo);
2016-03-17
13:28:06.927
Asia/Tokyo
2016-03-17T13:28:06.928
2016-03-17T16:58:06.929+09:00[Asia/Tokyo]
40. Refactoring: Practical concerns
“Fear of breaking
working code”
Is management buy-in necessary for refactoring?
How to refactor code in legacy projects (no automated
tests, difficulty in understanding, lack of motivation, …)?
Where do I have time
for refactoring?
41. “Applying design principles is the key to creating
high-quality software!”
Architectural principles:
Axis, symmetry, rhythm, datum, hierarchy, transformation