List of Object-Oriented [text.Baldanders.info]

「おもしろい技術書」

2026-07-28T06:06:01+00:00

またまた Bluesky で見かけたネタだが，「おもしろいと思った技術書教えてください」に対する結城浩さんの回答が面白かった。

おもしろいと思った技術書教えてください | mond

そういや，子どもは夏休みに入ってるんだよね。読書感想文に悩む季節ですなぁ。これは度々書いてるけど，私は小学生の時に学習参考書の読書感想文を書いて，市のコンクールで賞をもらった男です。どやっ！

というわけで，個人的に面白いと思った技術関連本をいくつか挙げてみる。子どもが読んでも全然構わないけど，たぶん子ども向けではないのであしからず。

K&R

結城浩さんの回答にもあった『プログラミング言語C』がこれ。

プログラミング言語C - 共立出版: Brian W.カーニハン著; Release 1989-06-15; 評価

[Comment] 通称 “K&R”。初版当時のプログラマには「バイブル」と呼ばれた名著。現在は ANSI 準拠の第2版。

原著者の頭文字を取って “K&R” と呼ばれたりする（著者のひとりである Dennis M. Ritchie さんは C 言語の作者でもある）。現在は C 言語の規格バージョンも ISO/IEC 9899:2024 (C24) まで進み K&R よりも優れた技術参考書がたくさんあるが，当時は国際規格すらなく C 言語の教科書と言える本は殆どこれだけで，それ故に「バイブル」などと呼ばれてもいた。

私は真面目にプログラミングを習ったのが IT 業界に入ってからで¹ しかもアセンブラからの入門だったので，初めて C 言語を習ったときは「なんて素晴らしい言語なんだ」と感動したものである。特に感動したのがポインタ演算。たとえば char 型のポインタ変数をインクリメントしたときと short 型のポインタ変数をインクリメントしたときで，ポインタ値の増分が異なるんだよ。凄くね！

同じく Brian W. Kernighan さんによる『カーニハンのUNIX回顧録』に C 言語が誕生した経緯や『プログラミング言語C』執筆当時の話が載っている。

デニスに本作りに関わってもらうようにしたことは，私の技術的な経歴において最も賢明で，あるいは最も幸運なことだった．デニスが共著者となり，彼のリファレンスマニュアルを含めることができたため，本は信頼のおけるものとなったのである．

[…]

本文のテキストは何度も互いにやり取りしたため，二人の文体は融合しているが，リファレンスマニュアルは，デニスの文章の純粋な見本として，ほぼ元あったままにした．この部分は，かつてビル・プラウガーが評した「ぞくぞくするような精密さ」をもって言語を解説している．リファレンスマニュアルは，Cそれ自身のように，正確で，洗練され，簡潔である．

『カーニハンのUNIX回顧録』第4章 p.86より

プログラミング言語の技術参考書を探すときに苦労するのが，言語の使い方を解説したものは多くあるのに言語そのものを解説した本は少ないということだ。どんな言語であれ，プログラミング言語にはそれぞれ作者の思想が根底にあり，それに基づいて言語仕様上の制約が課せられている。これを理解しないと次のステップ（イディオムとかライブラリ・フレームワークとか）に進めないと思う。

プログラミング言語 Go

プログラミング言語Go - 丸善出版理工・医学・人文社会科学の専門書出版社: 明解で効率的なプログラムを描くための書。柴田　芳樹訳; Release 2016-06-15; 評価

[Comment] 著者のひとりは，あの “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

原著者の一人は前節で紹介した Brian W. Kernighan さんである。 Go 言語そのものについて丁寧かつ誠実に書かれた良書であるが，残念ながら内容が古くなってしまった。しかも日本語版は絶版状態らしい。改訂版の予定はないとのこと。

Go 言語は非常にシンプルな言語で，いまだに言語固有のキーワード（予約語）が25個で変わらない。

The following keywords are reserved and may not be used as identifiers.

break        default      func         interface    select
case         defer        go           map          struct
chan         else         goto         package      switch
const        fallthrough  if           range        type
continue     for          import       return       var

via The Go Programming Language Specification - The Go Programming Language

言語仕様全体も1枚の Web ページに収まる分量である。言い方を変えると，このシンプルさ（を保つこと）こそが Go 最大の制約なのである。

私は仕事では様々なプログラミング言語を変遷しているが「母国語」と言えるものは C 言語だった。でも Go 言語を知って以降「母国語」が Go 言語になった。五十路に入って「母国語」が変わるとかそうそうないだろう。

そうなったのも『プログラミング言語Go』の影響が大きいと思っている。そのくらい私にとってインパクトのある本である。

デザインパターン本

Java言語で学ぶデザインパターン入門第3版 | SBクリエイティブ: 「GoF」の『デザインパターン』で紹介された23個のパターンを、オブジェクト指向の初心者にもわかるようにやさし; Release 2021-11-13; 評価

[Comment] なんと！結城浩さんのデザパタ本の第3版が出た。古典的な GoF のデザインパターン23個はそのままに，最近の Java の言語仕様に合わせてコードが一新されている。

いわゆる Gang of Four（GoF）による古典的なデザインパターンを解説した本である。ちなみに，結城浩さんのデザパタ本にはマルチスレッド編もある。

原典の翻訳本もあるが，結城浩さんの著書はどれも平易な文章で読みやすくお勧めである。

Java を前提に書かれているが，もちろん他の言語でも応用できる。デザインパターンでググったら様々な言語で実装している例が見つかると思う。

ただし古典なだけあって，今では使わないほうが良いとされるパターンがあったり，言語によっては実装が難しいものもある。

Go 言語で Factory Method Pattern を構成できるか

先日『実用 Go言語第2版』の読書会で

なお、昔は GoF のデザインパターンに取り上げられたこともあり、テンプレートメソッドパターンが王道とされてきましたが、このパターンを使うには、必ずサブタイプを実装しなければなりません。近年では、クロージャやラムダといった要素を備えた言語が増えています。C++ も C++11 からクロージャが使えるようになり、GUI フレームワークの Qt も、関数オブジェクトでハンドラーが記述できるようになりました。このストラテジーパターンへの移行は Go に限らず、プログラミング言語の全体的な流れと言えます。

『実用 Go言語第2版』3章 p.83より

という記述があって「GoF って知ってる？」という話からデザパタ本の話になった。デザパタ本って GoF 版をベースにしているせいか出版年がどれも古くて，若い人だと知らなかったりするんじゃないだろうか。

とはいえ Iterator とか Factory とか Proxy とか Decorator とか Adapter とか… 今でもよく目にする（けど初見で面食らう）単語も多いので，読んでおいて損はないと思う。

その他の読み物

これは技術参考書と言うより読み物に近いかな。

Clean Architecture 達人に学ぶソフトウェアの構造と設計 | ZEN大学出版会: Clean Architecture 達人に学ぶソフトウェアの構造と設計について、詳細・ご購入はこちらから; Release 2026-07-10; 評価

[Comment] 実務に即効性があるわけではないが，ものの「考え方」を示す本としてはよく出来ている。ソフトウェア技術史の読み物としても面白い。

いつの間にか発行元がZEN大学出版会に変わっとるがな。 ASCII 版は Kindle 版が引き上げられてて絶版になってるのか？慌てて私の Kindle ライブラリの中を見たが，既に買っているものはまだ見れるようだ。そのうち読めなくなるのかね。理工系の本でデジタル版がないとかありえないのだが。

中身は良書。原著は2017年に出版されている。

「明日から Clean Architecture で実装するぞ」とはいかないと思うけど，ものの「考え方」を示す本としてはよく出来ていると思う。「構造化プログラミングとかオブジェクト指向とか関数型とかって何？」ってあたりから SOLID などの原則の説明まで一通り網羅されていて用語の勉強にもなるだろう。回顧録みたいにもなってるので，ソフトウェア技術史の読み物としても面白い。

ちょうぜつソフトウェア設計入門 | 技術評論社: SoftwareDesign誌での連載と技術アドベントカレンダー24回ぶんに収まらなかった関連知識を徹底解説。いわゆる「オブジェクト指向」と呼ばれる考え方から発展した分野は、どのようにソフトウェア設計の役に立つのかを、よく知られた原則、テスト駆動開発、デザインパターンなどを通じて理解できる一冊です。上級者には定番の知識を体系的に整理するヒントとして、初級者には可愛いイラストで覚えるキーワード集として、幅広く活用していくことができます。なお、サンプルコードはPHPで書かれていますが、他の言語に置き換えて読めるコードばかりです。PHPを使っているかどうかを問わず、全ての開発者にオススメです。; Release 2022-12-07; 評価

