GoFデザインパターンの一覧表と,活用のためのコメント,および入門者が独学するためのリンク集(サンプルコード付き)。 入門者の独学を支援するために,このページのURLを提示して熟読させ,各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず,入門書を買ったまま,途中で挫折する人が多い。 挫折の原因は,パターンの数が23もあって,多いからだろう。 全パターンをすんなり覚えてもらうためには,各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると,パターンの意味はこうなんだ。」 という要点・本質を,短いコメントで伝えれば助けになるだろう。 こういった学習を通して,Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表(要約コメント付き) 全パターンについて,10文字以内
Effective Scala Marius Eriksen, Twitter Inc. marius@twitter.com (@marius) Table of Contents Introduction Formatting: Whitespace, Naming, Imports, Braces, Pattern matching, Comments Types and Generics: Return type annotations, Variance, Type aliases, Implicits Collections: Hierarchy, Use, Style, Performance, Java Collections Concurrency: Futures, Collections Control structures: Recursion, Returns,
先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの?」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob
サーバサイド(特にNode.js)とクライアントサイド両方で動かしたいものは最近はこんな感じで書いている。 CommonJSのwiki見ててそこに紹介されてるソースコードで(どれだったか忘れたけど。。)やってたのを見ていいなーと思って真似っこした。 (function(define) { define([], function() { 'use strict'; /** * @constructor */ var SomeClass = function() { // initialize }; /** * @type {string} * @private */ SomeClass.prototype.hoge_ = 'hoge'; /** * @return {string} */ SomeClass.prototype.getHoge = function() { return th
最近CoffeeScript界隈のブロゴスフィア(死語)を賑わせていた「CoffeeScriptを使うべきか、使わざるべきか?」という話題についてまとめてみた。 以下の記事紹介は超訳かつ要約なので詳しく知りたい人は元記事を参照のこと。 ことの発端はこの記事。 SnackJSの作者がCoffeeScriptをディスる。 A Case Against Using CoffeeScript by Ryan Florence デバッグの問題 CoffeeScriptが生成するJavaScriptはきちんとしているけど、結局は自分が書いたコードじゃないため読みにくい。自分で直接書いたほうが見やすい。 それにCoffeeScriptをデバッグするワークフローは大変だ。 まず問題がJavaScript内のどこで発生したのかを突き止める(CoffeeScriptのコードと行単位で対応してないから大変だ)
Java Advent Calendar 2011 の18日目です。 17日目の記事は JavaEE使ってウェブアプリケーションつくろうよ - 水まんじゅう2、 19日目はJavaエバンジェリストの寺田さんですよ。乞うご期待。 プロローグ 後:「先輩、いまさらなんですけど上からSQLの遅いところを調査してくれって依頼がきてて、全クエリの実行時間を実データで集計とれと言ってるんですけど。これ、SQL発行前後で時間計測するしかないですかねー。このプロジェクトどんだけクエリ発行してるところあるんだろ…。簡単にやれないですかね。とりあえず調査に1週間かかるって返答しちゃいましょうか」 先:「まぁまて。全部のクエリにもれなく時間計測のコードを挿し込むとかやってられんし、手作業で漏れも発生するだろ。こういうのはオブジェクト指向で解決するのがスマートだ。あ、とりあえず調査に1週間かかるとは返答しておけ」
コードのリファクタリングとデザインパターン C++, Javaなどオブジェクト指向の考え方、クラスを上手に使うとコードをよみやすく整理できる場合が多くあります。 プログラムの動作を変えずにコードを整理することをリファクタリングと呼びます。 最初からコードを上手に設計するのは、熟練のプログラマでも難しいものです。少人数で開発する場合は、むしろ積極的にコードをリファクタリングし、アルゴリズムの見通しをよくするとよいでしょう。コードを修正する際にはversion管理ツールを使えるようにしておくと安心です。以前のソースコードの状態にいつでも戻せます。 ソースコードの版管理ツール Mercurialの使い方 http://www.xerial.org/wiki/lecture/2010/Mercurial デザインパターンに関しては、GoF本や結城浩さんの本などを読むと理解はできると思いますが、
プログラムのロジックを考え、実装を行う上で、変数の名前空間やスコープはとても重要です。 これらはロジックを組み立てる上での複雑さに直結し、ソースコードの読みやすさにダイレクトに関係してくるためです。 この記事では、私が Python で開発をする上で気をつけるようにしている名前空間やスコープに関するお話をします。 コーディングスタイルについて 名前空間やスコープの前に、まずは基本的なコーディングスタイルについて軽くお話しします。 Python のコーディングスタイルというと、 PEP 8 – Style Guide for Python Code (日本語訳は こちら )が有名です。 これは、 Python でプログラムを書く上で守っておくとよいお作法について書かれており、 Python のコーディングスタイルとしてはデファクトスタンダードといえるでしょう。 この PEP8、例えば以下のよ
サバクラ両方で動く JavaScript の大規模開発を行うために 原文:Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる? 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te
PHP finallyで検索すると、「PHPにはfinallyがない。欠陥言語だ!」という主張の記事がたくさんヒットします。これに対してPHPを擁護している記事があまりなさそうなので、PHPを擁護してみることにします。 finallyとは何か まずはおさらい。 try~catch~finallyは例外処理を行うための構文です。tryで例外が発生するかもしれない処理を書き、catchで例外が発生したときの対処を書き、finallyでは例外が起きても起きなくても実行される処理を書きます。…というのが初歩的な説明ですが、このfinallyの解説は十分ではありません。 finally節は、途中でどんなことが起ころうとも必ず実行されるというかなり特殊な性質を持っています。たとえば以下のJavaScriptのコードはいずれも「try」「finally」と表示します。tryの中でgoto相当の構文を実行
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは?」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
9 リードスルー、ライトスルー、ライトビハインド・キャッシュおよびリフレッシュアヘッド Coherenceでは、データベース、Webサービス、パッケージ化されたアプリケーション、ファイル・システムなど、任意のデータソースの透過的な読取りまたは書込みのキャッシングがサポートされていますが、一般的にはデータベースが最も一般的に使用されています。ここでは、任意のバックエンド・データソースのことを、簡単にデータベースと呼びます。効率的なキャッシュでは、集中的な読取り専用操作および読取り/書込み操作をサポートし、読取り/書込み操作の際には、キャッシュとデータベースは完全に同期化されている必要があります。これを実現するために、Coherenceではリードスルー、ライトスルー、リフレッシュアヘッドおよびライトビハインド・キャッシュをサポートします。 注意: パーティション(分散)およびニア・キャッシュ・
jQueryヘビーなアプリケーションの問題点と、MVCによる構造化の必要性 jQueryは、ブラウザ上で動くJSアプリケーションの開発生産性を劇的に向上させました。DOM操作による動的なページ書き換え処理などは、セレクタを使ってちょろっとコードを書くだけで、ほんの数行で記述できてしまいます。 しかし、この方法の延長で、大規模なJSアプリケーションを構築することは果たして現実的でしょうか。例えば「GMail」や「New Twitter」程度の規模のJSアプリケーションを書かなければならないとしたら、どうでしょう? 大規模なJSアプリケーションを開発するには、こういった手法を延長するのではなく、より洗練されたデザインパターンを導入する必要があります。この目的にぴったりのデザインパターンが、「MVC」デザインパターンです。 MVCパターンは、Webの世界ではサーバサイドプログラミングで広く知られ
This page is meant to be a central repository of decorator code pieces, whether useful or not <wink>. It is NOT a page to discuss decorator syntax! Feel free to add your suggestions. Please make sure example code conforms with PEP 8. Creating Well-Behaved Decorators / "Decorator decorator" Note: This is only one recipe. Others include inheritance from a standard decorator (link?), the functools @w
ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家(ドメインエキスパート)ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
JavaScriptパターン ―優れたアプリケーションのための作法posted with amazlet at 11.03.08Stoyan Stefanov オライリージャパン 売り上げランキング: 1642 Amazon.co.jp で詳細を見る id:uupaa さんが良い本とTwitter上で言っていたので、勢いで買って一気に読んだ。索引も含めて200ページ程度の本なので、JavaScriptがガッツリ書ける人であれば1時間弱、中級者程度でも2時間強もあれば一通り読めると思う。 感想とか、各章で個人的に気になったところとか 多少「これ書かなくてもいいんじゃね?」的な感じを受けた箇所があったが、上級者を目指す中級レベルのJSerは読んだほうが良さそうな気がする。個人的には自己流?でやっていたことがパターンとして記載されていて、概ね正しいことをしていたんだなぁと再確認できてよかった。
Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす
MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基本的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません><) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの本来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF
あると便利ですよね、ということで書いてみた。 よくあるコーディングパターンには yield とか使ってないです。 こっちの方がよくありそうでしょ? Select 全ての要素に何らかの処理を行いたいときに使用します。 // よくあるコーディングパターンその1 // 全ての要素を2倍するメソッド public IEnumerable<int> DoubleAll(int[] target) { var result = new int[target.Length]; for (int i = 0; i < target.Length; i++) { result[i] = target[i] * 2; } return result; } // Selectで書き直し public IEnumerable<int> DoubleAll(IEnumerable<int> target) { re
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く