• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

The "Do one thing" advice for classes/methods. How strict should we be when designing them?

 
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am reading the Monkhouse & Camerlengo book and I encountered this phrase:

Before building any class, it is worthwhile considering what it is that the class does. The same applies to methods - for each method, try to determine just what the method does. If you find yourself using the word "and" when describing a class or method, there is the possibility that the class or method is trying to be responsible for more than it should. You might then consider whether it makes sense to break a class or method into two or more classes or methods; it might make your code a bit more manageable and maintainable.



But for the Denny's DVD project, this method was used to retrieve all store's inventory:



I do not intend to criticize the authors, but this method clearly does more than one thing because it contains a boolean parameter.

So what is your opinion about this "do one thing" concept? Should we be so strict or should we allow some flexibility in designing classes/methods?
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You should always try to adhere the 1 purpose for class (and method) principle. It will result in a clean design which can be easily tested, maintained, extended,... In short, all advantages of (good) object-oriented design. In practice that's not always possible. And it's a private method, so it's used for internal use only.

But a better design could be to create a similar 2nd method buildRecordNumbers which does exactly what the name suggest. The only drawback of this approach is that you'll have duplicate code (the for loop) with other business logic. That could be solved using a CallbackHandler for each method which performs the actual business logic.

Putting everything together could result in something like this:


But that's maybe a little bit of a design overkill, so for the sake of simplicity you could merge both methods into 1 using a boolean parameter. That brings us back to the original code

Hope it helps!
 
Alexandru Dragoi
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Roel, actually I have put your suggestion into the code for Denny's DVD project and it looks not only cool, but rather...an useful refactoring!

One of the disadvantages of the old design was that whenever you had to build the record numbers (calling getDvdList(true)), every time you ended up not using the return value (i.e. the List<DVD> dvdList). An useless collection of dvd's was filled up with each method call and the garbage collector had to clean this list every time with no sense...

Furthermore, boolean arguments look bad for the reader. Every time when you see a method call with the boolean argument you must look deeper into the code to see what is the use of that boolean argument.

With your proposed design things look more straightforward.
 
reply
    Bookmark Topic Watch Topic
  • New Topic