興味深い質問です。 モノリシッククラスが何であるかについての正式な定義はないと思いますが、あなたはアイデアを持っています。 論理的に接続されていない、または無意味に結合されている複数のコンポーネントを含むクラスは、モノリシッククラスです。

私が強くお勧めする「The Pragmatic Programmer」を読んだ場合、モノリシッククラスをその本のほとんどすべてに反するアンチパターンとして定義できます。

例として、モノリシックチップの正式な定義があるモノリシックチップに似たチップとOS設計の領域でより多くを見つけることができます/http://en.wikipedia.org/wiki/Monolithic_kernel[kernels]クラス。 以下にいくつかの例を示しますが、それぞれがこのリストに載っていないことを主張できます。

チームに参加するのではなく、単独でプログラミングを開始した場合、最初のプロジェクトの1つを開くことができ、モノリシックなクラスが存在する可能性があります。

単語の語源を調べると、ギリシャ語のモノ（単一）とリソ（石）に由来していることがわかります。 あなたが言及するソフトウェアの文脈では、http：//www.worldlingo.com/ma/enwiki/en/Monolithic_application/1 [単一層アプリケーションで、ユーザーインターフェイスとデータアクセスのコードは単一のプラットフォームから単一のプログラムに結合されます]。

「モノリシック」とは、http：//oreilly.com/catalog/opensources/book/appa.html [成功したソフトウェアの難燃化に使用されている]という用語です。 このリンクは、この用語に固有の仮定とその限られた有用性を公開します。

基本的な前提は、それぞれが明確に定義された個別のタスクを持つソフトウェアコンポーネントから構築されている場合、システムがより適切に動作することです。 直感的に、これは正しいようです。 各コンポーネントが機能する場合、システム全体が機能する必要がありますか？

現実には、それほど簡単ではありません。 大規模な構成（非モノリシック）システムは、責任を負う単一のコンポーネントがない場合でも、重要な機能を見逃す可能性があります。 これは、アーキテクチャ設計が特定のコンポーネントへの機能の割り当てに失敗した場合に発生します。 これは、単一のコンポーネントにきれいにマッピングされない関数の場合に特に発生する可能性があります。

Linux（リンクされた例を続ける）は、実際にはモノリシックではありません。 モノリシックカーネルの上にモジュラーユーザー空間があり、多くの個別のユーティリティが付属するユーザー空間です。 http://www.busybox.net/ [そうでない場合を除く。]

モノリシックアーキテクチャは、すべてのRailsツール（ActionMailer、ActiveJob、ActionCableなど）をこれらのツールが適用するコードと一緒に収集できる1つのピースとして作成されるソフトウェア構造のモデルです。 ツールは互いに接続されていませんが、自律的でもありません。

1つの機能を変更する必要がある場合、1つのプロセスの一部であるため、プロセス全体と他の機能の作業に影響します。

Ruby on Railsが何であるか、何が提供できるか、その長所と短所を思い出しましょう。 その最も重要な利点は、簡単に操作できることです。

_rails new_と書くと、すぐに新しいアプリケーションをすぐに入手できます。必要なREST APIを作成し、Railsヘルパーとジェネレーターを使用すると、開発がさらに簡単になります。

Railsアプリでメールを送信する必要がある場合は、Rails ActionMailerを使用します。 ハード処理が必要な場合は、ActiveJobが役立ちます。 Rails 5を使用すると、すぐにWebソケットを使用することもできます。 したがって、チャットを作成したり、アプリケーションをよりインタラクティブにしたりするのは簡単です。

正しいDSL構文を使用する場合、そのすべてを使用でき、さらにすぐに使用できます。 さらに、これらのツールの内部実装に関するすべてを知っている必要はなく、DSLであると考え、期待される結果を受け取ることができます。

それは何かがモジュラーの反対であることを意味します。 モジュラーアプリケーションには、モジュールと呼ばれる部品があり、アプリケーション全体を交換することなく交換できます。 一方、モノリシックアプリケーションは、一部を修正またはアップグレードした後、全体を置き換える必要があります。

Wikipediaから：「モジュール性は、一般に、アプリケーションロジックの一部の再利用をサポートし、アプリケーションの一部の修理または交換を可能にすることでメンテナンスを容易にするため、望ましいです。卸売りの交換は必要ありません。」

そのため、モノリシッククラスのコンテキストでは、すべての機能は自己完結型であり、クラスに機能を追加または変更する場合は、クラスのコードを変更/追加して再コンパイルする必要があります。 逆に、モジュラークラスは、外部で実装される機能へのアクセスを公開します。 たとえば、「Calculator」クラスは、実際に数値を追加するために個別の「Add」クラスを使用できます。別のライブラリから「乗算」関数を呼び出します。または、Webサービスから「償却」関数を呼び出します。 これらの機能部分のそれぞれがクラスの外部で変更できる限り、モジュール式です。

ソフトウェア開発におけるモノリシックデザインの私の定義は、コードの単一の不可分ブロックに追加機能を追加する必要があるデザインです。

PRO:

短所：