Retired

Open a weak chest. (retired)

51nevepura
Description
Loading description...
Puzzles
View
AllIssues3Questions1SuggestionsShow Resolved
  • Please sign in or sign up to leave a comment.
  • Sleibefehler Avatar

    I really like this Kata, but in my opinion the fact that the BadCodeException will get thrown out if the inputCode for unlocking the chest is wrong should be writen in the description, as this wasn't immediately clear to me.

    • nevepura Avatar

      Thanks for the feedback. However, I think that the core of the problem is getting this surprise exception and finding out how to deal with it. So the description is not talkative on purpose.

  • yLaWy Avatar

    Personally, I think this kata should be a 7 kyu kata because it contains only "basic functional or object-oriented concepts" (as the 7 kyu kata difficulty description says). It's not an issue whatsoever, but maybe something that can be changed to be more coherent(?).

  • dinglemouse Avatar

    you see, a WeakChest can be opened with a specific integer code between 0 and 999

    Does this mean we can we assert that all chests are openable, or might there be some chests that can't be opened even after testing every possible code?

  • FArekkusu Avatar

    Why does lockpick have throws BadCodeException in its declaration if it's supposed to open a chest successfully?

    • nevepura Avatar

      It is supposed to open a chest successfully if given the correct code. Otherwise it won't open and throw the declared exception.

    • FArekkusu Avatar

      What are you talking about? lockpick doesn't receive any codes - it generates them itself.

    • nevepura Avatar

      You are right. The throws is not needed in lockpick(). At some point in your solution you may want to put it, but neither at the start nor in the end. I fixed it, thanks.

    • nevepura Avatar

      Marking as solved

      Issue marked resolved by nevepura 4 years ago
  • FArekkusu Avatar

    lockpick should be static.

    • nevepura Avatar

      I don't agree. I think it's the Burglar who lockpicks, so the functionality should belong to an instance Burglar, and not be available externally as a static utility method. For example, if a burglar had a skill level, the lockpick() could depend on it's skill. It's not this case, but it could be possible. Why do you think it should be static?

    • FArekkusu Avatar

      For example, if a burglar had a skill level, the lockpick() could depend on it's skill. It's not this case, but it could be possible.

      So you're saying that lockpick should be an instance method because if the Burglar class actually had instance-specific code, even though IT DOES NOT HAVE ANY, it would not be possible to make it static? Is this a joke?

    • nevepura Avatar

      First of all, there is no need to shout. Second, it is technically possible to make it static, but functionally it is not correct. Because it is the burglar who lockpicks. new Burglar().lockpick() and Burglar.lockpick() they both work. But in the first case there is a Burglar who lockpicks; in the second case it's a functionality that anyone can call, without being a Burglar. I want only burglars to be able to lockpick. So from my point of view it's technical vs functional. Exercise-wise, it makes no difference, so let's leave it as it is.

      Issue marked resolved by nevepura 4 years ago
  • dfhwze Avatar

    Lack of description. What would expected behavior be when a bad code gets chosen when the chest is already open, and does such further attempts even make sense?