Win a copy of Spark in Action this week in the Open Source Projects forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Righting Software: key design principles

 
Sheriff
Posts: 15733
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Still on the book sample at https://www.informit.com/articles/article.aspx?p=2995357 on Software Design Decomposition.

I've still only done a quick read through the article and will probably go back over a few more times to digest specific sections. The last part about the need for practice really resonates with me, which made me think about principles. When I practice, I always try to tie whatever I do back to key principles. When I'm practicing TDD and working on recognizing smells (potential violations of design principles), I keep principles like SOLID, KISS, DRY, and GRASP in mind. When designing at a higher level, I keep in mind things like decoupling, layering, and ports and adapters.

When practicing volatility-based decomposition, what are some of the key design principles that you use to guide your design choices? What are some "smells" that you watch for to avoid? Also, how much of a factor does being able to refactor your designs play in your process/method?
 
Author
Posts: 12
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu,

Of the various threads you posted today, this one is the most important.
In general, you don't want to just practice, because you may get it wrong and no know it.

To practice correctly, you should do these three things:

*Set specific goals
       Don’t go all over the place. Focus on what you practice now. Avoid going down into the weeds of detailed design and technology.
       Actively look for opportunities to concentrate, to improve, to further your learning.  

*Obtaining immediate feedback
        Is it working? Attack it. See how it handles change. View the guidelines from Chapter 3 on structure, and from Appendix C to see that you have not violated any of the directives and guidelines.
        Share your work with like-minded peers and have them critic it.

*Concentrate on technique as much as outcome
       Design all types of things, not just the current project, to become really good at volatility-based decomposition.
       Learn to do it both efficiently (quickly) and effectively (correctly).


Juval.  
 
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic