3 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free to choose which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free to choose which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free to choose which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.

2 added 7 characters in body
source | link

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free into choose which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free in which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free to choose which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.

1
source | link

Defensive coding in API design generally is about validating input and carefully selecting a proper error handling mechanism. Things other answers mention are also worth noting.

This is actually not what your example is about. You are there limiting your API surface, for a very specific reason. As GlenH7 mentions, when the set of cards is to be used in an actual game, with a ('used' and 'unused') deck, a table and hands for example, you definitely want to put checks in place to make sure each card from the set is present once and only once.

That you designed this with "zones", is an arbitrary choice. Depending on the implementation (a zone can only be a hand, a deck or a table in above example) it might very well be a thorough design.

However, that implementation sounds like an derived type of a more Collection<Card>-like set of cards, with a less restrictive API. For example when you want to build a hand value calculator, or an AI, you surely want to be free in which and how many of each cards you iterate over.

So it is good to expose such a restrictive API, if the only goal of that API is to make sure each card always is in a zone.