Unixでのプログラミングの技術（だけでなく）。 パート4、「分離のルール」

「 エリック・レイモンドによる」Unixのいくつかの簡単な開発ルールに焦点を当てた一連の記事を続けます。これは、私の最も深い信念において、他のオペレーティングシステムに拡張できます。 モジュール性 、 明clarity性 、 構成の規則について、最初の3つのパートですでに話しました。 今日では、4番目のルールになります-



分離ルール：ルールをメカニズムから分離し、インターフェースをエンジンから分離します（ 「ビジネスロジック」 ）（分離のルール：メカニズムからポリシーを分離し、エンジンからインターフェースを分離します）



多くのWebプログラマーは、おそらくこのルールはかなり平凡だと思うでしょう。 結局のところ、この原則は、サイトの数百万のフレームワークとコンテンツ管理システムの基本であり、それらはほとんどすべての最新のWebソリューションの基礎です。 それでも、製品をゼロから開発する場合にのみ、この原則を頻繁に遵守し、あらゆる方法でそのサポートと開発に違反することに気づくようになります。 「緊急だったから」。 第二に 、 ウェブサイトを除く残りのソフトウェアでは、記憶が少なくなります。 結局のところ、インターフェイスはWebインターフェイスだけではありません。



このトピックに関連して、 Model-View-Controller 、または要するにMVCの概念を思い出してください。 データ（モデル）、表現（ビュー）、 ビジネスロジック （コントローラー）を分離することになっています。 簡単に言えば、すべてのロジック、すべてのインターフェイス、およびすべてのデータは、異なるコンポーネントによって互いに分離され、標準インターフェイスによって接続されている必要があります。 この設計パターンは、ほとんどすべての最新のプログラミング言語に実装されています。 人気のある「クラシック」から、Apache Struts（JAVA）、Symfony（ PHP ）、ASP.NET MVCを思い出すことができます。 この目的のために十分に文書化され、広く使用されているフレームワークを使用することは、問題を解決するための詳細を置く必要がなく、おそらく自転車の発明と時間の浪費にすぎないため、自分で最初から書くよりもはるかに好ましいですおよびリソース。



インターフェイスとロジックの分離の非常に興味深い例は、GNUライセンスの下で配布されるUnix用のチェスの実装です。 テキストインターフェイスを備えた独立したチェスエンジンがあります。 その内部では、インターフェイスも「ロジック」から分離されていますが、重要なことは、意図的に意図的に「負担」がかかっていないことです。 フィギュア付きBlackboardは、XChess、Pychess、Winboardなどの個別のアプリケーションです。



この概念を使用する典型的な例は、独自のグラフィカル環境を持たないウィンドウシステムであるX Window Systemの実装です。 「ウィンドウ」と「アイコン」のレンダリングは、「数学」がなく、 I / Oデバイスのサポートを気にしないサードパーティのウィンドウマネージャーによって行われます 。



この原則の一部は、ルールをメカニズムから分離することです。 それは、柔軟でカスタマイズ可能なデータベースのロジックを構築することです。 ここで、残念ながらまたは幸いなことに、柔軟性と十分性の間の境界線をどこに引くべきかについての普遍的なアドバイスはありません。 たとえば、iPhone用のアプリケーションを設計するとき、さまざまな画面解像度に依存できます。これは、iPadへの移植の問題が発生した場合に確実に役立ちます。 これには間違いなく追加の労力と時間が必要です。 したがって、プロダクトマネージャーまたは彼を置き換える人物がここに関与する必要があります。プログラマーのタスクは、これらの問題を明確かつ理解可能な形式で正しくタイムリーに提起することです。



この原則を遵守する際の難しい状況の1つは、Javascriptとサーバーロジックの使用です。 AJAXを積極的に使用するシステムを作成する場合、設計段階でこれを注意深く監視する必要があります。 非常によくある間違いは、 JavaScriptを使用したサイトテンプレートの過度の複雑さであり、その結果、テンプレートが複雑なシステムになります。 したがって、Javascriptを積極的に使用する計画を立てるたびに、この場合のようにビジネスロジックとインターフェイスを分離するように、開発チームで調整されたアプローチを取ります。

" 以前：構成ルール

続き：シンプルさのルール "