問題タブ [modularity]

レポート用に SQL Server 2008 で新しいデータベースを構築しています。さまざまな種類のレポートに含まれるこのデータに関連する多くの一般的なビジネス ルールがあります。現在、これらのルールは、レガシー言語のより大きな手続き型プログラムに組み込まれていますが、これを SQL に移行しようとしています。SASでのレポート、C#でのレポートなど、このデータからレポートを実装する際の柔軟性を狙っています。

現在の私のアプローチは、これらの一般的なルール (通常は非常に単純なロジック) を分割し、個々の SQL UDF にカプセル化することです。パフォーマンスは問題ではありません。これらのルールを使用して、一種のレポート「スナップショット」で静的フィールドにデータを入力したいだけです。これを使用して、任意の方法でレポートを作成できます。

各ルールが何をしているかを理解する (そしてルール自体を維持する) 限り、このモジュラー アプローチは気に入っていますが、メンテナンスも悪夢になるのではないかと少し心配になり始めています。他のルールに依存するルールもありますが、そこから逃れることはできません。;)

データベースでのこのモジュラー アプローチのためのより良いアプローチはありますか? 私は正しい方向に進んでいますか、それともアプリケーション開発の考え方が多すぎますか?

私はOSGiに関するプレゼンテーションをたくさん見ましたが、 OSGiはより良いモジュール化を実現する上で有望だと思います。どうやら「ホットデプロイメント」と「異なるバージョンの x を並行して実行する」ことも市長のセールス ポイントです。

OSGi が解決すると約束していることは問題でさえあるのだろうか...? 同様の主張がメイドだったOOの初期を思い出しました：

オブジェクト指向が新しいとき、大きな論点は再利用性でした。オブジェクト指向を使用する場合、「一度書く」だけで「どこでも使用できる」と広く主張されていました。

実際には、これはかなり低レベルの例でしか機能していませんでした。その理由は、再利用可能なコードを書くのが難しいからだと思います。技術的にではなく、インターフェース設計の観点から。将来のクライアントがクラスをどのように使用したいかを予測し、正しい選択を前もって行う必要があります。これは定義上困難であり、潜在的な再利用性の利点を提供できないことがよくありました。

OSGiを使用すると、ここでも、私たちが実際には持っていない問題の潜在的な解決策である約束に陥る可能性があるのではないかと私は疑っています。あるいは、もしそれらを持っていたとしても、OSGi に助けを求めることを正当化するのに十分な量と重大度でそれらを持っていません。たとえば、モジュールのサブセットの「ホットデプロイメント」は間違いなく素晴らしいアイデアですが、実際にどのくらいの頻度で機能しますか? 特定の問題のモジュール化が間違っていたことが判明したためではないことがどれくらいありますか? 複数のモジュール間で共有されるモデル エンティティはどうですか? これらのモジュールはすべて同時に変更する必要がありますか? それとも、インターフェイス コントラクトを維持できるようにするために、オブジェクトをプリミティブにフラット化し、モジュール間通信でのみ使用しますか?

OSGi を適用する際の最も難しい問題は、モジュール化を「正しく」行うことだと思います。OO でクラスのインターフェイスを正しく設定するのと同様に、OSGi を使用しても問題は同じままです。今回はより大きなスケールで、パッケージまたはサービス レベルでさえもです。

ご想像のとおり、私は現在、プロジェクトで使用する OSGi を評価しようとしています。私たちが抱えている主な問題は、コードベースが大きくなるにつれて複雑さが増していることです。私は、システムをより小さなモジュールに分割して、相互作用がますます定義されないようにしたいと考えています。

• 何をモジュール化するかを決定するのに役立つフレームワークがないことを考えると、OSGi はあなたにとって報われたことがありますか?
• チームで作業することで、生活が楽になりましたか?
• バグの数を減らすのに役立ちましたか?
• 主要コンポーネントの「ホットデプロイ」に成功したことがありますか?
• OSGi は時間の経過とともに複雑さを軽減するのに役立ちますか?
• OSGi はその約束を守りましたか?
• それはあなたの期待に応えましたか？

ありがとう！

私の Android メイン アプリケーションは、いくつかのモジュールがプリインストールされたメイン プログラムで構成されます。
次に、後で別のモジュールを提供したいと思います。別のファイルとして提供するのが最善です。次のようなモジュール: 場所、天気、議題。

これをどのように達成しますか？

インストール/存在するモジュールをデータベースに保持したい。そのため、起動時にモジュールが存在するかどうかを検出して、モジュールをデータベースに入れる必要がある場合があります。メイン アプリは、これらのモジュールに基づいて動作します。

これらのモジュールを個別のファイルとしてビルドするにはどうすればよいですか? それらは私のアプリケーションのエントリ ポイントにはなりません。そのため、ナビゲーション メニューのアプリケーションであってはなりません。

これは可能ですか？
Eclipse を使用してこれを作成するにはどうすればよいですか?
モジュールはどのような形式で提供されますか?
ユーザーはどのようにモジュールを追加/削除しますか?

コードの再利用を促進するために、Rails 3ではどのような取り組みが行われていますか？フレームワークに組み込まれているmerbスライス/エンジンに似たもので、「ブログ」エンジンなどの構成可能なコンポーネントをドロップできるものはありますか？もしそうなら、何がベストプラクティスと見なされますか？

これは非常に興味深い読み物でした: http://www.devmaster.net/articles/oo-game-design/

著者は、「うわー、これは慎重に実装すれば素晴らしいかもしれません。これは未来です!」と繰り返し言っています。まあ、あまり役に立ちません。コードが必要であり、何よりも、この種の設計が実際に機能するという証明が必要です。

この記事で説明した概念のいくつかを実装する例を知っていますか? たぶん、研究できる小さなオープンソースのゲームでしょうか? または、少なくとも、同様の概念が議論される場所ですか?

私はCでモジュラープログラミングを始めたばかりです。多くのエラーが発生しているため、インクルージョンで何か問題がconflicting types for 'functionName'発生previous declaration of 'functionName' was hereしていると思います。インクルージョンガードを設置しました。

Cでのモジュラープログラミング、特にインクルージョンがどのように機能するかを説明する明確なチュートリアルを知っていますか？

更新：問題を切り分けようとしました。リクエストに応じて、ここにいくつかのコードがあります。

更新2：更新されたコードは以下のとおりです。エラーも更新されました。

これにより、次のエラーメッセージが生成されます。

aStruct.h：10で

• フィールド'ssTest'のタイプが不完全です

main.c：8で

• 未使用の変数`asTest' （これは理にかなっています）

私は4つの製品を持つ製品スイートに取り組んでいます。現在、すべての構成データはXMLファイルまたはプロパティファイルのいずれかにあります。このアプローチは、環境（本番、開発など）ごとに異なる構成ファイルを管理する必要があるため、維持できません。

では、構成データを処理するための最良の方法は何ですか？

また、これを別のモジュールにモジュール化できますか？すべての製品がこのモジュールを使用できるようにします。プロパティファイルは使いたくありません。すべての構成固有のコードを新しい構成モジュールとして移動し、すべての構成データをデータベースに保持できるソリューションを探しています。

いくつかの機能を追加するために、多くの WAR 開始ページのコンテンツを変更する必要があります。フィルターを使用して変更できません。フィルターを Web アーカイブに配置する必要があるためです。サーブレットなどでも同じです。これを行う方法の手がかりはありますか?

OOPの方法論を批判する非常に説得力のある記事（おそらく本）をいくつか提供していただきたいと思います。

私はこのトピックについてWWWでいくつか読んだことがありますが、「決定的なデモチベーター」は実際には見つかりませんでした。

OOPに対する私の個人的な態度はそれほど重要ではありませんが、あらゆる種類の議論と単なる抽象的な思考のための建設的で厳密な基盤が本当に必要です。

独自の研究を投稿することもできますが、非常に建設的なものにしてください（私の個人的な要求として）。