Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

The Most Common Design Smell

 
Ranch Hand
Posts: 282
Eclipse IDE PHP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

What is the most common design smell that you've seen in Java? What is the mistake that people make the most, in your experience?

Thank you.
 
Author
Posts: 63
6
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's non-trivial to point out one out of 25 design smells (discussed in our book). However, I can provide a set of most commonly occurring smells that I have seen in my experience:
- Multifaceted Abstraction (when an abstraction has more than one responsibility assigned to it)
- Deficient Encapsulation (when the declared accessibility of one or more members of an abstraction is more permissive than actually required)
- Insufficient Modularization (when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both) - commonly referred as God Class.
- Rebellious Hierarchy (when a subtype rejects the methods provided by its supertype(s))
 
Author
Posts: 93
14
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am just adding to Tushar's list of smells.

One of the most common smells I have seen is duplicates of various forms - for example, in names, methods, classes, and in hierarchies. Two smells from our book relating to duplication:

Duplicate abstraction: This smell arises when two or more abstractions have identical names or identical implementation or both.
Unfactored hierarchy: This smell arises when there is unnecessary duplication among types in a hierarchy. There are two forms of this smell:
Duplication in sibling types: Sibling types in the hierarchy have similar code segments that can be moved into one of their supertypes.
Duplication in super and subtypes: There are similar code segments in super and subtypes indicating redundant code in the subtypes.

For example, 21–29% of the code is duplicated - hold your breath - in JDK Reference. You can see some of the code clones in JDK here: PMD CPD JDK Clones

A common smell that is typically overlooked is the duplication in names. For instance, JDK has numerous classes with identical names. Specifically, of the 4005 types in Java 7, 135 type names are duplicates, which is a substantial 3.3%! Example: javax.swing.Timer, java.util.Timer, and javax.management.timer.Timer. When base class and derived class names are same (e.g., classes java.util.Date and its derived class java.sql.Date), it causes difficulty in understanding. Though duplicate type names may not be a problem in most contexts (it may even be desired, as in case of Domain Driven Design, for example which recommends bonded contexts Bounded Context in DDD), it does cause problems in practice. For instance, I have come across a situation where a runtime exception was uncaught because the names of the exceptions were same but were in different package.
 
Sheriff
Posts: 16940
286
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The one that I see most often is improper assignment of responsibilities. Related smells:
1. Too many responsibilities - violating the Single Responsibility Principle (SRP)
2. Too few responsibilities - Anemic Domain Model, data structures posing as objects
3. Non-cohesive and/or incoherent APIs - violating SRP and/or the Interface Segregation Principle (ISP)
4. Violations of GRASP - https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)
 
Michael Angstadt
Ranch Hand
Posts: 282
Eclipse IDE PHP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your responses.

Wow, I didn't know that so much of the JDK code base has duplicate code! Was that OpenJDK or some other implementation?

I agree with S G Ganesh about identical class names. In theory, you should keep your class names as short and concise as possible. After all, their package names will differentiate them from other classes in other packages that have the same name. But in practice, it can be annoying if you are using two identically named classes from different packages inside of the same class. Then, you're forced to identify at least one of the classes using its fully-qualified name, which is super annoying.
 
Blueberry pie is best when it is firm and you can hold in your hand. Smell it. And smell this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic