タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Programmingとprogrammingと設計に関するdecoy2004のブックマーク (9)

  • 責任(関心)を意識したアプリケーション設計 - Qiita

    プログラムが上手く組めるようになりたい プログラミングが上手くなりたいと考えたときに、個人的には『名付けを意識』するのと、『アプリケーション設計のときに責任を意識する』考え方を取り入れることをおすすめしております。 今回は『アプリケーション設計のときに責任を意識する』ことについて書いてみたいと思います。 基的には単一責任原則と、関心の分離のお話になります。 ※ タイトルに『関心』というワードがありますが、アスペクト指向プログラミングの話ではありません 単一責任原則とは まずは単一責任原則とは何かについてです。 よく単一責任原則の説明では「クラスを変更する理由は複数存在してはいけない」というニュアンスの言葉がよく使われます。 例えば、社員管理システムの実装を行いたい場合、一つのクラスに「社員登録」「出勤管理」「給与管理」などの機能を詰め込むと、『社員登録』の変更をする際にそのクラスが変更さ

    責任(関心)を意識したアプリケーション設計 - Qiita
  • システム開発 - 共立出版

    第I部 JSD入門 第1章 モデルと機能 第2章 プロセス・モデル 第3章 仕様の実現 第4章 JSDの開発手順 第II部 JSDの開発段階 第5章 三つの事例 第6章 実体行動段階 第7章 実体構造段階 第8章 初期モデル段階 第9章 機能段階 第10章 システムタイミング段階 第11章 実現段階 第III部 各種の話題 第12章 入力副システムと誤りデータ 第13章 システムの保守 第14章 回顧 付録A JSD用語集 付録B JSD記法 付録C デイリー・ラケットの懸賞 付録D ウィジェット倉庫 付録E ハイラッド・エレベータ

    システム開発 - 共立出版
  • Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ

    Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
  • 状態遷移図/表、すなわち設計をコードでテストする

    状態遷移表からひな型コードを生成する この状態遷移表からコードを起こすわけですが、状態遷移の実装については『StateパターンでCSVを読む』を書きました。デザイン・パターンの一つ:Stateによる実装です。今回の実装はC、継承も仮想関数も使えないという利き腕を封じられた条件なので戦術を大きく変えにゃならんです。 状態遷移の実装は要するに「(1)現状態 と (2)受理したイベント の組」に対応する「(3)アクション と (4)遷移先(新たな状態)」を引き当てることに他なりません。ならば上記(1)~(4)の並びをレコードとし、そのレコード列(=状態遷移表)から「(1)現状態 と (2)受理したイベント の組」に一致するレコードを探し出して「(3)アクション を実行して (4)新たな状態 に遷移」すればいい。 状態遷移表からひな型コードの生成には使い慣れた「T4-template」を用います。

    状態遷移図/表、すなわち設計をコードでテストする
  • Base DDD(ドメイン駆動設計) 参考文献を巡る旅

    2014.09.21 DDD読書会@大阪 LT大会用資料です。 DDDの参考文系を調べることで、DDDの思想に少しでも触れればと思いまとめてみました。

    Base DDD(ドメイン駆動設計) 参考文献を巡る旅
    decoy2004
    decoy2004 2014/09/25
    絶版多い。復刻しないかな。
  • クラスの命名のアンチパターン - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame

    クラスの命名のアンチパターン - Qiita
    decoy2004
    decoy2004 2014/09/05
    『手段と目的を履き違へるべからず。「ラッパーであること」や「プロクシであること」は何か他の目的を実現するための手段に過ぎないはず。』
  • 実践的な設計って、なんだろう?

    Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計

    実践的な設計って、なんだろう?
    decoy2004
    decoy2004 2014/05/19
    『コレクションを get() して操作するとあちこちに同じコードが登場する。だからコレクションを持つクラスにループ処理を閉じ込めて一元管理する。』
  • オブジェクト指向設計とは - @ledsun blog

    オブジェクト指向という言葉には オブジェクト指向分析(OOA) オブジェクト指向設計(OOD) オブジェクト指向プログラミング(OOP) の三つの意味があります。 オブジェクト指向初心者泣かせです。 ここではオブジェクト指向設計を説明します。 ソフトウェアの設計 ソフトウェアの設計には二つの側面があります。 作成するソフトウェアの共通部分を探し出しモジュール化する 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする 一つ目のモジュール化は構造化設計からある手法です。 オブジェクト指向設計で特に取り上げる点はありません。 ここでは二つ目の将来の変更のために抽象化することに重点を当てます。 オブジェクト指向設計 オブジェクト指向設計とは多態を実装する部分を決めることです。 多態とはオブジェクト指向言語を活用した次のものです。 変更可能な点に抽象クラス*1 (オブジェクト指向言語

    オブジェクト指向設計とは - @ledsun blog
  • 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;

    Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべきだなと感じた。 このではソフトウェアコンストラクションに関する話題を扱っている。このの中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による

    職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
    decoy2004
    decoy2004 2014/03/17
    『最初から過剰に抽象化するのは失敗のもと』
  • 1