[Comment] 祝♪ #ちょうぜつエンジニアめもりーちゃん単行本化！絵は可愛いが読み応えあり。「SoftwareDesign」連載分も収録されていて超お得！

𝕏 を見なくなったのだが，めもりーちゃんの更新は細々と行われているようだ。

初っ端がマンガなので面食らうが，中身は割とハード。技術系の読み物としてお勧めである。版元でなら PDF で買えるし（←重要）。

前節でちょろんと紹介した Template パターンと Strategy パターンの比較の話も載っている。

ブックマーク

「読書感想文は、ただちに「面白かった本のお勧め文」に名目を変えるべき」ではない

参考

カーニハンのUNIX回顧録 - 丸善出版理工・医学・人文社会科学の専門書出版社: Unixとは何であり，どのように生まれ，なぜ重要なのかを説明する，コンピュータ史上でも特に生産的だった形成期の素晴らしい物語ブライアン・カーニハン著; Release 2025-09-24; 評価

実用 Go言語第2版: 文法はシンプルで学びやすいという特徴を持つGo言語。システム開発の現場でも使われる機会が増えていますが、複雑な要件を実現するにはプログラミング言語が提供するシンプルな構成要素（文法やライブラリ）を、さまざまに組み合わせます。本書は「よりGoらしく書くには」「実用的なアプリケーションを書くには」といった観点からGoを使うポイントを紹介します。構造体やインタフェース、またJSON、CSVファイル、Excel、固定長ファイルの扱い方、ログやテスト、環境構築など、また初版の発行後、Goに追加されたジェネリクスについても紹介。現場に即した幅広いトピックについて、「Goらしいプログラムの書き方」を、その背景と共に教えてくれる先輩のような書籍です。; Release 2025-12-01; 評価

最初に入った会社の3ヶ月研修で情報処理1種資格相当の座学とアセンブラと C 言語を叩き込まれた。一応，学生時代に BASIC と Fortran は習ったが，お遊び程度だったと言っておこう。 ↩︎

それは Duck Typing ぢゃない（らしい）

2020-04-10T10:37:23+00:00

今回は Go と Rust との比較をちょっとポエミーに語ってみる（笑）

そもそも duck typing は Ruby のような動的型付け言語における型推論の手法（のひとつ）である。その由来は duck test から来ていて

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

via Duck test - Wikipedia

というフレーズに集約されている。

静的型付け言語である Go や Rust における抽象型を使った型決定を duck typing と呼ぶのは厳密には正しくない，らしい。 Go や Rust における interface や trait といった抽象型を用いた型決定は「部分型付け（subtyping）」と呼ばれる。ただし Go と Rust では全く異なる戦略をとる。

Cat コマンドもどき（Go 版）

ここで簡単なプログラムを書いてみよう。 UNIX 系のプラットフォームではおなじみの cat コマンドの「もどき」を書いてみる。

本来の cat コマンドは複数の入力を結合（concatenate）して出力するものだが，真面目な実装をし始めるとキリがないので，今回は以下の2つの機能のみ実装する。

コマンドライン引数で指定したファイルを1つのみ標準出力に出力する
ファイルの指定がない場合は標準入力をそのまま標準出力に出力する

ぶっちゃけ，ただの「土管」である（笑）これを Go で書いたのが以下のコードだ。

package main

import (
    "fmt"
    "io"
    "os"
)

func concatenate(w io.Writer, r io.Reader) error {
    _, err := io.Copy(w, r)
    return err
}

func main() {
    if len(os.Args) > 1 {
        file, err := os.Open(os.Args[1])
        if err != nil {
            fmt.Fprintln(os.Stderr, err)
            return
        }
        defer file.Close()

        if err := concatenate(os.Stdout, file); err != nil {
            fmt.Fprintln(os.Stderr, err)
            return
        }
    } else {
        if err := concatenate(os.Stdout, os.Stdin); err != nil {
            fmt.Fprintln(os.Stderr, err)
            return
        }
    }
}

concatenate() 関数がメインのロジックで，引数の io.Writer, io.Reader および返り値の error は全て interface 型である。まぁ concatenate() 関数を括り出す必然性は全くないのだが，後述の Rust のコードと比較しやすいよう敢えて分けている。

concatenate() 関数の呼び出しで，最初の

if err := concatenate(os.Stdout, file); err != nil {
    fmt.Fprintln(os.Stderr, err)
    return
}

と次の

if err := concatenate(os.Stdout, os.Stdin); err != nil {
    fmt.Fprintln(os.Stderr, err)
    return
}

は（当然ながら）同じ関数で，引数や返り値にどのようなインスタンスが入るかは実行時に決まる。コンパイル時に決まるのは注入するインスタンスの構造が受け入れる interface 型の構造と合致していることだけだ（合致しなければコンパイル・エラー）。

すンごい簡単に書かれているけど，これは「依存の注入（depencency injection）」の典型例である。

では，これをリファレンスとして，今度は Rust を使って書いてみる。

Cat コマンドもどき（Rust 版，総称型編）

とりあえず，えいやっで書いたコードがこちら。

fn concatenate<W, R>(w: &mut W, r: &mut R) -> Result<(), std::io::Error>
where
    W: std::io::Write,
    R: std::io::Read,
{
    let mut buf = Vec::new();
    r.read_to_end(&mut buf)?;
    w.write_all(&buf)?;
    Ok(())
}

fn main() -> Result<(), std::io::Error> {
    let args = std::env::args();
    if args.len() > 1 {
        for s in args.skip(1).take(1) {
            concatenate(
                &mut std::io::stdout(),
                &mut std::io::BufReader::new(std::fs::File::open(s)?),
            )?;
        }
    } else {
        concatenate(&mut std::io::stdout(), &mut std::io::stdin())?;
    }
    Ok(())
}

std::io::Write と std::io::Read が trait 型なのだが，各 trait は総称型 W, R の制約条件として書かれているだけで実行時に機能するわけではない。つまり最初の

concatenate(
    &mut std::io::stdout(),
    &mut std::io::BufReader::new(std::fs::File::open(s)?),
)?;

と次の

concatenate(&mut std::io::stdout(), &mut std::io::stdin())?;

はコンパイル時に別の関数として展開される¹。これを（多態化（polymorphization）に対する）単態化（monomorphization）と呼ぶ。

じゃあ Rust では依存の注入は書けないのかというと，勿論そんなことはない。

Cat コマンドもどき（Rust 版，依存注入編）

依存の注入ができるように書き換えたバージョンがこれ。

fn concatenate(
    w: &mut Box<dyn std::io::Write>,
    r: &mut Box<dyn std::io::Read>,
) -> Result<(), Box<dyn std::error::Error>> {
    let mut buf = Vec::new();
    r.read_to_end(&mut buf)?;
    w.write_all(&buf)?;
    Ok(())
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let args = std::env::args();
    let mut r: Box<dyn std::io::Read> = if args.len() > 1 {
        let fnam = match args.skip(1).next() {
            Some(s) => s,
            _ => "".to_string(),
        };
        Box::new(std::io::BufReader::new(std::fs::File::open(fnam)?))
    } else {
        Box::new(std::io::stdin())
    };
    let mut w: Box<dyn std::io::Write> = Box::new(std::io::stdout());
    concatenate(&mut w, &mut r)?;
    Ok(())
}

concatenate() 関数が同一のものであることを強調するために呼び出しをひとつに纏めているので少しまだるこしい書き方になっているが，ご容赦。このように Rust では trait 型を Box<dyn Trait> の形式に落とし込むことで実行時の動的ディスパッチを可能にしている。

Accept Interfaces, Return Structs

Go の設計指針で有名な言葉に accept interfaces, return structs というのがある。私自身は必ずしもこれに賛同しないが（システム内部のコンテキスト境界は interface にすべき），この指針は Go の特徴をよく表している。

たとえば io.Reader と os.File は Read() 関数という「同じ振る舞いを持つ」点で関連しているけど，両者の間に明示された記述は存在しない²。それでも，その関係を以って io.Reader に os.File インスタンスを注入可能であり「Go では duck typing ができる」とか言われる所以である。 Go プログラマは息をするように依存を注入するのだ。

このような関係を構造型の部分型付け（structural subtyping）と呼ぶそうな。

構造型と公称型

Go の interface 型が構造型の部分型付けであるのに対し Rust の trait 型は公称型の部分型付け（nominal subtyping）に分類されるだろう。たとえば std::io::Read と std::fs::File との間にはコード上で明示された関連がある。その「明示された関連」がなければ，たとえ同じ構造を持っていたとしても，両者の間に関係があるとは見なされないのだ。

Rust の言語仕様がこのような制約を構成しているのには，勿論ちゃんとした理由がある。

Go においてはメモリ管理や並列処理³ といった面倒事をランタイム・モジュールに「丸投げ」している。なので，プログラマは富豪的な記述に専念できるが，バイナリは肥大化してしまうしコンパイル時の最適化にも限度がある⁴。

Rust はリソース管理等についてプログラマ側でかなり面倒を見なければならないが（それでも C/C++ などに比べれば全然楽だし安全），言い換えればコード上でのコントロールがし易くコンパイル時の最適化についても期待できる。上述の cat コマンドもどきでも，コンパイル時の単態化を避けるコードをわざわざ書く理由はないだろう。

これはプログラム設計時の重要なトレードオフとなる。まぁ「Go か Rust か」みたいな究極の選択をする状況はないと思うが，複数のプログラミング言語からどれかを選ぶ際にはこういったことも考慮していくべきだ（選ぶ余裕もない事案のほうが多いだろうけどw）。

前にも書いたが，「それができる」ことと「そのように作られている」ことには天と地ほどの違いがある。どうせ「書く」なら無茶せず楽しく書きたいものである。

ブックマーク

Rustでファイルの入出力 - Qiita
RustのファイルI/OにはBufReader, BufWriterを使いましょう、という話 - Qiita
Go言語のInterfaceの考え方、Accept interfaces,return structs - Qiita
継承できないなら注入すればいいじゃない！ : Go のイベント用に作ったスライド

参考図書

プログラミング言語Rust 公式ガイド: Steve Klabnik (著), Carol Nichols (著), 尾崎亮太 (翻訳); KADOKAWA 2019-06-28 (Release 2019-06-28); 単行本; 4048930702 (ASIN), 9784048930703 (EAN), 4048930702 (ISBN); 評価

[Comment] 公式ドキュメントの日本語版。索引がちゃんとしているので，紙の本を買っておいて手元に置いておくのが吉。

reviewed by Spiegel on 2020-02-24 (powered by PA-APIv5)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

[Comment] 著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

Go言語による並行処理: Katherine Cox-Buday (著), 山口能迪 (翻訳); オライリージャパン 2018-10-26; 単行本（ソフトカバー）; 4873118468 (ASIN), 9784873118468 (EAN), 4873118468 (ISBN); 評価

[Comment] Eブック版もある。感想はこちら。 Go 言語で並行処理を書くならこの本は必読書になるだろう。

reviewed by Spiegel on 2020-01-13 (powered by PA-APIv5)

余談だが Rust では「ファイルを閉じる」操作は変数の生存期間満了時に暗黙的に行われるようだ。明示的に閉じるには drop 関数を使う。 ↩︎
たとえば var _ io.Reader = (*os.File)(nil) のような記述で関連を明示することは可能。これはパッケージを書く際によく用いられる手法で，実行バイナリには反映されないが，事実上のコンパイラ・ヒントとして機能する。 ↩︎
Go における並行処理と並列処理の違いについては『Go言語による並行処理』を読むことを強くおすすめする。 ↩︎
近年，特に組込み用途で注目されている TinyGo は LLVM 上で動作することを前提としていて，本家 Go に比べてかなり小さい実行バイナリを吐けるらしい。 ↩︎

技術的負債としての「オブジェクト指向」

2019-07-28T11:47:23+00:00

「オブジェクト指向プログラミングは1兆ドル規模の大失敗なのか？ - YAMDAS現更新履歴」より。

邦訳を公開してくださった方，マジ感謝です。英語不得手な私には大変ありがたい。

「1兆ドル」という見積もりが妥当かどうかはともかく¹，オブジェクト指向設計あるいはプログラミングが究極ではないという意味なら同意できるし「その先」に進むべきというのも分かる。更にこれからプログラミング言語を学ぶなら関数型を学べという点についても激しく同意する。

どういうわけか日本人は Java が大好きで，確かにあと数年は飯の種になるだろうが，将来を見据えれば Java は間違いなく COBOL と同じ道をたどる。

Java はやめておけより

そういう意味で Java のようなレガシーなプログラミング言語が将来的な技術的負債になるのは間違いないと思う。まぁ「みずほ」のような大災害はそうそう起こらないだろうけど（笑）

でもそれが「オブジェクト指向」故の問題かと言われれば，ちょっと考えるところでもある。

オブジェクト指向設計とオブジェクト指向プログラミング

ひとくちに「オブジェクト指向」と言うが「設計」と「プログラミング」は分けて考える必要がある。「プログラミング」はどうしても言語仕様に依存してしまうが，「設計」は言語に依存しないしするべきではない。

研究分野についてはよく知らないのでスルーするが，産業分野に於いて「オブジェクト指向」とは制御単位としての「オブジェクト」と「オブジェクト」同士の関係を「記述」することだ。つまり「制御」を主体に設計するならば「オブジェクト」そのものに着目せざるを得ない。

これが，それまでの「構造化プログラミング」からの発展としての「オブジェクト指向」である。

さぁ，例外（おまえ）の罪を数えろ！

私が数年前に Go 言語を習い始めて驚いたのは「例外がない」ことだった²。

例外が抱える問題というのは本質的に goto 文の問題と同じ。オブジェクトの状態ごと脱出するため，（脱出前ではなく）脱出後にオブジェクトの後始末を記述せざるを得ないし，記述するためには脱出前の状態（の可能性）を「知識」として知っていなければならない。もし後始末をきちんとしないと，それがバグやリークやその他の脆弱性のもとになる。

エラー・ハンドリングについてより

例外処理を行うためにはオブジェクトの内部状態に外部からアクセスする手段を実装する必要がある。これが「オブジェクト指向」プログラミングを狂わせる要因のひとつになっている，と思う。

Go 言語ではエラー・ハンドリングの問題を tupple と defer 構文というシンプルな言語仕様によって解決している。これを知ったときはマジで感動したね。ほんでもって，私が Go 言語に傾倒する理由のひとつになっている。

具象から抽象へ記述する

これも以前に書いたことだが Go 言語では汎化・特化の関係を記述する手段として interface 型が存在する。 Interface 型は duck typing と勘違いされることもあるが（私もそう思っていた），実は「構造的部分型（structural subtyping）」と呼ばれるもので，オブジェクトの「ふるまい」のみを定義する³。

たとえばウォータフォール型の開発スタイルでは実装を開始するまでに設計が終わることが（建前上は）保証されているため「抽象→具象」へと書き進めることが容易な言語が向いている。一方，要件が絶えず変わったり実験的な製品の場合は設計が終わるまで待っていられないため Go 言語のような言語が向いてるかもしれない。

きみは Generics がとくいなフレンズなんだね，または「制約は構造を生む」より

私が「プログラマも要件定義から参加すべき」と思うようになったのは Go 言語を知ってからだ。他の流行りの言語でもそうだろうが，今やプログラミングは文芸的になりつつありプログラマ間のコミュニケーション「言語」にもなりつつある。

Don’t Talk to Strangers

「オブジェクト指向」設計およびプログラミングには don't talk to strangers の原則があり，いわゆる「友達の友達」のことは知らないふりをするのがよい設計と言われている。つまり「オブジェクト指向」で重要なのは「オブジェクト」ではなく，その「関係」であるというわけだ。

I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.
- Alan Kay, the inventor of OOP

via Object-Oriented Programming — The Trillion Dollar Disaster

引用の引用でスマン。

たとえば REST (REpresentational State Transfer) と呼ばれる分散システムにおける設計原則がある。でも REST って上で言うところの「オブジェクト指向」そのものだよね。 REST の背景には多分「オブジェクト指向」の考え方があるのかもしれないが，そもそも分散システムの設計における必然から生まれたものでもある。

結局のところ…

「オブジェクト指向」が云々なんてのは些末なことで，その時のトレンドによって要求は変わるし，要求の変化に伴って設計やプログラミングも変化するのだから拘っても仕方がない。

大事なことは，そうした「変化」のタイムスケールが，かつて感覚で考えていたよりもずいぶん小さいものであり，サボることなく対応していかなければあっという間に技術的負債になってしまうということだろう。そのための DevOps や OODA や PDCA なんじゃないの，と思うわけだ。

まぁ，既に職業エンジニアを廃業し現場から遠ざかったロートルが言うことじゃないけどさ。

ブックマーク

「null 参照」の損失を10億ドルと見積った人もいたな。こういう競馬の予想屋 (経済アナリスト) みたいなやり口は好かんのだがなぁ。 ↩︎
Go 言語には panic という「例外」に似た仕組みはあるが，これは文字通りプログラム続行不可能な状態で強制終了させるための仕組みであり「例外」のように運用すべきではないとされている。 ↩︎
Duck typing は主に動的型付け言語における型推論方式（のひとつ）で，クラス間の関係を記述するものではないらしい。ちなみに構造的部分型に対する言葉として「公称型（nominal subtyping）」というのがあって C++ や Java におけるテンプレート・クラスやインタフェース・クラスを使った汎化・特化関係を指す場合に使うそうだ。 ↩︎

Go 言語で Factory Method Pattern を構成できるか

2018-12-30T06:24:48+00:00

少し前に面白い記事を見かけたのだが

Go言語で factory method パターンを書いてみる - Qiita

「これって factory method pattern じゃないよね」と思いつつ「Go 言語には「継承」がない」ことを説明する好例だと気付いたので今回の記事を書いてみた。

Factory Method Pattern とは

まずは factory method pattern の解説から。以下にクラス図を示す。

Product は抽象クラスで ConcreteProduct が Product の実装クラスである。 Creator クラスの factoryMethod() メソッドは Product インスタンスを返す抽象メソッドで，サブクラスの ConcreteCreator で実装されている。

Creator クラスを利用する側はサブクラスの ConcreteCreator を Creator クラスとして生成し anOperation() メソッドをキックする。

ポイントは anOperation() メソッドが実装メソッドで，内部では factoryMethod() メソッドが呼ばれている点である。ただし Creator インスタンスの実体は ConcreteCreator クラスなので， anOperation() メソッドから呼ばれるのはオーバーライドされた ConcreteCreator のほうの factoryMethod() であることが期待される，というわけだ。

本来なら Creator インスタント生成時にどの ConcreteProduct インスタンスを（Product クラスとして）使うのか判断すればいいのだが（これが factory pattern），それだと ConcreteProduct クラスが増えるたびに Creator クラスも修正しなければならず管理が煩雑になる。

そこで ConcreteProduct クラスと一対一に対応する ConcreteCreator クラスをつくり，その中でどの ConcreteProduct インスタンスを（Product クラスとして）使うのか判断している，つまり「インスタンス作成をサブクラスにまかせる」のである。

Go 言語には「継承（Inheritance）」がない

しかし，このデザイン・パターンは Go 言語では使えない。何故なら「Go 言語には「継承」がない」からである。

汎化と構造的部分型（Structural Subtyping）

Go 言語ではクラス間の「汎化」関係を実装する手段として interface 型を持っているが，これは「振る舞い」のみを定義する。先程の Creator クラスのように抽象メソッドと実装メソッドをひとつのクラスの中に混ぜ込むことはできない。 Interface のような型を一般的には「構造的部分型」と呼ぶらしい¹。

埋め込み（Embedding）と委譲（Delegation）

もうひとつ Go 言語には型を構造体のフィールドとして埋め込む機能がある。たとえば

type parent struct{}

という型があるとして

type child struct {
    parent
}

とすれば child 型は parent 型の属性や操作をそのまま使うことができる。こんな感じ。

package main

import "fmt"

type parent struct{}

func (p parent) Say() string {
    return "I'm parent type."
}

type child struct {
    parent
}

func main() {
    p := parent{}
    c := child{}
    fmt.Println(p.Say())
    fmt.Println(c.Say())
    //Output:
    //I'm parent type.
    //I'm parent type.
}

これで child 型は parent 型を（擬似的に）継承しているように見える。更に child 型に対して

func (c child) Say() string {
    return "I'm child type."
}

という関数を追加すれば

package main

import "fmt"

type parent struct{}

func (p parent) Say() string {
    return "I'm parent type."
}

type child struct {
    parent
}

func (c child) Say() string {
    return "I'm child type."
}

func main() {
    p := parent{}
    c := child{}
    fmt.Println(p.Say())
    fmt.Println(c.Say())
    //Output:
    //I'm parent type.
    //I'm child type.
}

という感じになり child 型の Say() 関数が parent 型の Say() 関数をオーバーライドしているように見える。ところが parent 型に

func (p parent) Speek() {
    fmt.Println(p.Say())
}

という関数を追加し，これを使って喋らせてみると

package main

import "fmt"

type parent struct{}

func (p parent) Say() string {
    return "I'm parent type."
}

func (p parent) Speek() {
    fmt.Println(p.Say())
}

type child struct {
    parent
}

func (c child) Say() string {
    return "I'm child type."
}

func main() {
    c := child{}
    fmt.Println(c.Say())
    c.Speek()
    //Output:
    //I'm child type.
    //I'm parent type.
}

となり Speek() 関数はあくまでも parent 型の Say() 関数を呼び出していることが分かる。

実は Go 言語の埋め込みフィールドは「継承」ではなく「委譲」として機能する。したがって C++ や Java の仮想関数のようにメソッドがオーバーライドされることもない。型の中で関数名が被った際の暗黙の優先順位は決められているためオーバーライドしているように見えるだけなのである。

これを先程の factory method pattern のクラス図に当てはめて考えると Go 言語で無理やり実装しようとしても

という感じになり，そもそも Creator を抽象クラスに（polymorphic に）できないし，サブクラスの ConcreteCreator から anOperation() メソッドを呼び出しても内部で呼び出される factoryMethod() メソッドは Creator クラスのものということになる。

「継承」できないなら「注入」すればいいじゃない

さて，どうしようか。とりあえずコードを書きながら考えてみよう。

最初に紹介した記事を参考にしつつ，まずは Product に相当する interface 型を以下のように定義するところから始めようか。

//Human is Product class of factory method pattern
type Human interface {
    SelfIntroduction() string
}

続いて ConcreteProduct に相当する型も定義する。

//NamedHuman is parent class with name property
type NamedHuman struct {
    MyName string
}

func (nh NamedHuman) Name() string {
    if len(nh.MyName) == 0 {
        return "〈名無し〉"
    }
    return nh.MyName
}

//Man is Concrete Product class of factory method pattern
type Man struct {
    NamedHuman
}

func (hm Man) SelfIntroduction() string {
    return hm.Name() + "だぜ！"
}

//woman is Concrete Product class of factory method pattern
type Woman struct {
    NamedHuman
}

func (hm Woman) SelfIntroduction() string {
    return hm.Name() + "よ！"
}

ちょっと分かりにくいかも知れないが，クラス図にすると

となっていて Man 型および Woman 型が（Human 型に対する） ConcreteProduct クラスに相当するのが分かると思う。ちょろんと動かしてみよう。

func NewMan(name string) Human {
    m := &Man{}
    m.MyName = name
    return m
}
func NewWoman(name string) Human {
    w := &Woman{}
    w.MyName = name
    return w
}
func main() {
    h1 := NewMan("太郎")
    h2 := NewWoman("花子")
    fmt.Println(h1.SelfIntroduction())
    fmt.Println(h2.SelfIntroduction())
    //Output:
    //太郎だぜ！
    //花子よ！
}

問題なく動作することが確認できた。

ここまで書いたコードを眺めてみると NewMan() および NewWoman() 関数が factoryMethod() メソッドと似た機能を有していることが分かる。じゃあ，これらの関数を実行時に Creator クラスに埋め込むように構成すればいんじゃね？

さっそく書いてみよう。

//Speaker is Creator class of factory method pattern
type Speaker struct {
    createHuman func(string) Human
}

func (s Speaker) Speech(name string) {
    hm := s.createHuman(name)
    fmt.Println(hm.SelfIntroduction())
}

createHuman は関数型のメンバ変数で func(string) Human のインタフェースを持つ関数を表す。これはすなわち NewMan() および NewWoman() 関数のことである。

それでは実際に動かしてみよう。

func NewSpeeker(f func(string) Human) *Speaker {
    return &Speaker{createHuman: f}
}

func main() {
    s1 := NewSpeeker(NewMan)
    s2 := NewSpeeker(NewWoman)
    s1.Speech("太郎")
    s2.Speech("花子")
    //Output:
    //太郎だぜ！
    //花子よ！
}

