進歩のためのオブジェクト指向プログラミングの長所と短所

Question

私は概念としてオブジェクト指向プログラミングを使用することの長所と短所を理解しています。私が探しているのは、進行中のOpenOを使っていることの長所と短所です。私が考慮する必要がある課題はありますか？ ooとよく噛み合わない言語の部分はありますか？そのようなもの。

編集：10.2b

Answer 1

を使用して、私はあなたに私の意見を与えるでしょうが、私はそこに、おそらく最大の進捗嫌いだということあらかじめご了承ください。 ;）つまり、私はOOABLにいくつかの中規模のプロジェクトを書いているので、私はこの分野でいくつかの経験を持っています。これらは、あなたが、私は私の帽子のうちの話ではない知っているだけので、私が書いたいくつかのものです：クライアントとサーバのための

• STOMPプロトコルのフレームワーク
• ActiveRecord
• のためのABLのコンパイラインターフェイスを模倣する簡単なORM組織私は（バックエンドとフロントエンド）にあった
• ExcelとWord文書を構築するためのライブラリ、電子メールを送ることができ（MS Office 2003のXMLスキーマを使用してそれらをシリアライズその愚かなCOMのもののどれも）
• 電子メールクライアント複数を使用してstrategies

OOABL長所：

• あなたは絶対に進行コードを書かなければならない場合は、再利用可能なコードを作成するための素晴らしい選択肢です。

OOABL短所既存の手続きのコードベースをクリーンアップする

グレート方法：

• クラス階層が限られています。 10.2Bの継承された（サブ） インターフェースを作成することはできません（これは11で追加される予定でした）。 OpenEdgeの より古いバージョンには、抽象的な クラスの欠如のような他の制限があります。これにより、きれいなオブジェクト指向設計を作成する能力が制限され、 あなたは怪我をしないことを構築するときにを傷つけるでしょう。
• エラー処理sucks - CATCH/THROWは、あなたのカスタム エラーを投げて、呼び出し元にそれらをキャッチさせません。下位互換性 はこれがさらに進化するのを防ぎます。
• オブジェクトのメモリフットプリントが大きく、何のAVMのデバッグはなぜ追跡する ツールはありません（お奨めは、これらのクローズドシステムを愛するが！）
• ガベージコレクションは、「10.2Aゴマ存在し、まだ ていなかったにもいくつかのバグを持っていますいくつかの例については公式OEフォーラムを参照してください。
• ソケットを管理するネットワークプログラミング（PITA）は、 別の永続的な手順を実行する必要があります。私はOOBLでプログラミングされた は一般的にピタだったと思います。私は、「ウィンドウ環境」やそれを使用しようとしたときにその影響を受けるものについて、多くのエラーが発生したことを覚えています。/SUBSCRIBEは動作しませんでした。 メモリが使用されている場合。
• 最も 進捗開発者がそうOOABLをしないよう、ご使用の環境によっては、コードレビューは難しいかもしれないが、あなたのコードを理解していない可能性が
• 上記の点がtrueの場合は、脅威を感じ 定着し、開発者からの活発な抵抗に直面する可能性があります新しい を学ばなくてはならない

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

ここでは理論的にはですが、MEMPTR、固定配列（EXTENT）、多分WORK-TABLEを使ってこれらのことを試してみてください。しかし、私はこれを10.1Cで試みましたが、インターフェイスの継承と抽象クラスがないためにデザインが分断されました。予想通り、パフォーマンスはかなり悪いものでした。後者の部分は私の貧弱な能力に起因するかもしれませんが、それは克服することは不可能であるという実装上の制限だと思われます。

OpenEdgeで絶対にコーディングする必要がある場合は、最終的にはOOABLを使用してください。手順上のABLよりも優れており、OpenEdgeの反復リリースごとに粗いエッジが少しスムーズになります。しかし、それは決して美しい言語（OOまたはそれ以外）ではありません。

オブジェクト指向のプログラミングを習得し、ABLに限定されていない場合は、オブジェクトをRubyやSmalltalkなどの第一級の市民として扱う言語を検討することを強くおすすめします。

Answer 2

K +

ひとつだけ - 「エラー処理が吸う」 - それは吸うではなく、あなた自身のエラー・クラスを作ることができないので、呼び出し側のブロックでキャッチして - 私はそれを使用しています、動作します。古いNO-ERROR/ERROR-HANDLEオプションとProgress.Lang.Error/CATCHブロックとROUTINE-LEVEL ON ERROR UNDO、THROWからの混乱は何ですか。それは大きな問題です。チームには何の慣習もなく、エラーハンドリングと使い方があります。

Answer 3

私は過去4年間、OOABL（10.1cで始まった）で80％の時間をかけました。 OOABLの使用をお勧めしますが、OOABLを他のOO言語と同じ方法で使用すると問題が生じることを考えることは非常に重要だと思います。 「同じように」とは、世界で共通するデザインパターンと実装方法を意味します。また、いくつかのタイプのアプリケーション、特にテクニカルフレームワークの分野では、OpenEdge（ORMなど）との連携が困難です。

原因は、OOABLのパフォーマンス上の問題と、言語のOO機能が欠落しています。

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

一部欠落または不正なオブジェクト指向の機能：

• ませクラスライブラリ、これは大規模なアプリケーションで特に重要となり （C＃での内部）は、Javaのように何のパッケージの可視性OO
• のために必要なノーデータ構造
• ないジェネリック
• 非常に限られた反射能力の取り扱い本当にひどい例外
（oe11で改善）

他の言語でのプログラミングに精通していて、OOABLの使用を開始すると、そこにあると思われる多くのものを失っているポイントに達することができます。 ABLのもの

アプリケーションをWindows上でのみ実行する必要がある場合は、C＃で新しいooコードを実装し、clr bridge経由で既存のプログレスコードから呼び出すこともできます。