2

形式言語とオートマトン理論のコース用の教育ツールの設計と実装を試すために、暇な時間を使うことを考えています。私は、OOPの実装が適切であるかどうか、もしそうであれば、以下に概説する設計の高レベルの改善を誰かが提案できるかどうかを判断しようとしています。

言語分析で明らかになった潜在的なクラスはたくさんあります。いくつか（そして私が基本的な何かを逃したかどうか私に知らせてください）は次のとおりです：文法; 非終端記号; ターミナル; 製造; 正規文法; 文脈自由文法; 状況依存文法; 無制限文法; オートマトン; 州; シンボル; 遷移; DFA; NFA; NFA-ラムダ; DPDA; PDA; LBA; チューリングマシン。

質問1：各種類の文法は、実装で独自のクラスを取得する必要がありますか、または包括的な文法クラスには、それがどの種類の文法であるかを判別するメソッドが必要です（たとえば、「isRegular（）」、「isContextFree（）」など）。 。） （より一般的には、ドメインモデルで少しだけ異なり、動作の点でのみ異なるクラスは、実装の継承によって表される必要がありますか、それとも単に異なる種類の動作を親クラスにプッシュする方がよいでしょうか？）

質問2：「シンボル」、「状態」、「非終端記号」などのようなものは、実装で独自のクラスを取得する必要がありますか、それともこれらはコンテナーによって支配される必要がありますか？ （より一般的には、ドメインモデルの非常に単純なクラスに、実装で独自のクラスを指定する必要があります（たとえば、拡張性のために）。それとも、コンテナークラスにプッシュする必要がありますか？）

質問3：トランジションは実装で独自のクラスである必要がありますか？その場合、各種類のオートマトンをサポートするためにサブクラス化する必要があります（状態が異なるだけでなく、何が起こるかも異なるため）移行中）？ （より一般的には、1つの子と別の子の間に全単射がある2つの抽象的な親クラスを持つことは良い習慣ですか...カップリング？）

結局のところ、これらの決定の多くは単なる設計上の決定であることに気づきましたが、皆さんがOOP設計のベストプラクティスについてどのように考えているかを知りたいと思います。さらに、純粋なOOP設計の質問として「より一般的な」質問をするだけではない理由は、この種のドメイン（言語とオートマトン）の経験がある人々からの特別な視点が欲しいからです。

どんな助けでも大歓迎です。

4

3 に答える 3

2

良いアイデア。最初に手続き型プログラミングで、最初にOOで、後で同様のことを行いました。

回答1：両方。一部の文法またはトークンには特定のメソッドまたは属性がありますが、他の文法またはトークンはすべての文法間で共有する必要があります。

回答2：彼らは独自のクラスを持っている必要があります。altoughtは共通の祖先を共有する可能性があります。

回答3：両方の方法で処理できますが、特定のクラスを定義すると便利な場合があります。他のクラス/オブジェクト間に交差または関連付けが存在することに同意しますが、それらをモデル化することは困難です。「プロキシ」デザインパターンはその一例です。

LEX、Bison、yaccで言語デザインを教えるのは難しいです。私は、ANTLRがコンパイラ関連のものを教えるための優れた設計ツールであることを「聞いた」。

何をしたいですか ？

オブジェクト指向のパーサー/スキャナー？

すでにいくつかありますが、使い方がわかりません。それらの中には、新しいクラスを定義するような新しい文法を宣言するものもありますが、この場合、ルールの宣言には関数型プログラミング（構文）または論理プログラミング（構文）の方が適しています。

ビジュアル関連ツール：

http://www.ust-solutions.com/ultragram.aspx

http://www.sand-stone.com/

http://antlr.org/

http://antlr.org/works/index.html

幸運を ;-）

于 2011-08-02T15:13:38.907 に答える
2

より一般的には、ドメインモデルで少しだけ異なり、動作の点でのみ異なるクラスは、実装の継承を介して表される必要があります...

行動は「ただ」ではありません。動作はオブジェクトの最も重要な部分です。

または、単にさまざまな種類の動作を親クラスにプッシュする方がよいでしょうか。

確かに違います。それはリスコフの置換原則の違反になります。
継承は、「一般的なものへのより簡単なアクセス」のために使用されるべきではありません。

親クラスのコンテンツは、子クラスと完全に遍在し、継承を回避し、子がそれを遵守しない場合は構成を使用します。

より一般的には、ドメインモデルの非常に単純なクラスに、実装で独自のクラスを指定する必要がありますか（たとえば、拡張性のために）、それともコンテナクラスにプッシュする必要がありますか？

それはあなたの論理がどれだけ「深く」なるかに依存します。

通常、いくつかの制限に達したときにのみ分解を開始することをお勧めします。
それを進化的デザインと呼ぶ人もいます。

例-「クラスは最大200行のコードを超えてはならない」、「オブジェクトは5〜7行を超える他のオブジェクトと通信してはならない」、「メソッドは最大10行のコードを超えてはならない」、「同じロジック一度だけ書くべきだ」など。

また、セマンティクスを過小評価するのは簡単です。if order.isOverdue()よりもはるかに読みやすく、理解しやすいですif order.dueDate<date.Now()。ドメインの概念を反映するクラスを導入すると、コードが大幅に「人間化」され、抽象化レベルが向上します（「asm vsjava」を考えてください）。

しかし、分解のための分解は不必要な複雑さにつながります。
それは常に正当化されなければなりません。

実装でTransitionを独自のクラスにする必要があります。その場合、各種類のオートマトンをサポートするためにサブクラス化する必要があります（状態が異なるだけでなく、遷移中に発生することも異なるため） ？

それがあなたのドメインに準拠している限り、それは何も悪いことではありません。

抽象化の作成は、ドメインに大きく依存する芸術的な活動です（たとえば、コードがコースの教育ツールであると想定されているという要件を忘れた場合、形式言語とオートマトンの専門家からのアドバイスは非常に複雑になる可能性があります）。

于 2011-08-02T16:21:03.897 に答える
2

既存のソリューションを作成する代わりに使用したい場合は、NCSUの友人が、法案に適合する可能性のある ProofCheckerというツールを作成しました。

これはJavaで書かれているので、OOの角度も満たす可能性があります。

于 2011-08-02T20:56:39.593 に答える