2017年06月14日

事例:ブログ投稿システム-出力部構造


初めての方はこちらを「はじめに

前回の記事「設計における汎用性とは」の何か具体例は無いかと思ったのですが内部構造の話なのでなかなか思いつかず、自身の事を例に取り上げてみようと思います。
実はこのブログは自作のプログラムによって投稿しています。
今回はこのブログ投稿システムの出力部分の構造を例にとって設計の汎用性について説明してみたいと思います。

構造


以下の図が出力する部分の簡単な構造の図です。
53N025_001.jpg

各部分の説明をします。
1.Editor:記事のエディター
11.Main:メインの処理
12.Out:出力(投稿)部
121.Mng:下のFmtの管理部
122.Fmt:各型式の出力内容の生成部
1221.Seesaa:ブログサービスSeesaa用の出力処理
1222.Twitter:Twitter用の出力処理
2.SNS-API:各SNSにアクセスする為のAPI
21.Blog:ブログ共通
22.Twitter:Twitter

あくまで説明用であって実際はもっと複雑な構造をしています。
1.Editorはいわゆるブログエディター的なものであって、記事を書いた後に「出力」機能を実行すると投稿します。
その投稿に関する処理を一手に引き受けているのが12.Outです。
12.Outの実体は122.Fmtであって、ここで記事の内容を各投稿先の形式に変換します。
122.Fmtにどんなものがあってどれを呼び出すか等の制御を121.Mngが行っています。
前回における「」と同様の構造です。
2.SNS-APIはこのシステムとは独立していて各SNSへのアクセスを機能として実装したものです。ブログはサービスによりますがXML-RPCというプロトコルである程度共通的な機能が提供されています。
ちなみに122.Fmtや2.SNS-API内の空の箱は何も実装されていません。つまり現在のところ実体は何もありません。

固定的な構造


さて、この様な構造に対して以下の様にもっと直接的で固定的な構造をとる事も出来ます。
53N025_002.jpg

各部分の説明をします。
1.Editor:記事のエディター
11.Main:メインの処理
12.Out:出力(投稿)部
121.main:出力処理
122.Sub Seesaa:ブログサービスSeesaa用機能
123.Sub Twitter:Twitter用の機能

SNSアクセスのAPIは無く、全て1.Editorに内包されます。
12.Outの処理も基本的に121.mainに全て入っていて、Seesaa用の独自の処理とかTwitter用の独自の処理を受け持つ為にサブが存在します。
こちらは前回における「」から「」のどこかという事になります。

両者の比較


両者を並べて比較しながら話を進めます。
53N025_003.jpg

ここでは仮に左を汎用型と呼び右を固定型と呼ぶ事とします。
赤い線は両者の関係を表したものです。
汎用型の121.Mngは122.Fmtを管理する為のものなので該当するブロックは固定型にはありません。汎用型で122.Fmtと2.SNS-APIとして分離して実現していたものは固定型では12.Outの中で一緒くたになって実現されることになります。
固定型は作りがシンプルですし汎用型の様な空の箱もありません。

現在の利用方法では固定型でも特に問題はありません。
ではなぜ汎用型の様な構造にしたのかと言えば、自分にとってこのシステムの場合この程度の汎用性で設計するのが一番トータルで効率が良いと思えたからです。
トータルと言うのは「開発+将来の保守」の両方を合わせた効率という事です。
開発という意味では基本的にはあまり考えてなく、各機能群があるべき姿としてどの場所になるのかを考えただけです。例えばSNSへのアクセスを担当する機能は本来ブログとは関係ありませんからブログのシステムの外にいなければなりません。そんな具合に各機能群をあるべき場所に配置していくだけなので設計といっても大してパワーのかかる事ではありません。
また将来の保守性という意味でも何かを具体的に想定していた訳ではありません。例えば元々「出力というのは多様に切り替えるもの」という理解なので、122.Fmtの様な形で色んな型式を取り揃えて121.Mngで切り替える形しか考えていませんでした。具体的な事としてはそうしておけば「万一ブログの引っ越しをした場合も対応が楽だ」程度の事しか想定していませんでした。
それでもこういう構造の方が保守(新規開発後)の効率が良い(費用対効果が高い)だろうという判断でした。
実際Twitterへの出力は最初は無くて何年か経ってから対応したのですが、もしブログのみを対象とした固定型の構造にしていたら後からTwitterの対応をするのは12.Outをほぼ作り直さないとならなかったでしょう。それが汎用型の構造では12.Out内の変更としては122.Fmtに1222.Twitterのブロックを追加しただけで大してパワーはかかりませんでした。

この様にできるだけ汎用的な姿になっていればそれだけメリットはある訳ですが、設計するパワーとのパランスをとる必要があるのは前回の「実際の取り組み」の部分で述べた通りです。

一覧


メニュー

関連


なぜ汎用的にする必要があるのか
なぜログやエラー処理の組み込みは苦労するのか
設計における汎用性とは


記事を広める



posted by 善 at 22:09 | Comment(0) | TrackBack(0) | 事例 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック