[集合向けフレームワーク設計]についての説明

私は概念層の推演に慣れており、述べたものの多くは私たちが創造した過程の副産物であり、業界でよく見られる観念とは実際には大きな違いがある.似たような視点を採用していないか、独立して多くの問題を考えたことがないからだとは思えません.もしあなたが従業内ですでによく知っている概念だけで私の書いた内容を理解しようとしたら、明らかに不可能なことです.だから私はよく言います.
新しいアプリケーションを作成している場合は、多くのコードが存在する可能性があります.

myFunc(){
  for each x in set
    doSomethingValuable(x);
  return packedResult;
}

myOtherFunc(packedResult){
  for each y in pakedResult
    doSomethingOther(y)
}

実は私たちが本当に関心を持っているのはループの内部のある過程ですが、私たちはよくそれらがいくつかの汎用的または特定のループ(集合遍歴)操作に囲まれていることを観察することができます.Witrixの設計方式は業務の関心点を強調し、すべての要約操作をできるだけ抽象的に完成させることである.たとえば、インタフェースにフィールドが表示されます.抽象的な操作から言えば

  for each field in dsMeta.viewableFields
    show field.viewer

このプロセスはプラットフォームコードで実現され、汎用的な集合操作プロセスである.異なる具体的な応用は、特定のフィールドの表示形式に関心を持っているだけで、フィールドの集合が必要ですが、私たちの注意力の重心ではありません.
フィールドがインタフェースに表示されるレイアウトの問題を考慮すると、コレクション内の構造方法を変更します.

          （dsMeta.         ）
    show field.viewer

集合を抽出することは,実際には構造問題と内容問題を最大限に分離することである.    
構造は抽象的で、独立した意味を持っている.これがWitrixが提案した構造向けの設計の視点である.オブジェクトのいわゆるビジネスの意味を強調するのではなく、ある共通言語(例えばruby)の柔軟な文法構造を強調するのではありません.この間には物理的意義を持つ構造解析が可能な技術層が厚く存在する.[url]http://canonical.iteye.com/blog/60758 [/url]
http://canonical.iteye.com/blog/126467
stream styleはストリームにコンテンツを追加し続ける、o.put(y).put(z).put(t)という方式は、jQueryのコードを見ればわかります.
SAXのイベント駆動方式とモードマッチング能力を組み合わせることは確かに局所的に変換論理を直接適用することができるが,状態空間の協力が欠けており,複雑な問題に直面すると力不足である.