• 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

Righting Software: key design principles

 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.  
 
I think he's gonna try to grab my monkey. Do we have a monkey outfit for this tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic