yonatankarp/software-design-skills

gof-iterator

Use when traversing a collection without exposing its internals — phrases like "Iterator pattern", "the menus use different internal structures but the diner shouldn't care", "encapsulate iteration", "hide whether it's an array, list, or hash map".

ソースを見る

使い方

  1. インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
  2. 必要なツール、認証情報、対応環境を原文で確認します。
  3. 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/yonatankarp/software-design-skills --skill gof-iterator

開始前の確認

  • 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
  • スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文

見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。

One-line summary

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

When to use this skill

  • Multiple aggregate types must be traversed uniformly even though they use different internal structures (one uses an array, another a hash map, a third a linked list).
  • A method consumes a collection but should not depend on which concrete collection type it is.
  • Implementing a custom collection that needs to be traversable in client code (a tree, a graph, a paginated remote dataset).

When NOT to use this skill

  • The language already gives you iteration over standard collections (every modern language does) and you're not designing a custom collection — just use the language's for-each / iteration.
  • The "iteration" is really a transform or filter pipeline — that's a higher-level concept; reach for the language's streams / sequences.
  • You need random access, not sequential access — Iterator is sequential by definition.

Core content

The pattern separates two concerns:

  • The Aggregate owns the data and knows its internal structure.
  • The Iterator knows how to walk that structure one element at a time.

The aggregate provides a method (typically iterator()) that returns a fresh Iterator. The Iterator implements the standard interface (hasNext(), next(), occasionally remove()).

Multiple iterators may exist over the same aggregate at the same time, each tracking its own position — that's why iteration state belongs to the Iterator, not the aggregate.

The pattern is so foundational that virtually every modern language has it built into the language and standard library. Kotlin, Java, C#, Python, Swift, Rust, JavaScript — all have Iterator or Iterable interfaces and for loops that consume them.

Decision heuristics

  • For built-in collections, never roll your own Iterator — the language provides one.
  • When designing a custom collection or stream, implement the language's standard Iterator interface so client code can use idiomatic iteration (Kotlin for over Iterable, Java for-each, Python for x in y).
  • For a one-time traversal that filters or transforms, prefer a stream / sequence over a stateful iterator.

Anti-patterns

  • Exposing the underlying collection (getInternalList()) and letting callers iterate it directly — defeats encapsulation; callers depend on the concrete type.
  • Iterators that mutate the aggregate during traversal in ways the aggregate didn't sanction — usually causes concurrent-modification bugs.
  • Custom iterators that don't match the language's standard interface — forces client code into bespoke patterns.

See also

  • gof-composite — Iterator is the natural way to walk a Composite structure.
  • gof-kotlin-idioms — Sequence, Iterable, the Iterator<T> interface, and iterator { yield(x) } builders are first-class; rolling your own iterator class is rarely the right move.

References

  • Head First Design Patterns (2nd ed), Ch. 9 ("Well-Managed Collections: the Iterator and Composite Patterns") — the canonical chapter, framed around two restaurants merging menus stored in different data structures.

タスクに関連する項目

同じリポジトリから

関連する Skills

すべての Skills
yonatankarp
コミュニティ

arch-adr

Use when recording an architectural decision so future maintainers know why — phrases like "ADR", "architecture decision record", "why did we pick X", "lightweight architecture documentation", "decision log", "should this be an ADR", "tribal knowledge", "we chose this two years ago and now nobody remembers why". Defines the ADR as a short, structured document capturing what was decided, why, alternatives considered, and consequences — written at the time of the decision and kept in the repo.

導入数
2
GitHub Stars
1
更新日
5月19日
yonatankarp
コミュニティ

arch-fitness-functions

Use when enforcing architectural characteristics through automation — phrases like "architecture fitness function", "evolutionary architecture", "architecture tests", "ArchUnit", "dependency rules in CI", "automated architecture checks", "guardrails", "drift detection". Defines fitness functions as automated checks that verify architectural characteristics on every change, catching drift before it accumulates.

導入数
2
GitHub Stars
1
更新日
5月19日
yonatankarp
コミュニティ

arch-microservices

Use when designing or reviewing a microservices architecture — phrases like "microservices", "should we split this service", "service boundaries", "bounded context per service", "API gateway", "backend for frontend", "BFF", "service mesh", "microservices vs monolith", "database per service", "data ownership". Defines microservices as independently deployable services aligned with business capabilities — and the discipline of resisting the style until the monolith proves inadequate.

導入数
2
GitHub Stars
1
更新日
5月19日
yonatankarp
コミュニティ

arch-strangler-fig

Use when migrating a legacy system incrementally — phrases like "strangler fig", "strangler pattern", "incremental migration", "monolith to microservices", "rewrite without big bang", "replace legacy in place", "facade in front of the legacy system", "anticorruption layer". Defines Fowler's Strangler Fig as the migration discipline of gradually replacing legacy functionality behind a stable facade, never doing a big-bang rewrite.

導入数
2
GitHub Stars
1
更新日
5月19日