Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>So it may be impossible to give you a complete answer about "best practices" without knowing more about your domain, but I can tell you that you may be setting yourself up for disaster by thinking about the implementation details this early.</p> <p>If you're like me then you were taught that good OOD/OOP is meticulously detailed and involves <a href="http://en.wikipedia.org/wiki/BDUF" rel="nofollow noreferrer">BDUF</a>. It wasn't until later in my career that I found out this is <strong>the</strong> reason so many projects become egregiously unmaintainable later on down the road. Assumptions are made about how the project might work, instead of allowing the design to emerge naturally from how the code is actually going to be used.</p> <p>Simply stated: You need to being doing <a href="http://en.wikipedia.org/wiki/Behavior_driven_development" rel="nofollow noreferrer">BDD</a> / <a href="http://en.wikipedia.org/wiki/Test-driven_development" rel="nofollow noreferrer">TDD</a> (Behavior/Test Driven Development).</p> <ol> <li>Start with a rough domain model sketched out, but avoid too much detail. </li> <li>Pick a functional area that you want to get started with. Preferably at the top of the model, or one the user will be interacting with.</li> <li>Brainstorm on expected functionality that the unit should have and make a list.</li> <li>Start the TDD cycle on that unit and then refactor aggressively as you go.</li> </ol> <p>What you will end up with is exactly what you do need, and nothing you don't (most of the time). You gain the added benefit of having full test coverage so you can refactor later on down the road without worrying about breaking stuff :)</p> <p>I know I haven't given you any code here, but that is because anything I give you will probably be wrong, and then you will be stuck with it. Only you know how the code is actually going to be used, and you should start by writing the code in that way. TDD focuses on how the code should look, and then you can fill in the implementation details as you go.</p> <p>A full explanation of this is beyond the scope of this post, but there are a myriad of resources available online as well as a number of books that are excellent resources for beginning the practice of TDD. These two guys should get you off to a good start.</p> <ul> <li><a href="http://martinfowler.com/" rel="nofollow noreferrer">Martin Fowler</a></li> <li><a href="http://www.threeriversinstitute.org/" rel="nofollow noreferrer">Kent Beck</a></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload