Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Run to Completion

Run to Completion

Scheduled Pinned Locked Moved Design and Architecture
designgame-devooptutorialquestion
1 Posts 1 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    Leslie Sanford
    wrote on last edited by
    #1

    The concept of Run to Completion means, at least as it pertains to classes, that a method must run to its end before another method can be called on the same object. Adhering to this rule makes it easier to reason about a class's state. I've often seen examples of this rule being broken or just ignored. How often does a class call one of its methods in the middle of another method? I've done this many times, and I've seen code authored by others do the same thing. As long as the method being called is read-only, I don't think RTC is being violated. But when it's a write method, I've wondered if this isn't an indication of a code smell. I was looking at Sams Teach Yourself Object Oriented Programming in 21 Days. In the book is a step-by-step example of designing an object oriented blackjack game. Here's an excerpt of part of the code from that example:

    // In the Player class
    public void play(Dealer dealer)
    {
    while(!isBusted() && hit())
    {
    dealer.hit(this);
    }
    }

    public void addCard(Card card)
    {
    hand.addCard(card);
    notifyListeners();
    }

    public boolean isBusted()
    {
    return hand.isBusted();
    }

    // In the Dealer class
    public void hit(Player player)
    {
    player.addCard(cards.dealUp());
    }

    There's a circular nature to this design which doesn't sit well with me. But setting that aside, what I want to get at is what the player class is up to in the play method. This method passes its instance to the Dealer which in turn calls the Players addCard method. This method adds a card to the player's hand. Back in the play method, the loop checks to see if the hand is busted. It's depending on the Dealer to make a change in its state elsewhere. I don't know; maybe there's nothing wrong with this approach. It just seems fragmented to me. The play method is depending on state changes made via another method that it expects to be called while it (the play method) is still executing. I'm not sure how I would approach this, but I was curious as to whether anyone else sees anything wrong with this.

    1 Reply Last reply
    0
    Reply
    • Reply as topic
    Log in to reply
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes


    • Login

    • Don't have an account? Register

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • World
    • Users
    • Groups