はらぺこ日誌» ブログアーカイブ » API 開発における要件分析 – C++ のための API デザイン
ライブラリ API の設計手法を学ぼうシリーズの第3弾です。前回の記事はこちら。以下の教材を利用しています。 C++ APIデザイン 今回から第4章に入ります。4章は C++ での実装の話はなく、設計に入るまでの情報の収集や整理 (要するに要件分析)、および様々なレイヤーでの設計に関する議論となっています。プログラミング実習をするような内容でもないので、要点をまとめながら解釈したり考えたりしたことをレポートしたいと思います。 今回はその中でも、 4.1～4.3節の、要件分析までの内容について見ていきます。 大原則 最初のセクションに入る前の書き出しで、以下のように書かれています。これはもう、大原則ですよね… (強調は拙引用者によるものです)。 …こうしたさまざまな分析テクニックは個別に使っても組み合わせて使っても有用である。とはいえ、「自分で理解できないことは設計できない」という原則を常に
はらぺこ日誌» ブログアーカイブ » Observer パターンでコンソール MVC っぽいことをやってみる – C++ のための API デザイン
ライブラリ API の設計手法を学ぼうシリーズの第2弾です。前回の記事はこちら。以下の教材を利用しています。 C++ APIデザイン さて、API のラッピングパターンについてはざっと読むだけで終了とし、今回は Observer パターンについてさらってみました。 MVC っぽいことをやってみたい。 本書では、オブザーバーパターンの説明に入る前に、 MVC アーキテクチャについての説明がありました。 シンプルなアプリケーションでは、コントローラはユーザ入力に基づいてモデルへの変更に影響を与え、こうした変更をビューに通信して、UIを更新できるようにする。しかし、実際のアプリケーションでは、通常、水面下のモデルへの追加変更を反映するために、ビューも更新する必要がある。(…中略…)とはいえ、先ほど述べたように、モデルコードはビューコードを静的にバインディングして呼び出すことはできない。そこでオブ
はらぺこ日誌» ブログアーカイブ » Pimpl とかファクトリとか – C++ のための API デザイン
otoco プロジェクトの開発に着手するにあたって、私はまだ C++ でのライブラリ開発を 1 からコーディネートした経験がなかったので、クロスプラットフォームに対応したライブラリ API の開発手法を学ぶ必要があると感じました。ちょうどいい感じの教材が割りと最近出ていたようで、早速購入し、勉強を進めています。 C++ APIデザイン C++11 についても若干触れられているようで (原著執筆当時はまだ C++0x と呼ばれていた模様…)、この手の教材の中では比較的情報が新しい方なんではないかと思われます。 実はこの本を買って勉強し始めたのはもう結構前 (確か前原にいた頃… 昨年の暮れ頃?) なのですが、ここしばらく本業やら引っ越しやらが忙しくてなかなか手を回せずにいたので、久しぶりの着手ということで、すでに履修していた第3章の、 Pimpl イディオムとファクトリメソッド辺りを復習してみ
DB 操作の視点からオブジェクト指向を考える: 国民宿舎はらぺこ 大浴場
シナリオ 出席簿をつけるアプリケーションを想定してみることにします。まずマスターとして、学生、講師、講義の 3つが存在するものとします。 学生 学籍番号 (PK) 氏名 性別 学年 etc... 講師 教員番号 (PK) 氏名 性別 役職 etc... 講義 講義識別番号 (PK) 講義名 担当講師 (教員番号) 場所 時間割 期間 単位数 概説 etc... それから、マスター以外のテーブルとして、受講者リストと出席記録があるものとしましょう。 受講者リスト 講義識別番号 (PK) 受講者 (学籍番号) (PK) 点数 成績 (優|良|可|不可) etc... 出席記録 講義識別番号 (PK) 受講者 (学籍番号) (PK) 講義回数 (N回目) (PK) 遅刻 (時刻) etc... さて、ログインした講師が受け持つ講義の 1つを選択し、新たに出欠をとる画面を開いたとします (講義回数
医薬連携とシステムに関する考察
とある薬剤師による、レセプト、処方せん等の病院と薬局との連携や、そこに介在する電子システムなどに対する考察というかぼやき。 システム屋として (そして現在病院関係のシステムに片足程度には関わっている者として) も気になる話題だったので、個人的メモとして拾い上げてみました。
はらぺこ日誌» ブログアーカイブ » システム構成仕様がとりあえず完成。
こんなんできました～。 …なんか、UI と I/O の関係図にデータの流れも含まれてるなぁ。これだったらデータの流れ図要らなかったかも…。ていうか、基本的にはここでやりたかったのは必要な UI の可視化なので、実行時オプション、設定ファイル、警告出力、そして各種操作が、各処理とどう関係するか、という部分だけ書いて、データの流れは含めるべきではなかったかも…。あと端子で書いた 3つの出力もデータの流れ図で示すべきだったかも…。データの流れ図ではファイルと見分けが付かないしなぁ…。 2009 年 7 月 7 日 by 村山 俊之 タグ: otoco, 設計 この投稿は 2009 年 7 月 7 日 火曜日 8:52 AM に 技術メモ, 活動記録 カテゴリーに公開されました。 この投稿へのコメントは RSS 2.0 フィードで購読することができます。 コメントを残すか、ご自分のサイトからトラッ
はらぺこ日誌» ブログアーカイブ » UI と I/O の関係図を作成中…
なんだけど、いまいちしっくりこないので、まだ未公開です…。ちょっと時間をかけすぎてしまった (1時間以上オーバー^_^;)。 …操作と入出力がごっちゃになっちゃってるなぁ。入力はファイルを規定しているのに出力はそれを規定しないからアンバランスになってるんだろうな。操作が処理を呼び出す関係と処理による入出力の関係は切り離さないとな。出力はどうやって示そう? コネクタが良いのかなぁ… (以上独り言) 2009 年 7 月 6 日 by 村山 俊之 タグ: otoco, 設計 この投稿は 2009 年 7 月 6 日 月曜日 9:56 AM に 技術メモ, 活動記録 カテゴリーに公開されました。 この投稿へのコメントは RSS 2.0 フィードで購読することができます。 コメントを残すか、ご自分のサイトからトラックバックすることができます。
はらぺこ日誌» ブログアーカイブ » データの流れを設計してみた。
otoco の処理におけるデータの流れを書いてみました。この奇っ怪な図の作図には OpenOffice.org の Draw を利用しています。 この手のツールの場合、データの流れはそのまま必要な処理を浮き彫りにするので、システムの構成を表現する情報の一つとして重要な資料になります。そして、実際のモジュール構成をもろに規定する仕様とはならないので、あくまで外部仕様として扱うことができるのも大きな利点です。 明日以降はこれに加えて、UI と処理との関係を設計します。 2009 年 7 月 5 日 by 村山 俊之 タグ: otoco, 設計 この投稿は 2009 年 7 月 5 日 日曜日 12:47 PM に 活動記録 カテゴリーに公開されました。 この投稿へのコメントは RSS 2.0 フィードで購読することができます。 コメントを残すか、ご自分のサイトからトラックバックすることができま
「妄信」とやらがプログラムを「複雑」にするという迷信: 国民宿舎はらぺこ 大浴場
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場 職場からなので簡潔にｗ 「変数のスコープは狭いほど良い」と妄信する 「同じロジックのコードを2度以上書くな」と妄信する 「プログラミング言語を極めるのが大切」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。 同じようなパターンがプログラムの複数箇所に現れる場合、それらを抽象化して一つの共通ロジックへのパラメータ渡しとして実装し、それを複数箇所から呼び出すように実装すると、プログラムコード量が小さくなり、保守性が良くなったような気がするので、未熟なプログラマが、なんでもかんでも共通ルーチン化しまくって、非常に保守性の悪いプログラムにしてしま
ハンガリアン記法考: 国民宿舎はらぺこ 大浴場
物凄く久しぶりに一人っきりでワインとか飲んだら思いっきり酔いつぶれて 2、3 時間ほど眠ったらこんどは目が冴えてしまって眠れなくなっちゃったので、これまた久しぶりに枯れた話題について愚考を重ねてみようかと思う次第。 最近、とある友人 (「主に VB」なプログラマーさん) が、「変数名には必ず型がわかるような接頭子をつける記法に慣れている」というようなことをおっしゃるので、ハンガリアン記法を原則化するコーディングルールが好きでは無いおいらはちびっと反発してしまったわけなのですが、偏見の可能性もあるので今一度整理してみようかなぁとか思ってみたわけなのですよ。 結論から言えば、結局は case by case ということになるのだろう、ということなのですが、それだけだと有意義な情報とは言えないと思うので、どういう場面で使うと効果的かというのをさらっと列挙すると大体以下の通りになるんではないかと思
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
