高階プログラミング

配列および集合に基づくパイプライン技術の探求

配列および集合ベースパイプライン技法の探求

アンチパターンか？

これはすべてを配列としてコーディングすることによって得られる利点の探求です。(SmallTalkのジェダイ的な概念を借りています)

以下の指針があります:

1. すべての入力は配列に似た構造です。たとえ要素数が1つの配列でも。

2. 高位の関数は一般に配列を受理し、配列を返却するべきです。(ループのコールバックメソッド: map/reduce/each/filter は例外)

3. 100人の開発者のうち99人は私が言う「鋭意スキーマ過剰症候群」に悩まされています。

4. 膨れ上がったクラスベースモデルに注意してください - 予測可能な特徴がついています: 脆弱なインスタンス状態があり、調整すべきレバーとノブが多数あり、DBトランザクション、SQLロック、async/mutexing(最初から完璧に動く)、イディオム的なプロパティゲッター/セッターを使用し、public/private/final/などのアクセス修飾子の使い方も完璧ですよね？

5. では、共通の問題をとりあげて、~~~add~~~集合ベースの考察を強引に組み込みましょう。

6. 要素数の多い仮想のブログサイトがあり、記事(Article)が多数、コメント(Post)がさらに多数あります。

7. 以下のdeleteメソッドを追加しましょう - ただし、単一値と配列の両方をサポートします。

package net.danlevy.why.java___why.you.got.all.the.dots____it.must.be.all.the.factories;

public class Post {
  public String   title;
  public Date     created;
  public String   message;

  public Post(String title, String message) {
    this.title    = title;
    this.message  = message;
    this.created  = new Date();
  }

  public Date isArchived() {
    return this.created < new Date(2015, 0, 1);
  }

  // Post.deleteは、単一のPostまたはPost[]配列で呼び出すことができます
  public static int delete(Post post) {
    List<Post> posts = new List<Post>(post);
    return delete(posts)
  }

  public static int delete(List<Post> posts) {
    return posts.map(Dao.remove);
  }
}

私のJavaが少し錆びついていたら、ご容赦ください。