12

オブジェクト指向プログラミングを概念として使用することの長所と短所を理解しています。私が探しているのは、具体的には oo in progress/openedge を使用することの長所と短所です。考慮しなければならない課題はありますか? oo とうまくかみ合わない言語の部分はありますか? そのようなもの。

編集：10.2bを使用

4

3 に答える 3

19

私はあなたに私の意見を述べますが、私はおそらくそこにいる最大のプログレス嫌いであることを事前に警告しておいてください. ;) そうは言っても、私は OOABL でいくつかの中規模のプロジェクトを書いているので、この分野での経験はある程度あります。以下は私が書いたものです。

  • クライアントとサーバーの STOMP プロトコル フレームワーク
  • ActiveRecordを模倣した単純な ORM
  • 私が所属していた組織の ABL コンパイラ インターフェイス (バックエンドとフロントエンド)
  • Excel および Word ドキュメントを構築するためのライブラリ (MS Office 2003 XML スキーマを使用してそれらをシリアル化します。そのばかげた COM のものはありません)
  • 複数の戦略を使用して電子メールを送信できる電子メール クライアント

OOABL 長所:

  • 絶対に Progress コードを書かなければならない場合、これは再利用可能なコードを作成するための優れたオプションです。
  • 既存の手続き型コードベースをクリーンアップする優れた方法

OOABL 短所:

  • クラス階層は制限されています。10.2B では継承された (サブ) インターフェイスを作成できません (これは 11 で追加される予定だったと思います)。OpenEdge の古いバージョンには、抽象クラスの欠如などの他の制限があります。これにより、クリーンな OO 設計を作成する能力が制限され、自明でないものを構築し始めると問題が発生します。
  • エラー処理はひどいものです - CATCH/THROWでは、カスタム エラーをスローして、発信者に強制的にエラーをキャッチさせることはできません。下位互換性により、これ以上の進化が妨げられているため、改善されるとは思えません。
  • オブジェクトのメモリ フットプリントが大きく、その理由を突き止めるための AVM デバッグ ツールがありません (これらのクローズド システムが気に入らなければなりません!)。
  • ガベージ コレクションは 10.2A まで存在せず、11 でもまだいくつかのバグがあります (いくつかの例については、公式の OE フォーラムを参照してください)。
  • ネットワーク プログラミング (ソケットを使用) は PITA です。ソケットを管理するには、別の永続的な手順を実行する必要があります。OOABL でのイベント プログラミングは一般的に PITA だったと思います。「ウィンドウ化された環境」またはそれに関連するものを使用しようとすると、多くのエラーが発生したことを覚えています。PUBLISH/SUBSCRIBEメモリが機能する場合、どちらも機能しませんでした。
  • ほとんどの Progress 開発者は OOABL を行わないため、コードを理解できない可能性があるため、環境によってはコード レビューが難しい場合があります。
  • 上記の点が当てはまる場合、新しいことを学ばなければならないことに脅威を感じている定着した開発者からの積極的な抵抗に直面する可能性があります。

OO とは、再利用可能な小さなピースを構築して、組み合わせてより大きな全体を作ることです。OOABL の大きな問題は、「ABL」の部分が粗いデータ構造と列挙子の欠如によって足を引っ張られることです。これにより、本当に美しいものを構築することができなくなります。残念ながら、これはクローズド言語であるため、処理された手を回避して独自の新しいデータまたは制御構造を外部で作成することはできません。

現在、理論的には、MEMPTR、固定配列 (EXTENT)、およびおそらく WORK-TABLE を使用して、これらのいくつかを試して構築することが可能です。しかし、これを 10.1C で試みたところ、インターフェイスの継承と抽象クラスがないために設計が崩れてしまい、予想どおり、パフォーマンスはかなり悪かったです。後半は私の能力不足によるものかもしれませんが、実装上の制約であり、克服するのは不可能に近いのではないでしょうか。

肝心なのは、OpenEdge でコーディングする必要がある場合は、OOABL を使用することです。これは、手続き型 ABL よりも優れており、OpenEdge のリリースが繰り返されるたびに、粗いエッジが少し滑らかになります。ただし、それが美しい言語になることは決してありません (オブジェクト指向であろうとなかろうと)。

適切なオブジェクト指向プログラミングを学びたいが、ABL に縛られていない場合は、Ruby や Smalltalk など、オブジェクトを第一級市民として扱う言語を検討することを強くお勧めします。

于 2012-04-24T18:54:07.630 に答える
8

過去 4 年間、私は 80% の時間を OOABL (10.1c から開始) で作業してきました。私は間違いなく OOABL を使用することをお勧めしますが、OOABL を他の OO 言語と同じように使用すると問題が生じることを考慮することが非常に重要だと思います。「同じ方法」とは、OO の世界で一般的な設計パターンと実装方法を意味します。また、特に技術的なフレームワークの分野で、いくつかのタイプのアプリケーションは、OpenEdge では処理が困難です (ORM など)。

原因は、OOABL のパフォーマンスの問題と、言語の OO 機能の欠落です。

たとえば C# や Java でプログラミングしている場合、多くの場合、メモリ フットプリントとオブジェクトのインスタンス化時間は大きな問題にはなりません。ABL を使用すると、これはより頻繁に大きな問題になります。これは、他の設計上の決定につながり、一部のパターンとフレームワークの実装を妨げます。

不足している、または不適切な OO 機能の一部:

  • oo にはクラス ライブラリもデータ構造も必要ありません
  • Java のようにパッケージの可視性がない (c# の内部) これは、特に大規模なアプリケーションに関連します。
  • ジェネリックなし
  • 本当にひどい例外処理
  • 非常に制限されたリフレクション機能 (oe11 で改善)

したがって、他の言語での oo プログラミングに慣れていて、OOABL を使い始めると、そこにあるはずの多くの機能が欠けているところに到達し、そのような機能を ABL で実装しようとするとイライラする可能性があります。

アプリケーションを Windows のみで実行する必要がある場合は、C# で新しい oo コードを実装し、clr ブリッジを介して既存の進行状況コードから呼び出すこともできます。これは非常にスムーズに機能します。

于 2012-04-29T20:14:21.970 に答える
3

K+

唯一のこと-「エラー処理がひどい」-それはひどいですが、独自のエラークラスを呼び出し元ブロックでキャッチできないからではありません-それは機能します、私はそれを使用しています。ひどいのは、古い NO-ERROR / ERROR-HANDLE オプションと Progress.Lang.Error / CATCH ブロックと ROUTINE-LEVEL ON ERROR UNDO, THROW が混在していることです。チーム内に規則が存在しない場合、どのエラー処理をどのように使用するかは大きな問題です。

于 2012-04-25T07:58:42.147 に答える