よーし，うむうむ，よーし。クラス図にするとこんな感じだろうか（factory method pattern のクラス図と比較してみよう）。

これってだいぶ不格好だけど，まさしく依存（オブジェクト）の注入（dependency injection pattern）だよね²。

ていうか Go 言語プログラマは error 型や標準パッケージの io.Reader などを通じて息をするように「依存の注入」を行っているわけで，「継承できないなら注入すればいいじゃない」という感じで，自国語に得意なパターンへ持ち込むのが得策だと思う。

ブックマーク

Factory Method パターン - Wikipedia : クラス図はこちらを参考にした
Dependency injection - Wikipedia : 英語版と日本語版でかなり内容が異なるのだが大丈夫か？
Go 言語における「オブジェクト」

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

増補改訂版 Java言語で学ぶデザインパターン入門: 結城浩 (著); SBクリエイティブ 2004-06-18 (Release 2014-03-12); Kindle版; B00I8ATHGW (ASIN); 評価

[Comment] 結城浩さんによる通称「デザパタ本」。 Java 以外でも使える優れもの。

reviewed by Spiegel on 2016-01-05 (powered by PA-APIv5)

Interface 型の性質を示すものとして duck typing がよく挙げられる。私も以前はそう思っていたが duck typing は動的型付き言語で型を決定する手法（のひとつ）を指すのだそうだ。もちろん Go 言語は静的型付き言語なのでこれに当てはまらない。じゃあ Go 言語の interface 型は何かというと「構造的部分型」と呼ぶのが正しいようだ。 ↩︎
私は dependency injection を「依存性の注入」と訳すことに懐疑的だという主張に同意します。 ↩︎

Kotlin の予備学習

2018-12-02T06:07:36+00:00

The State of the Octoverse: top programming languages of 2018 | The GitHub Blog

この記事の中で “Fastest growing languages by contributors as of September 30, 2018” のトップが Kotlin なのを見て「やっぱ時代は Kotlin だ！」と確信したのだが，今は忙しいので，まずは「Kotlin をふわっと覚えられる」教材を探していた。そしたら偶々 Kindle unlimited で『速習 Kotlin』という本を見かけたので予備学習教材として読んでみた。

Kotlin は Android アプリ用言語として有名になったせいか，言語そのものを解説する本はまだ少ない感じ。個人的には Kotlin/Native に期待しているので，もっと言語そのものを解説する本がたくさん出るといいな，と思ったりする。

さて『速習 Kotlin』を読んだ第一印象だが，昔 .NET Framework が登場したときに真っ先に「覚えられるか！こんなもん」と感じたのを思い出した。

Kotlin に限らないが，コード記述の全てを「オブジェクト」およびそれらの関係で表そうとすると膨大な語彙や文脈が発生する¹。故に「言語を覚える」というのは言語仕様を理解するだけでは全然足りなくて，言語に付随する語彙つまりフレームワークを習得する必要がある。無理やり喩えるなら，昔の（C言語などの）言語は「数独²」でオブジェクト指向言語は「クロスワードパズル」といった感じだろうか³。

この手の解説本でありがちなミスは，言語「仕様」と言語周辺の「知識」がゴッチャになって記述が混沌としてしまうことだ。『速習 Kotlin』にもこの傾向がある。とはいえ Int や Double といったプリミティブな型でさえクラス・オブジェクトとして定義されているのだから，この点で著者の方を責めるのは酷というものだろう。

もうひとつ気になったのが糖衣構文（syntax sugar）。既にその言語に馴染んでいる人にとっては糖衣構文は書きやすくて読みやすいのだろうが，基本のキから言語仕様を学ぼうという人にとっては毒が強すぎる気がする。これって習熟度が異なる者同士で peer review すると支障が出たりしないのか？私なら研修である程度言語に慣れるまでは糖衣構文は禁止にするぞ。

というわけで，私なら

言語仕様の理解
糖衣構文に慣れる練習
フレームワークの知識を深める

の三段構えで学習を進めていきたいところである。まずは目の前の雑事を片付けていかないといけないのだが…

参考図書

速習 Kotlin: Javaより簡単！新Android開発言語を今すぐマスター速習シリーズ: 山田祥寛 (著); WINGSプロジェクト 2018-09-26 (Release 2018-09-26); Kindle版; B07HQMNLCV (ASIN); 評価

[Comment] Kindle unlimited で読める。 Java コードと比較しながらふんわりとイメージを掴むにはよい。予備学習教材。

reviewed by Spiegel on 2018-12-02 (powered by PA-APIv5)

STARTSIDE 数独すうどく脳トレ卓上ボードゲーム 9ブロックパズル (ブラック): STARTSIDE; おもちゃ＆ホビー; B077PDFQ4S (ASIN), 4562440102073 (EAN); 評価

[Comment] 「数独」がボードゲームに（笑）

reviewed by Spiegel on 2018-12-02 (powered by PA-APIv5)

この点で Go 言語における全てを「オブジェクト指向」に包摂しようとしない設計上の割り切り方は個人的に好印象である。スクリプト言語ならともかく，バイナリ・コードにコンパイルする言語は（泥臭さを許容してでも）パフォーマンスが要求されることも多く，無理にオブジェクト指向でマニピュレータを書くより「for 文で回したほうがはやい」なんてなこともあるのだ。 ↩︎
「数独（「数字は独身に限る」の略称）」はニコリの商標である。ちなみに数独のオリジナルは米国の方が考えられた ”Number Place” なのだが，海外では “Sudoku” の名称のほうが有名である。詳しくは日経サイエンス 2006年9月号「数独の科学」を参照のこと。 ↩︎
クロスワードパズルは出題者と解答者との間で共通の語彙がなければ絶対に解けない。 ↩︎

「オブジェクト指向」の黒歴史

2018-10-11T09:54:19+00:00

（もちろんタイトルは釣りです）

Qiita で面白い記事を見かけた。

まだ「オブジェクト指向はこうあるべき」で消耗してるの?

この記事にあるオブジェクト指向の価値を利便性に置くという考え方には激しく同意する。その上で，私の黒歴史を交えて，戯れ言をいくつか書いてみよう。

「プログラミング」で最初に何を学びましたか？

最近の子らは「プログラミング」で何を学ぶのだろう。

私が学生の頃（昭和時代）， FORTRAN の授業で真っ先にやらされたのがフローチャートを書くことだった¹。ちなみに授業の最初のお題は素数を求めるプログラムだった（ありがちw）。

そもそも「コンピュータ」っていうのは，名前の通り，「計算をする機械」なわけですよ。つまりフローチャートというのは「計算する」ことをモデル化したものなわけ。だから「計算する」ことに関してはフローチャートで全て表現できる。

そう思ってた時代がありました。

それから，まぁ，紆余曲折あって（バブル最盛期に）某システムハウスに潜り込んだのだが，初仕事の設計書で書かせられたのはフローチャートではなく状態遷移表だった。むしろ「フローチャートなんか要らん（コードを見れば分かる）」と言われましたよ。これが「社会の現実」ってやつですね，分かります。

ここで社会に出たての小僧は気づくわけですよ，「コンピュータ」っていうのは「計算をする機械」ではなく「情報を処理する機械」なんだということを。そして少年は「オブジェクト指向」と出会う（笑）

「情報」ってなに？

少なくともノイマン型コンピュータにおいては，基本的に以下の3つの機能しかない。

指定したアドレスから命令をフェッチして計算する
指定したアドレスからデータを読む
指定したアドレスへデータを書く

指定したアドレス（メモリとは限らない）に何があるのか決めるのはコードを書く人間側の責務であり，それを可能とするプログラミング言語であれば「情報を処理する」ことに関しては何でもできる。

じゃあ「情報」ってなに？

「オブジェクト指向」以前の「構造化プログラミング」の時代において，情報とは「データ」と「機能」だった。しかし「データ」と「機能」だけではコードは簡単に破綻する。以前に「ハード屋が書く C ソースコードが凄まじかった思い出」という記事を書いたが，これは情報を「データ」と「機能」と考えた場合の極端例と言える。

では「構造化プログラミング」時代のソフトウェア・エンジニアのコードは何故破綻しなかったのか²。ソフトウェア・エンジニアが暗黙的に考えていたこととはなにか。その答えのひとつが情報を「オブジェクト」と考える「オブジェクト指向」設計ないしはプログラミングである。

「オブジェクト指向」設計ではオブジェクトを以下の3つの組み合わせと考えた。

名前
状態（属性）
機能（操作，手段）

特に重要なのが「名前」である。「名前」とは自と他を区別する識別子で，区別することでそこに「関係」が生まれる。

たとえば「犬は動物の一種である」というのは，「犬」と「動物」の関係が「一種である³（is-a）」ことを示す。 C++ や Java では「一種である」という関係を「クラス・オブジェクトの継承」という形で記述するが，継承は「オブジェクト指向」に必須の記述ではない。 Go 言語の構造的部分型（structural subtyping）のような記述だってあるのだ⁴。

つまり「オブジェクト指向」においてはオブジェクトとその関係をモデル化することが重要で，それを記述することができるのであればどんな言語でも構わないのである。

ちなみに「オブジェクト指向」プログラミングはアセンブラや C 言語でも記述できるし実際にそういうプロジェクトに関わったこともある（大昔の話だよ）。プログラミング言語はプログラミングの手段に過ぎないということだ。

「オブジェクト指向」の先へ

しかし今さらアセンブラや C 言語で「オブジェクト指向」なコードを書こうという人は少ない（いや，ほぼいない？）だろう。では，当時オブジェクト指向プログラミング言語と呼ばれた C++ や Java によって私達ソフトウェア・エンジニアは幸せになれたのだろうか？否である！

これは私見だけど，「オブジェクト指向」の恩恵は「オブジェクト指向」で設計・記述できるようになったことではなく「オブジェクト指向」からの派生でコード記述が文芸的⁵ になり意図や文脈を記述するようになってきたことだと思う。

こうした発展はプログラミング言語のトレンドがオブジェクト指向言語だけではなく関数型言語など複数のパラダイムをブレンドした「マルチパラダイム・プログラミング言語」へシフトしていることからも言えるんじゃないだろうか。また FOSS が主流となりプログラムコードがエンジニア同士の対話手段として使われるようになったことも影響しているかもしれない⁶。

そういう意味で「オブジェクト指向はこうあるべき」という議論は不毛で非生産的な行為と言える。私達はもはやその先に足を踏み入れているのだから。

ブックマーク

参考図書

あなたはコンピュータを理解していますか? 10年後、20年後まで必ず役立つ根っこの部分がきっちりわかる！ (サイエンス･アイ新書): 梅津信幸 (著); ソフトバンククリエイティブ 2007-03-16; 新書; 4797339497 (ASIN), 9784797339499 (EAN), 4797339497 (ISBN); 評価

[Comment] 2002年に技術評論社から出た同名タイトルのリニューアルらしい。

reviewed by Spiegel on 2017-11-24 (powered by PA-APIv5)

数学ガール／乱択アルゴリズム: 結城浩 (著); SBクリエイティブ 2011-02-25 (Release 2014-03-12); Kindle版; B00I8AT1FO (ASIN); 評価

[Comment] 工学ガール，リサちゃん登場！

reviewed by Spiegel on 2015-04-19 (powered by PA-APIv5)

今どきの子は知らないかも知れないので念のために解説すると，「フローチャート」というのはコンピュータの処理の流れ（工程）を図式した一種のモデリング言語と思っていただいて構わない。 ↩︎
いや「動かないコンピュータ」なんてザラにあったけど。むしろ今も見かけるけど（笑） ↩︎
ちなみに「A は B の一種である」という関係を「汎化（または特化）」と言う。 “A is a B” と当て嵌めて考えれば分かりやすいだろう。 ↩︎
むしろ継承にこだわって菱形継承のような弱点や例外処理のような歪な構造を生み出したことは初期のオブジェクト指向プログラミング言語の黒歴史と言えるだろう。 ↩︎
これはいわゆる「文芸的プログラミング」とは意味が異なる。紛らわしくてゴメンペコン。 ↩︎
まさしく著作権による知的独占からの解放がもたらした好例のひとつですな。 ↩︎

きみは Generics がとくいなフレンズなんだね，または「制約は構造を生む」

2017-03-11T05:55:06+00:00

公理によって与えられる暗黙の制約。この制約が集合の要素同士をしっかり結びつける。単純にしばるのではない、相互に秩序ある関係を結ぶ。言い換えれば――公理によって与えられる制約が構造を生み出しているのだ

数学ガール／フェルマーの最終定理より

今回は戯れ言モードなので「プログラミング言語 Go」ではなくこちらで書いてみる。コードは1行も書かないのでご安心を（笑）

私は出自が組込みエンジニアで（今は何でも屋），アセンブラや C/C++ から始まり Java などの制御に向いていると言われる言語を遍歴している（PHP を機器制御に使うとかいうこともやったが）。 Go 言語もその流れから興味を持っているが，あいにく私が住んでいる地方都市で Go 言語の出番はまだない。

そういう経歴を持つ私から見て Go 言語が特異だと思ったのは以下の2点である。

例外処理がない
明示的なクラス定義構文がない

私だけでなく C++ や Java などから来た人は大抵これで面食らうらしい。

このうち1番目については「プログラミング言語 Go」で記事にしたので割愛する。

さて，2番目の「明示的なクラス定義構文がない」について。

そもそも「クラス」とはなにか。クラスとは以下の要素をひとまとめの「モノ（object）」として定義したものである。

名前（必ず1個）
属性（0個以上）
操作（0個以上）

Go 言語では明示的なクラス定義構文がない代わりに type と struct，およびメソッド・レシーバを組み合わせることでクラスの要素である名前，属性，操作を定義できる。

そしてクラス定義で重要なのは「クラス間の関係」を定義することである。クラス間の関係としては大雑把に以下の2つがある。

汎化・特化（継承等）
関連（集約，依存等）

このうち2番目の関連は定義しやすい。あるクラスの属性として別のクラスを定義するか，操作によって関連付けるかすればいいからだ。問題は1番目の汎化・特化をどうやって定義するかである。

Go 言語の場合は interface を使った「構造的部分型（structural subtyping）¹」を採用した。構造的部分型とはクラスの振る舞いに注目してクラス間の汎化・特化関係を帰納法的に定義することである。例を挙げると，それが「にゃーん」と鳴くのなら机器猫だろうが猫耳メイドだろうがサーバルキャットだろうが全部「猫」である，ということだ。

クラス間の関係を定義するのは意外に大変である。皆さんは「クラス設計」をどのように行っているだろうか。まずは具体的なクラスを列挙していき，それらの関係を考察していくのではないだろうか（「ユーザ」や「管理者」を定義するのに動物→人間→… と考えていく人はいないだろう）。考察する過程で（クラスとクラスを繋ぐ）不可視のクラスを発見したり複数のクラスがひとつの概念で括れることに気づいたりすることもある。つまり設計する過程では「具象→抽象」へと遡っていく。

一方，実装する際には， C++ や Java では最初にテンプレート・クラスやインタフェース・クラスを作ってからインプリメント・クラスに落とし込む。

たとえば，最初に「猫」という抽象クラスを作っておいて，それを継承する形で机器猫や猫耳メイドやサーバルキャットといった具体的なクラスを実装していく。つまり「抽象→具象」へと作業していくわけだ。そしてその過程において Generics² は，ほとんど必須と言えるほど利用価値の高い機能と言える。

これが Go 言語による実装ではひっくり返る。たとえば，最初に机器猫や猫耳メイドやサーバルキャットといった具体的なクラスを作っていって「これってみんな『にゃーん』って鳴くじゃん」と気がつけば後付けで「猫」という抽象クラスを実装できるのである。

どういうことかというと， Go 言語においては設計と実装を同時進行で「具象→抽象」へと考察していくことができる，ということである。このような思考過程においては Generics の有無はさして重要ではなくなる。だって具象化されたオブジェクトから作り始めるのだから。

「抽象→具象」へと実装する人にとっては Generics のない Go 言語はとてもまだるこしく見えるかもしれない。「なんで Generics がねーんだよ。いちいち全部書かせる気か。このポンコツ言語が！」となること請け合いである。しかし一度構造的部分型に慣れた人にとっては抽象クラスから書かなければならない C++ や Java こそが面倒くさい。何故なら，脳内では「具象→抽象」で思考していくのに実際に書くときには「考え終わらないと書けない³」からである。 Go 言語なら「考えながら書ける」のに。

これはどちらが正しいかという問題ではない。

たとえばウォータフォール型⁴ の開発スタイルでは実装を開始するまでに設計が終わることが（建前上は）保証されているため「抽象→具象」へと書き進めることが容易な言語が向いている。一方，要件が絶えず変わったり実験的な製品の場合は設計が終わるまで待っていられないため Go 言語のような言語が向いてるかもしれない。まぁ設計と実装を同時にやろうとするとリファクタリングが頻繁に発生するのでコピペ・プログラマにはキツい作業になるかもしれないが。

個人的には「プログラマは要件定義の段階から参加してコードを書くべき」と思ってるので，これを容易にするであろう Go 言語には注目している。

2018-10-11 追記

“Go 2 Draft Designs” において将来バージョンにおける Generics 対応の言及がある。

Go 2 Drafts Announcement - YouTubeより

ブックマーク

Why Everyone Hates Go · npf.io
- [翻訳]なんでGoってみんなに嫌われてるの？ - Qiita
Why Go? | Dave Cheney
- [翻訳] Why Go? - Qiita
Go 言語における「オブジェクト」
JavaScriptで継承を使わないプログラミングスタイル - JavaScript勉強会 : オブジェクト指向設計について上手くまとめている
Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

数学ガール／フェルマーの最終定理: 結城浩 (著); SBクリエイティブ 2008-07-29 (Release 2014-03-12); Kindle版; B00I8AT1CM (ASIN); 評価

[Comment] 「フェルマーの最終定理」というサブタイトルをみたとき「なんちう大風呂敷を広げるねん」と思ったものだが，実際に読んでみるとぐいぐい引き込まれる。ひっさびさに頭を使ったような気がする。

reviewed by Spiegel on 2019-01-13 (powered by PA-APIv5)

URL を見るとわかる通り最初は duck typing と表記していたが正しくは「構造的部分型」と言うらしい。 duck typing は主に動的型付け言語における型推論方式（のひとつ）で，クラス間の関係を記述するものではないようだ。ちなみに構造的部分型に対する言葉として「公称型（nominal subtyping）」というのがあって， C++ や Java におけるテンプレート・クラスやインタフェース・クラスを使った汎化・特化関係を指す場合に使うそうだ。 ↩︎
知らない人のために Generics について簡単に説明しておくと，変数の型あるいはインスタンス（instance）に対するクラス（class）に関係なく単一の記述で変数ないしインスタンスを扱うことのできる仕組みである。汎化の一種と考えてもよい。いわゆる多態性（polymorphism）とは異なり，継承関係の異なるクラスでも一緒くたに扱うことが可能なかなり強力な仕組みである。 Generics は特にコンテナ（container; オブジェクトの集まりを表現するデータ構造，配列など）操作で威力を発揮する。 ↩︎
私はこれを「写経」と呼んでいる。はっきり言ってプログラミングでもっとも苦痛なのがコーディング＝写経だったりする。ちなみに一番好きなのはデバッグ。特に他人の書いたコードをデバッグするのは大好物。あれは極上の数理パズルである（締切さえなければね）。 ↩︎
「ウォータフォール型」とは滝の水が上から下へと落ちていくように要件定義→設計→製造と上流工程から下流工程へ順番にプロセスを進めていく開発スタイル。工程ごとにマイルストーンを設けてチェックを行い，各工程が完了しないと先に進めないようにする。まぁ実際にはスケジュールやらの関係でチェックを端折って先に進めてしまうことが多く，下流工程に入ってから致命的な欠陥に気づいて抜き差しならない状況に陥ることもしばしばある（笑） ↩︎

Go 言語における「オブジェクト」

2015-12-15T12:19:58+00:00

Go 言語がいわゆる「オブジェクト指向言語」と言えるかどうかについては色々とあるようだが，オブジェクト指向プログラミングを助けるための仕掛けはいくつか存在する。今回はその中の type キーワードを中心に解説していく。

なお，今回のソースコードは “A Tour of Go” のものをかなり流用しているため取り扱いに注意。 Go 言語の公式ドキュメントは CC License の by 3.0，ソースコードは BSD license で提供されている。

Go 言語の基本型

今さらだけど， Go 言語の基本型（basic type）は以下の通り。

bool
string
int, int8, int16, int32, int64
uint, uint8, uint16, uint32, uint64
uintptr
byte
rune
float32, float64
complex64, complex128

このうち byte は uint8 の別名で rune¹ は int32 の別名である。また int, uint, uintptr のサイズはプラットフォーム依存になっている。 string は不変（immutable）な値で，その実体は byte 配列である。基本型は組み込み型であり，振る舞いを追加・変更することはできない。

さらにこれらの基本型を集約した構造体 struct を定義できる。

package main

import "fmt"

func main() {
    vertex := struct {
        X int
        Y int
    }{X: 1, Y: 2}
    fmt.Println(vertex)
}

ちなみに構造体のフィールド（field）には構造体を含めることができ，入れ子構造にすることもできる。

この他に配列（slice² を含む）や連想配列（map）あるいは関数値（function value）といったものもあるが，今回は踏み込まない。

型に名前を付ける

全ての型には type キーワードを使った宣言（type declaration）により名前を付けることができる。例えば先ほどのコードは

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func main() {
    vertex := Vertex{X: 1, Y: 2}
    fmt.Println(vertex)
}

と書き直すことができる。

type 宣言が使えるのは構造体だけではない。上述の基本型も type 宣言を使って型を再定義できる。

たとえば，2つの時点間の時間を表す time.Duration は以下のように定義されている。

type Duration int64

また，配列なども型として再定義できる。

type Msgs []string

type 宣言を使って型に名前を付ける利点は3つある。

名前を付けることでコードの可読性を上げる（オブジェクト指向設計では名前がとても重要）
再利用性の向上（特に構造体の場合）
型に関数を関連付けることができる。

type 宣言による名付けは単なる別名定義ではないということだ³。

型に関数を関連付ける

型に関数を関連付けるには以下のように記述する。

func (v Vertex) String() string {
    return fmt.Sprint("X =", v.X, ", Y =", v.Y)
}

(v Vertex) の部分はメソッド・レシーバ（method receiver）と呼ばれ，これが型と関数を関連付ける役割を果たす。内部処理としては

func Vertex.String(v Vertex) string {
    return fmt.Sprint("X =", v.X, ", Y =", v.Y)
}

と等価である⁴。関数の呼び出し側は

package main

import "fmt"

type Vertex struct {
    X int
    Y int
}

func (v Vertex) String() string {
    return fmt.Sprint("X = ", v.X, ", Y = ", v.Y)
}

func main() {
    vertex := Vertex{X: 1, Y: 2}
    fmt.Println(vertex.String())
}

のようにインスタンスと関数をピリオドで連結して記述する⁵。

構造体そのものには関数を付与できない⁶。たとえば

package main

import "fmt"

func (v struct{ X, Y int }) String() string {
    return fmt.Sprint("X =", v.X, ", Y =", v.Y)
}

func main() {
    var vertex = struct {
        X int
        Y int
    }{X: 1, Y: 2}
    fmt.Println(vertex.String())
}

などと書いても，コンパイル時に

invalid receiver type struct { X int; Y int } (struct { X int; Y int } is an unnamed type)

と怒られる。 type 宣言によって型に名前が付けられていることが重要なのだ。

Go 言語には class キーワードはないが， type 宣言を使うことで，名前と属性と操作を持つクラスを記述することができる⁷。

汎化・特化と処理の委譲

オブジェクト指向設計においてクラス間の関係は大きく2つある。

汎化・特化⁸（継承または is-a 関係）
関連⁹（包含または has-a 関係）

このうち関連についてはこれまで説明した方法で実現できるが，汎化・特化は表現できない。そこで以下の機能を使って汎化・特化を実現する。

振る舞いのみを定義した型

interface を使うと振る舞いのみを定義した汎化クラスを表現することができる。

interface で定義された型で最もよく目にするのは error だろう。 error は以下のように定義できる¹⁰。

type error interface {
    Error() string
}

定義が示すように error は「string 型を返す Error() 関数」のみが定義されている。逆に言うと「string 型を返す Error() 関数」を持つ全ての型は error の一種（つまり is-a 関係）であると見なすことができる¹¹。

たとえば

package os

// PathError records an error and the operation and file path that caused it.
type PathError struct {
    Op   string
    Path string
    Err  error
}

func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }

と定義される os.PathError は error の一種である。

interface も type 宣言で名前を付けることができ，他の型と同じように扱うことができる。さらに interface で定義した型は振る舞いのみで具体的な実装を含まないため，多態性を持たせた記述が可能になる¹²。

将来バージョンで総称型（generics）がサポートされるかも。

現行版の Go 言語ではいわゆる「総称型」はサポートされていないが，将来バージョンで導入される可能性がある。

次期 Go 言語で導入される（かもしれない）総称型について予習する

型の埋め込み

もうひとつの汎化・特化の機能が型の埋め込み（embedding）である。構造体や interface には別の型を埋め込むことができる。

たとえば io.ReadWriter は以下のように Reader および Writer を埋め込んでいる。（このときの Reader および Writer を「埋め込みインタフェース（embedding interface）」と呼ぶ）

package io

// Implementations must not retain p.
type Reader interface {
    Read(p []byte) (n int, err error)
}

// Implementations must not retain p.
type Writer interface {
    Write(p []byte) (n int, err error)
}

// ReadWriter is the interface that groups the basic Read and Write methods.
type ReadWriter interface {
    Reader
    Writer
}

これによって ReadWriter は Read() および Write() を自身の振る舞いのように扱うことができる。この場合も ReadWriter は Reader および Writer の一種であると見なすことができる。

同様に bufio.ReadWriter についても

package bufio

// ReadWriter stores pointers to a Reader and a Writer.
// It implements io.ReadWriter.
type ReadWriter struct {
    *Reader
    *Writer
}

// NewReadWriter allocates a new ReadWriter that dispatches to r and w.
func NewReadWriter(r *Reader, w *Writer) *ReadWriter {
    return &ReadWriter{r, w}
}

と実装されていて， bufio の Reader および Writer を埋め込み，これらの型の一種として実装されている。このときの Reader および Writer を「埋め込みフィールド（embedded field）」または「匿名フィールド（anonymous field）」と呼ぶ。 bufio.ReadWriter は io.ReadWriter の一種として機能している点にも注目してほしい。

関数のオーバーライドと処理の委譲

では，今まで述べたことを使って以下のコードを書いてみる。

package main

import "fmt"

type ErrorInfo interface {
    error
    Errno() int
}

type ErrorInfo1 struct{}

func (err *ErrorInfo1) Error() string {
    return fmt.Sprint("Error Information: ", err.Errno())
}

func (err *ErrorInfo1) Errno() int {
    return 1
}

func Action() error {
    err := &ErrorInfo1{}
    return err
}

func main() {
    if err := Action(); err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println("Normal End")
}

error の拡張として ErrorInfo interface を定義する。 ErrorInfo interface では error を埋め込み，さらに Errno() 関数を追加定義している。更に ErrorInfo interface に適合するクラスとして ErrorInfo1 型を作った。このコードの実行すると “Error Information: 1” が出力される。

ErrorInfo interface

次に ErrorInfo1 のバリエーションとして ErrorInfo2 を追加してみよう。

package main

import "fmt"

type ErrorInfo interface {
    error
    Errno() int
}

type ErrorInfo1 struct{}

func (err *ErrorInfo1) Error() string {
    return fmt.Sprint("Error Information: ", err.Errno())
}

func (err *ErrorInfo1) Errno() int {
    return 1
}

type ErrorInfo2 struct {
    ErrorInfo1
}

func (err *ErrorInfo2) Errno() int {
    return 2
}

func Action() error {
    err := &ErrorInfo2{}
    return err
}

func main() {
    if err := Action(); err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println("Normal End")
}

ErrorInfo2 では Error() 関数は ErrorInfo1 のものをそのまま使い回したいが Errno() 関数では異なる値を出力したい，と考えた。そこで Errno() 関数をオーバライドしようと考えた。図で書くと以下のような構成を期待したわけだ。

Override ?

しかし実際には，期待した “Error Information: 2” ではなく，前回と同じ “Error Information: 1” が出力される。

上のコードでは ErrorInfo2 と直接関連付けられた Error() がないため ErrorInfo1 の Error() が呼ばれるが，その関数の中で呼ばれる Errno() は ErrorInfo2 と関連付けられた関数ではなく ErrorInfo1 と関連付けられた関数になる。

delegation

これは Go 言語では埋め込みフィールドの関数呼び出しが「委譲」として機能しているためである。たとえば C++ 言語では virtual 修飾子を付与して仮想関数化することで意図的にオーバーライドできるが¹³， Go 言語ではこのような仕掛けがないため¹⁴，呼ばれた関数は常に委譲として機能する¹⁵。

上の例はクラス構成からして明らかにダメダメなのだが，今回のポイントはサブクラスである ErrorInfo2 から Errno() 関数を上書きすることでスーパークラス ErrorInfo1 の Error() 関数の処理を書き換えようとした点にある。継承¹⁶ の実装で一番よくあるミスがこの「カプセル化の破れ」で， Go 言語の場合は敢えて移譲を強制することでこの手の不具合が発生するのを回避しようとしているように見える。

他の言語では明示的に委譲を実装しようとすると冗長な記述になることが多いが， Go 言語の場合は埋め込みを使うことでシンプルな記述で委譲を実装できる点がメリットと言える。

ブックマーク

Big Sky :: Go言語でインタフェースの変更がそれ程問題にならない理由
オブジェクト指向言語としてGolangをやろうとするとハマること - Qiita
- オブジェクト指向言語としてGolangをやろうとするとハマる点を整理してみる - Qiita
Go言語に継承は無いんですか【golang】 - DRYな備忘録
Go言語でジェネリクスっぽいことがしたいでござる【generics】【golang】 - DRYな備忘録
Go 言語の値レシーバとポインタレシーバ | Step by Step
埋込みとインタフェース #golang - Qiita
Goにatexitやグローバルなデストラクタがない理由 - Qiita
Python と Ruby と typing - methaneのブログ : interface を使った汎化・特化の関係は duck typing ではなく「構造的部分型（structural subtyping）」と言うのが正しいらしい

Go 言語に関するブックマーク集はこちら。

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

rune は Unicode 文字の符号点（code point）を示す型で文字そのものを表現する。 string と rune の関係については「String と Rune」を参照のこと。 ↩︎
配列と slice の関係については「配列と Slice」で紹介している。 ↩︎
型の別名定義はバージョン 1.9 から導入された。詳しくは「Go 1.9 と Type Alias」を参照のこと ↩︎
Go 言語の関数呼び出しにおいて引数の渡し方は基本的に「値渡し」である。詳しくは「関数とポインタ」を参照のこと。 ↩︎
ちなみに fmt.Print などでは引数の型が String() を持っていることを期待し，この関数の出力結果をデフォルト書式にしている。したがって fmt.Println(vertex) と書いても同じ結果になる。 ↩︎
他にも基本型や他パッケージで定義されている型に関数を追加することはできない。当たり前だけど。 ↩︎
クラスは名前と属性と操作の3つの要素で構成されている。名前は他クラスと識別できるものを1個。属性と操作は0個以上存在する。 Go 言語では空のフィールドの struct を定義することにより0個の属性を持つクラスを構成できる。 ↩︎
言わずもがなだが，サブクラスから見たスーパークラスが「汎化」でその逆が「特化」である。 ↩︎
関連は更に集約と複合に分類できるが今回は踏み込まない。 ↩︎
error は組み込み型なので，実際にこのような定義が標準パッケージにあるわけではない。 error について詳しくは「エラー・ハンドリングについて」を参照のこと。 ↩︎
Go 言語では Java の implement のような interface クラスからの継承を明示するキーワードはない。記述された振る舞いからクラス関係を決定する方法を「構造的部分型（structural subtyping）」と呼ぶ。構造的部分型のメリットのひとつは多重継承で発生する様々な問題（名前の衝突や菱形継承など）を気にする必要がない点である。 ↩︎
たとえば interface{} と記述すればあらゆる型を含むことになる。これを利用して fmt.Print は func Print(a ...interface{}) (n int, err error) { ... } と定義されている。 ↩︎
逆に Java では関数は常に仮想関数として機能しオーバーライドされる可能性がある。これを抑止するためには final 修飾子を付加する。 ↩︎
Go 言語的には埋め込みフィールドはフィールドのバリエーションのひとつにすぎないため，動作も通常のフィールドが持つ関数を呼び出した場合と変わらない。そういう意味では構造体への埋め込みは，見かけ上は「is-a 関係」でも，実質的には「has-a 関係」に近いと言えるかもしれない。 ↩︎
複数の型を埋め込んでいる場合，埋め込みフィールド間で名前が衝突しているフィールドや関数を使おうとするとコンパイルエラーになる。この場合は err.ErrorInfo1.Error() のように型を明示して回避できる。 ↩︎
ここで言う継承は設計時の「汎化・特化」のことではなく，言語機能などを使った実装上の継承のこと。 ↩︎