Visitor パターン再考 - Qiita
オブジェクト指向 Advent Calendar というものを見つけたので、Visitor パターンについて書いてみます。 嘘です Visitor パターンについて書きたいけれど、Java Advent Calendar は埋まってしまってるので、それっぽい Advent Calendar に参加しただけです。別に Advent Calendar に参加しないといけない決まりなんてないんですけど。 デザインパターン Visitor パターンとは、デザインパターンの一つです。 そもそもデザインパターンとは何かというと、1995 年に Gamma らが "Gang of Four"、俗にいう GoF で提唱した、オブジェクト指向プログラミングによって特定領域の問題を解決しようとする際に頻出するイディオムのようなものです。 GoF で提唱されたデザインパターンは多くありますが、1995 年に発表
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
クラスとは何かを集合論から考えなおす - 2009-03-08 - きしだのはてな
いま論理学とか集合論とかを勉強してるので、クラスって何かという話のときも集合論として考えてた。 なので、そのとき考えたことをまとめておく。 まず、「なにか」があるとする。「なにか」はなんでもいい。 そして、その「なにか」の集合を考える。たとえば"aaa"や"bbb"を要素とするStringという集合を考える。3とか5とかを要素とするIntegerという集合を考える。 ここで、その集合がなにを扱うかという規則をどうするかというのがオブジェクト指向としては大切になるかもしれないけど、今回はそこには触れないでおく。 とにかく、「なにか」と『「なにか」の集合』を考えることをここでは大切にする。 これで『「なにか」の集合』を考えたところで、『「なにか」の集合』を要素とする集合を考えて、この集合をクラスとする。つまり、クラスという集合は、StringやIntegerといった集合を要素にもつ。 ここで、
Java 的オブジェクト指向を 90 分で理解する - 偏見プログラマの語り！
1. 分からない。いくら説明を読んでも分からない。 ● 1.1. 未だに分からない Java 的オブジェクト指向 今日び Java 的オブジェクト指向の説明なんて星の数ほどあるような気がしますが、それでもなお「これで分かった！」という説明に辿りつけない不運な人がいるようですね。まぁこんだけ色々な説明が溢れていたら逆にどれを読めば良いのかワケ分からなくなってしまうのかもしれません。じっくり読んでも理解できなかったのであれば、きっとその説明と読者の相性が悪かったんでしょう。… というわけで、僕も Java 的オブジェクト指向が全っっっっ然これっぽっちも分からないという人に向けて説明する記事を書こうと思います。そうでない人には無価値な記事ですのでブラウザの「戻る」をクリックしましょう。 ● 1.2. 「オブジェクト指向」という名の南の島がある オブジェクト指向にはいくつもの専門用語があって、学習
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
