例外設計の話
例外設計の話。 こんな指針がいいのかなー 2013 夏 ver. 例外の目的とは？ 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」 via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html .NET の「例外のデザインのガイドライン」にもこう書いてある。 特定の例外が特定のコンテキストでスローされる理由を把握できている場合は、その例外をキャッチするようにしてください。 回復可能な例外だけをキャッチする必要があります。たとえば、存在しないファイルを開こうとした場合に発生する FileNotFoundException は、アプリケーションで処理できる例外です。それは、アプリケーションがユーザーに問題を知らせ、ユーザーが別のファイル名を指定したり、ファイルを作成したりできるようにすることが可能だからで
Home
2015.06.28(日) BSDカーネルの設計と実装 読書会 (35) 最終回 P.639（14.4.2 カーネルスレッドの初期化）～ @shigemk2さんによるレポート: BSDカーネルの設計と実装 読書会 (35) 最終回 まとめ #readDaemon 2015.05.23(土) BSDカーネルの設計と実装 読書会 (34) P.613（13.10.3 鍵管理）～ @shigemk2さんによるレポート: BSDカーネルの設計と実装 読書会 (34) まとめ #readDaemon 2015.04.05(日) BSDカーネルの設計と実装 読書会 (33) P.588（13.7.5 再送処理）～ @shigemk2さんによるレポート: BSDカーネルの設計と実装 読書会 (33) #readDaemon 2015.03.14(土) BSDカーネルの設計と実装 読書会 (32) P.5
契約プログラミング - Wikipedia
契約による設計 契約プログラミング（けいやくプログラミング、英: Contract programming）または契約による設計（けいやくによるせっけい、英: Design by Contract; DbC）は、ソフトウェアの正確性[注 1]と頑健性[注 2]を高めるためのソフトウェア設計の方法論である。DbC はロバート・フロイド、アントニー・ホーア、エドガー・ダイクストラらの形式的検証の仕事を基礎にしている[1]。DbC は（抽象データ型に基づく）オブジェクト指向プログラミングにおける表明の利用や、継承に伴う表明の再定義の原理的規則、例外処理の原理的規則などを提供する[2]。 DbC は、バートランド・メイヤーによって提案された[3][4][5]。 概要[編集] 「契約による設計」（DbC）における中心的な概念は、クライアントとサプライヤ[6]の契約 (contract) である。Db
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
動的プログラミング言語 - Wikipedia
動的プログラミング言語（どうてきプログラミングげんご、英: dynamic programming language）は、コンピュータ・プログラミング言語において、一般にコンパイルなどの準備段階に済まされることが多いことを、準備時ではなく実行時に行うプログラミング言語処理系（の言語）である。本来は実装（処理系）のことを指すべきであるが、一般にその言語を指して議論されることが多い。もっぱら高水準言語が多い。動的言語（英: dynamic language）とも。例えば、型システムによる型チェックや、値の型変換、名前束縛などを、コンパイルなどの実行準備時ではなく実行時に行う。そういった「動的さ」により、コードの追加やオブジェクトや定義の拡張や型システムの変更によるプログラムの拡張、といったことが行いやすい、ということが利点とされる。これらの動作は静的な処理系でも手間はかかるがエミュレート可能で
ドメイン駆動設計 - Wikipedia
ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計手法である[1][2]。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。例えばローンの申し込みを処理するソフトウェアには、LoanApplicationやCustomerなどのクラスと、AcceptOfferやWithdrawどのメソッドが含まれることになる。ドメイン駆動設計は次の目標に基づいている。 プロジェクトの主な焦点をコアドメインとドメインロジックに置く。 ドメインのモデルに基づく複雑な設計。 特定のドメインの問題に対処する概念モデルを繰り返し改良す
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
