「コンストラクタ」を含む日記 RSS

はてなキーワード: コンストラクタとは

2020-12-20

プライベートメソッドテストすべきか

「すべきでない」というのがたぶん多数派

テストすべきでない理由としてだいたい次の理由があげられる。

プライベートメソッド関数テストする必要は無いと考えていますプライベートメソッドは、実装の詳細であるからです。

多くの場合、そのクラスパブリックメソッド経由でプライベートメソッドテストも同時に行えます

プライベートメソッドのテストは書かないもの? - t-wadaのブログ

ほとんどの場合プライベート メソッドテストする必要はありません。 プライベート メソッド実装の詳細です。

プライベート メソッドがある場合は、パブリック メソッドを見つけて、そのメソッドに対してテスト記述します。

単体テストを記述するためのベスト プラクティス - .NET | Microsoft Docs

プライベートメソッドテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。

例えばtwitterで、パブリックメソッドにだけテストを書き、テスト必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドテストに強く反対している。

またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつテストひとつオブジェクトで表し、それによってテスト独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身ひとつオブジェクトとして独立しているなら、テスト対象となるオブジェクトプライベートメソッドテストできないのは当然のことになる。

しかし「プライベートメソッドテストがしたい(したくなることがある)」と感じる人も相当数いる。

そう感じる人にとってはむしろここからが本題で、

問題になる。

テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。

例えそのクラスがprivateメソッド依存関係があっても。

コンストラクタインジェクションされたクラスのprivate メソッドでもテストファーストしたい - Qiita

privateなルーチンの自動テストは面倒だ。実際にコーディングするとき最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。

私は元々メソッドはprivateにしない主義なのでメソッド場合問題ないのだけれど、ファイル内の「関数」が問題になる。和了計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)

private メソッドテストすべきか問題原則論だけだと袋小路に入りがちだから、private メソッドテストしたくなる具体的な場面について議論したほうがいいと思う。

自分レビューでよく見る例としては、複数の public メソッドの重複部分を private メソッド抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)

きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートバックドア開けてでもテスト書くようにしてます (twitter/mizchi)

しかプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッド可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。

伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。

自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラム挙動を変えること"の方が、「privateなメソッドテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)


メソッドプライベートパブリックかという話とそれをテストするかどうかは別問題だろという意見もある。

単体テストホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)

private メソッドテストするかどうか? まず最初に言っておきたいのは public/private は抽象設計問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)

特定言語の貧弱な機能思考制限を受けて誤った結論を出している典型的な例。

"テストを書くべき"と"上位層から可視性"は直交する概念

https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1

テスト粒度メソッドアクセス権は独立したものなので、「プライベートメソッドテストすべきか否か」という切り方自体ナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)

private メソッドテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能テストインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)


プライベートメソッドテストがしやす言語での意見

RustやGoではプライベートメソッドに対するテスト簡単にできる。

そのためかプライベートメソッドテストすることに対して拒否反応があまりないようだ。

Rustのテストファイル内とtests/以下の2箇所に書ける。

テストには開発用のホワイトボックステスト仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。

例えば度々議論になるプライベート関数テストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)

Rustではプライベートに対して何の手間もなくテストが書ける。

概念的にはプライベートに対するテストは外部コードではなく内部コードの一部として見るべきなのだろう。

Rust入門を兼ねてプロジェクト・オイラーの問題を解く - 再帰の反復blog

Rustでprivateなメソッドテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)

Rustみたいに単体テストは同ファイルに書ければいいのに

assertionチックにprivateメソッドのすぐ下にテスト書きたい

ドキュメントにもなるし (twitter/takaya_tim)

Rust のようにユニットテストプロダクションに混ぜる方式はおれもいいと思ってて、テストプロダクションを分離することで private 関数テストができない問題があるけど(テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね)、そもそもこの議論不要になるよね (twitter/nunulk)


go言語だとプライベートメソッドテスト普通にやりますね。(twitter/mattn_jp)

昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)

golangのテスト書いてたけど、テストプログラム名前空間(パッケージ)が、対象プログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)

Goテストコードテスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)

プライベートメソッドテストするか?」とは別にドキュメントソースコードと同じファイルに書いていい(文芸プログラミング)なら、単体テストテスト対象と同じファイルに書いてもいいのでは?」というのも論点になるかもしれない。

2020-11-06

コード共通化するな

プログラミングできる気になった自称中級者は、ソースコード共通パターンが現れると決まって、その処理を関数などに共通化したがる。

しかに、そうすることでソースコードは短くなるし、一見して保守性が上がったような気になるのだが、それは間違った作法から止めろ。

かいこと言っても伝わらない自称プログラマが読んでることを想定して、先に結論簡単に書いておく。

お前は絶対コード共通化するな。

共通化してはいけない理由

なぜコード共通化するのがいけないのか。理由簡単だ。要するに、コードが似ているのは単なる偶然であって、それらは別の処理だからだ。

別の処理だから共通化するのはおかしいし、もし共通化した処理の一方のみ仕様が変わった場合、その修正は他方にも影響してしまう。つまり保守性が下がっている。

たとえば、同じプロジェクトの中に、10%の消費税を加える処理と、10%の金利を加える処理があったとする。この2つの処理はともに元の金額を1.1倍する処理であり、全く同じ処理であるが、共通化してはいけない。

これらを共通化してしまうと、たとえば金利が8%に変更になったとき金利計算の処理だけではなく、消費税計算している箇所すべてを変更しなければならなくなる。

実際のアプリケーションでやりがちなのは複数の処理の「事前処理」「事後処理」などを1つの関数にして、呼び出し毎に細かい挙動引数制御するようなパターンだ。

これは結局、改修を重ねる度に「事前処理」「事後処理」の内容が使用箇所によって全く異なるものとなり、それに対応するために

といった悲惨設計に陥る。

他にも、GUIアプリユーザーの応答を待つDialogクラスなんてものを作って、使用箇所ごとにメッセージボタンに割り当てる処理などを切り替えることがある。

これも間違いなく、プログラムが成長するにつれて破綻する。たとえば、ある場所ダイアログは、表示するメッセージテキスト形式のみではなくなり、脇に画像を表示するかどうかのフラグコンストラクタに渡したり、Dialog継承させて表組みを表示するTableDialogサブクラスを作ったりすることになる。ボタンが「OK」と「キャンセル」の2種類の場合じゃなくなって、表示するボタンの数をコンストラクタに渡したり、ボタンに割り当てる処理をリスト形式で渡したりし出す。

こうして、最初は良い設計に見えたDialogクラスはどんどん複雑になる。こうなった原因は明らかで、本来は異なるもの共通化したからだ。おかしな色気を出さずに、素直に別々に実装しておけばよかったのである

処理に名前をつけろ

プログラミングをする上で「コード共通化する」なんてことは意識しなくていい。それよりもプログラマがすべきことは、処理に適切な名前をつけることだ。そのプログラムにおいて「単なる変数操作」を超えた意味のある処理には名前をつけろ。そして、同じ意味の処理なら同じ関数を使うし、違う処理なら違う関数を使う。それだけだ。コード共通化できるかどうかなんて全く関係ない。

変数関数クラス名前空間等が再利用のための機構だという先入観は一旦捨てろ。それらの真の意義は、「関心の分離」にある。つまり実装隠蔽し、その意図抽象するために存在する。たまに勘違いしてる奴がいるが、別に1回しか使われない関数とか、1行しかない関数はあってもいい。というか、この原則にしたがって設計すると、ほとんどの関数(or メソッド)は数行になる。

上の消費税の例で言えば、「消費税を加える」「金利を加える」処理は、明らかに単なる算術演算以上の意味のある操作から関数化する。そして、それぞれの実装は当初の仕様では奇しくも全く同じになる。消費税を加える箇所では前者の関数を呼ぶし、金利を加える箇所では後者関数を呼ぶ。

これはこう言い換えることもできる。消費税を加える関数を変更するのは、消費税計算処理が変わったときのみであり、金利を加える関数を変更するのは、金利計算処理が変わったときのみである。つまり、すべての関数は、それを変更する理由がただ1つになるように設計しろということだ。

こういうアプローチプログラムを書くと、ソースコードはあたかもそのアプリケーションドメイン特化言語で書かれたかのような見た目になる。

また、一つ一つの関数は小さく、理解やすく、テストデバッグも容易になる。そして、結果として再利用もしやすくなるし、プログラムの変更も容易になる。

2020-09-27

anond:20200927035510

言語によると思う

javaなら普通にオブジェクトEnum継承したインスタンスになるからその分メモリ使うし、enum内部で結局String持ってる(コンパイラStringEnumの子クラスコンストラクタに渡す)からStringの方がリソース無駄にならない

インスタンス単一にする意味はあるから結局enumの方が好ましいだろうけど)

Cとかは実質intだからStringにするのは無駄だろうな

2020-07-26

anond:20200726082730

関数コールときクラス指定するとコピーコンストラクタが呼ばれるからコピーが遅いと関数がおそくなるよ(智材なんてぱくってもひとはしなないといわれたからやった)

2020-05-22

どちらの副作用のほうが大きいか

意図しないstd::moveがない=だけのmoveコンストラクタが呼ばれる場合

コピーコンストラクトと使い方に差がある

という弊害constなのにmoveコンストなのに所有権を失うというコンストとは違う動作が行われる)である という もとからconst には前コンスト 後コンストの問題はあるが 同じような弊害を生むのではないか

難しいけど ごめんなさい。

2020-05-21

いや、C++コンストラクタ別にクラスを作らなくても、すでに存在するクラス変数に対してコンストラクタを呼び出しゃいいだろ あれは 特に何もしなくてもクラスを作れば呼び出されるが、呼びたきゃ呼べよもう1回

 

a = new A();

なaのA()を

for文でメモリを新たにハントしないで100回呼べよ いみわかるから

newをしたらコンストラクタ1回 自動で読んでくれるけど 別に 呼べよ 呼びたきゃ なにいってんだ

 

カツ丼食べたいんですけど、警察逮捕されなきゃ駄目ですか?とか

デリヘルってどうやってよんだらいいですか?って聞かれても困るぞ(まずは、ホットペッパービューティー でググれ )

2020-04-09

ねぇXちゃんさぁ。なんでこんな動的なオブジェクトをstaticにしてんの?

これさぁ、そこそこ重いけどさ、セッションごとに生成される一時的インスタンスで持ってるだけでも十分パフォーマンス的に問題ないよね?

なんでプロセス間でわざわざ共有してんの?

これってネットワーク接続管理してるオブジェクトだよね?

ネットワークリソースつったって利用者たかだか数百人でしょ?

その中でリソースを同時利用するってゆってもたかだか十数人でしょ?

プロセス内でこのオブジェクトを全共有することでリソースの削減なんてたかが知れてるよね?

それをわざわざプロセス内でこのオブジェクトを全共有ってマジ管理できるの?シンクロナイズドとか書いてっけどさぁ?削減できるリソースの量に比べて超危険すぎねぇ?

コミットログ見たけど、ぜんぜん性能問題とかと関係のない問題修正だったみたいだけど、なんでこんな危険コードになったわけ?

Xちゃんさ、そもそもコードが品雑なんだけど、これエンプラJava案件なのよ

なんでCの組み込みコードみたいにif文の鬼ネストとか、引数に空のList渡して破壊的に値を設定するような、読みづらいコード書いてるわけ?

Listくらい普通に返り値で返しなさいよ…

状態管理もif文の鬼ネストやめて専用クラスとかEnum使ってコマンドパターン対処しなさいよ

もしかして、Xちゃんオブジェクト指向にピンときていないのかな?

ちゃんはどっちかってーっとPHPパーなので、ゴリゴリオブジェクト指向はそりゃ専門じゃないよ

それでもさ、interfaceとか使って、各処理の実装を切り分けるとか、やりようはいくらでもあるじゃん

あと不要なnullチェックも多すぎです。コンストラクタ初期化保証されているfinalフィールド値がnullかどうかなんて確認しないでください

ユーザー入力DB入力環境リソースとか、外部の情報起源じゃない変数がnullとか、明らかなバグなんだから暗黙的なぬるぽクラッシュさせましょう

こんなバグが出荷に乗ることなんてありえません。わざわざ専用のエラー処理で専用の例外飛ばすとか無意味です。

いちいちなんか冗長で複雑なんですよねぇ。

ちゃんみたいな若造が、ベテランのXちゃんにこんなこといいたくないけどさ、

Xちゃんコード。どこか昭和匂いがするんだよねぇ。悪い意味で。

Xちゃん名誉のために言っておくと多分Cプログラミングうまいんじゃないかな?

そんなソース読んだこと無いから知らんけど

2019-10-22

Blawn

中学生プログラミング言語を作ったというのは素晴らしいと思うが、その言葉が一人歩きしてるようにも思える

字句解析やら構文解析やらのライブラリもあるから、いまやオレオレ文言語の開発自体の敷居はそこまで高くない

Blawnもふつうに有名どころのライブラリ使ってるしな

あとサンプル見ても可読性が高いようには思えない

なんでインデントブロックなの?

コンストラクタオーバーロードどうするの?

クラス内メンバの宣言でいちいち@つけなきゃいけないの?

なぜmain()ないの?

などなど…

この程度だったらおれなんて中学生の頃は毎日さくらたんのエロ同人でシコっていたぞ!

2019-01-01

anond:20190101161818

解説を入れておくと

グローバル関数リスト

自分自身コンストラクタ登録

デストラクタで削除する簡単システムを作る

商業だとこんな雑ではダメだけど

テストならこれでOK

std::list< MyWindow *> windows;

class MyWindow
{
public:

	HWND hWnd;



	MyWindow()
		:hWnd(NULL)
	{
		windows.push_back(this);
	}

	virtual ~MyWindow()
	{
		std::list< MyWindow *>::iterator it;
		for (it = windows.begin(); it != windows.end(); it++)
		{
			if (*it == this)
			{
				windows.erase(it);
				break;
			}
		}
	}

2018-11-21

djangoって何を目指してるの

htmlの中で

{{form}}とかやると受け取ったformを展開できて非常に便利なのだ

例えばbootstrapなどを使いたいときclass指定とかするのに困る時がある。特にテキストフィールドなど。

これに対しform.pyなどで定義した自作form内のコンストラクタclass=form-controlを付与することで対応できるそうだ。

でもそれだと何のために見た目と中身を分けているの?html内の記述対応できないと一貫性がなくない?

現にdjango-bootstrap-toolkitみたいなのがあってbootstrap4で使えるかはわからないけど

{{form | class-format}}みたいな記述ができるみたいだ。こういう方向性を目指すべきだと思うのに、何故フォーム作成コンストラクタ対応しようとするのか。

2018-09-14

「開発現場で役立たせるための設計原則パターン」への反論

開発現場で役立たせるための設計原則パターン

https://nekogata.hatenablog.com/entry/2018/09/10/163206

この記事はてブで大絶賛されてるが、個人的にはセンス無いなーと感じたので言語化してみる。

Notificationクラスが不親切。

Notificationクラスそもそも単一責任原則に反してない

開放閉鎖原則勘違いしてる

Notificationクラスと何のクラスが密結合なのか説明されてない

  • 『それ以前の問題というか「本来バラバラに書かれるべきものが、すべてここに書かれてて密結合しちゃってる」とみることができるかと思います。』?
  • 密結合というのであれば、コメント通知を変更した時にNotificationクラスとCommentクラスの両方に変更が生じてしまうことを示すべき

オブザーバーパターンが出てくる意味が分からない

今回の仕様を図で書くと

コメント→→→コメント通知

スター→→→スター通知

あしあと→→→あしあと通知

みたいな感じになるとする。

すると、今回スライド問題視しているのは矢印の右側の通知の部分が1クラス共通化されている点。

しかし、オブザーバーパターンの出番は図の矢印の部分が絡まり合って処理が複雑になってしまった場合

今回は1つのイベントから複数リアクションが発生することは想定しないので

オブザーバー不要なのは当然。選択肢に出てくるほうがおかしい。

そもそも問題認識(通知部分が問題)と解決策(矢印部分を解決)がズレてるから話がおかしな方向にいってる。

Notificationクラスサブクラスを作ろう、ならまだ分かる。

人間の可読性が考慮されてない

まとめ。

かに設計言語化するのは大事だが、言語化というのは「それっぽいことは幾らでも言える」危険性がある。そもそもプログラミングというのは芸術であり文学なんだからセンス無いのに言語化を頑張っても「一見それっぽく聞こえるけど間違ってる説明しか出てこない。

2017-07-02

日本人はなぜ入門者に厳しいのか?

週末の書店

プログラミングコーナーに行くと、いつもうんざりした気分になる。

何故ってこんなに入門書が溢れかえっているのに、何一つとして入門者向けの本が無いからだ。

日本書籍小売の総本山神保町三省堂書店の棚の端から端まで見た所で、ビギナー向けの本などありはしない。

なぜなら、入門書を謳っている本のコードほとんどが動かないコードからだ。

入門書だと言うのに、ページを割くべきところに文章イラストを割かない本が多すぎる。

例えばポインタコンストラクタインスタンスカプセル化…それぞれの概念

イラスト入門書だってそうだ。「入門」と書いてあるからといって、開いてみればデッサンや形のとり方を教える本などありはしない。

そう、日本入門書とは「元々デキる人がリメディアルとして持っておく本」のことであり、「ビギナー向けのウェルカム本」ではないのである

からといって、誰もがpython専門家になる胎教を受けて産まれるわけではないし、誰もが10代で写真と見まごうスケッチを描けるわけではない。

基本的には「デキる人」に着いて指導してもらうのである

では、その「デキる人」は誰に教わったのか?やはりデキる人たちや、海外入門書を車座になって読んで学習したのである

しかし、その「始祖・デキる人」がヒーロー時代とは、今とは複雑度合いも、求められるものも違う。

今は学生であっても、ある程度の高度な成果(ここでは、ネットで発表したものネットニュースでバズった経験や、学会評価された経験のこと)があって始めて企業受験票でしかない。

なぜ入門者向けの本がないのか?

それは(少なくとも)日本人初心者嫌いの民族からである

習うより慣れろ。仕事は見て盗め。教えられるのを待っているな。・・・

自分より出来ないやつに教えるのが大嫌いなのだ。(入門書の著者ですらそうなのだ!)

上にあるように、ある程度デキる人でないと、その手の会社には認められない。

からといって、大学教育で手ほどきを受けられるわけではない。これもある程度デキる人向けなのだ

では、書籍自助努力を、となっても、文頭にあるように、入門書向けの本など無く。

デキる人に一子相伝の手ほどきを受ける必要があるのだ。

では、デキる人はどこにいる?これもやはり雲の上の大学しかいない・・・

今はネットがある?これも難しい。

知恵袋や、teratailであっても、初心者に与えられる答えは「ググレカス」のみ。

では、ネットジャストな回答があるか?といえば・・・ない。基本的には公式リファレンスコピーや、動かないコードしかない。

デキる人は、デキない人の気持がわからない。何がわからないのかわからない。

からあいつらがわからないのは、あいつらが勉強不足だから、と考える。

からないのは、あいつらの自己責任だ。だから初心者は嫌なんだ。となる。

適性を測っている、という見方もある。

しかし、適性というもの基本的にやらなければわからないもので、やる前の教育から放棄しているのは適性を測るというより、

単純に教育放棄しているだけにほかならない。

日本人初心者軽視、というか教育軽視は今に始まったことではない。

「失敗の本質」でもそれは指摘されている。ということは戦時から既に教育嫌いなのだ

職場でもそう。教えられるのを待っているな、と言っておいて、いざ聞きに行けば「常識でわかるだろ」「ネットで調べて」「リファレンスマニュアル調べて」

学校でもそうだ。

授業の勉強も予習が前提。では授業ではより高度な話をするのか?しない。教師我流の演習である

演習するだけならば、家や図書館黒本赤本を解いていたほうがマシじゃないか

学校教育ですらこうだ。

日本人はとにかく初心者が憎い。潰したくて仕方がないのだ。

2014-09-05

1人教祖

僕たちはいだって宗教戦争だ。

エディタで。vimキーバインドで。teraterm背景色で。ログファイル名称で。変数名で、タブの桁数で。spfileの設定で。jbossの設定のおまじないで。stratsの継承方法で。エラークラス名で。プロパティ名で。セッターゲッターを付けるかつけないかで。コンストラクタで。newを上書きするかしないかで。jreのeditionで。eclipseの見た目で。javadocのエディションで。クラウンドキュメントIDで。githubにいくつ持っているかで。tryのインデントで。タブを表示するかしないかで。エディット中の飲み物で。待ち合わせはスタバなのかエクセルシオールなのかで。セブンイレブンコーヒーサイズで。そのコンビニコーヒーが一番うまいかで。IDカードは伸びるストラップがいいのか悪いのか。寝るときは机の下か椅子を並べるのか。デスクの上にフィギュアは置いていいのか悪いのか。めんまつるこか。

いつだって宗教戦争の糸口が僕たちを待ち構えている。とても恐ろしいことだ。

2014-07-11

PSCmdlet を継承したクラスコンストラクタで MyInvocationに触れるとオチ

http://anond.hatelabo.jp/20140711202103

今のところ、それしか考えられない...

コンストラクタを抜けた後のどこか(しか自分コードの中ではない)、NullReferenceException。

基底クラスの中?

MyInvocationプロパティgetアクセッサ関数内あたりで、初期化必要な何かをやっているのだろうか?

2014-04-09

オブジェクト指向 v.s. 関数型プログラミング

近年、関数型プログラミング重要はいろんなところで叫ばれています

Javaの最新バージョン関数型プログラミングに関する新機能が加わりました。

Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています

プログラミング教科書大手オライリーからJavascript関数型プログラミングを行うための解説書が発行されました。

関数型プログラミングへの注目度は高まってきています

おそらく、みなさんは既にオブジェクト指向が何か、を知っています

でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います

実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、

関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。

この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。

この記事はあまりかいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。

みなさんは鳥のように飛んで、高い空から関数型プログラミングとは何か、何が良いのか、を見渡してください。

ふたつのアプローチ比較

オブジェクト指向アプローチは、名前をつけてプログラムを整理する

関数型プログラミングアプローチは、汎用部品でなんとかする

オブジェクト指向アプローチ

Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。

また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体C言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。

継承クラスは、オブジェクト指向必須条件ではありません。

オブジェクト指向本質とは、何でしょうか。

その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります

最もプリミティブなオブジェクト指向対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。

これらの処理をまとめたら、わかりやすいですよね?

対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。

識別することとイコール比較できることは、とても良く似ています

イコールによる比較は、オブジェクト指向では鬼門であることが知られています

PointクラスインスタンスとColoredPointクラスイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。

また名前をつけて識別する対象は、フワフワしていてはいけません。

たとえば、"軍人階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士名前フィールドや、性別フィールドを持っているでしょう。

ところで彼が昇格したときに何が起こるでしょうか。

新たに"少将"クラスインスタンスが作られます。"大佐"クラスを破棄する前に、名前性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コード修正を加える必要があります(*)。

なるべくイコール比較を避けたい。対象不安定なものはいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。

関数型プログラミングアプローチ

一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとしま

さな関数を、集めて撚り合わせて、新しい関数を作る。

関数自体リストなどのデータ構造に詰めることもよく行われます

実は、関数型プログラミングというのは本質を表していません。

その真の名は、"値指向プログラミング"です。

関数をはじめとして、リスト・ツリーのようなコンテナ手続きを抽象化したもの、回路を抽象化したもの

あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります

変数という概念必要ありません。

変数適用する処理を作りあげることが、とても簡単だからです。

四則演算定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。

値をイコール比較することも、なんのそのです。

誤解を恐れずに言うと、オブジェクト指向トップダウンなのに対し、関数型プログラミングボトムアップです。

関数型プログラミングの利点

読みやすい・理解やす

関数型プログラミングサポートする言語には、沢山の汎用部品定義されています

このような構造インターフェイスとして、様々なライブラリが組まれているので、

たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、

パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。

理解やすいこと。これが関数型プログラミングの大きな利点です。

追記:

また、汎用部品と型のお陰で、ライブラリドキュメントが圧倒的にひきやすい、というメリットも有ります

Haskellな人がPythonにトライした結果 - Togetterまとめ

書きやす

関数型プログラミングは「厳密な事前設計必要とするため、簡単なことをやるのにも時間が掛かる」。

よく誤解されていますが、これはウソです。

スクラッチプログラムするのは、非常に手軽です。

>> map (*2) [1,2,3]
[2,4,6]

邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。

関数型プログラミングコードは、潔癖かつ濃密です。

たとえばC言語でint hoge(int x,int y)が定義されているときhoge(3)はなんの意味も持ちませんが(コンパイルコケますが)、関数型プログラミングでは意味があり、実際に有用です。

上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります

関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。

多くのバグは、コンパイルエラーとして検出されます

また、静的型付けの力によって、コード補完は非常に強力になっていますインテリセンスの比ではないです。

たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。

やがてやってくる未来には、プログラムテキストエディタで書くことは時代遅れになっているでしょう。

統合環境サポートで、バグミスの少ない、スムーズプログラミングができます

そしてその環境で動くプログラミング言語は、関数型プログラミングサポートした言語なのです。

いつ関数型プログラミング

以下の様な兆候を感じたら、あなたはそのプログラム関数型プログラミングで書くべきです。

一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます

そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチ有効です。

それこそが関数型プログラミングアプローチです。

オブジェクト指向の利点

初心者にとっては読みやすい・理解やす

特にオブジェクト指向有効なのはプログラミング初心者がそのコードをいじるかもしれないときです。

関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います

そのため、初学者にとってはハードルが高いのです。

扱う対象があまり複雑でない時は、書きやす

オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき

そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。

関数型プログラミングの得意分野はなにか

数値計算

遅延評価という機能によって、レガシー言語で扱えなかった、巨大な数を扱うことができます

分数を扱うことができます虚数もです。

関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています

テキスト処理

手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解やすく、メンテナンスやすものになります

関数型プログラミングを知らない人は、「正規表現おk」と言いますが、

彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。

並行処理

手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。

関数型プログラミングサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。

さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります

Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。

C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。

レシピ

もう少し簡単な例をあげます

あなたは、あるレシピにしたがって、自動的料理を行うマシン制御プログラムを書いているとしましょう。

料理レシピは、"手続き"ですよね?たとえば、カレー

1. まず玉ねぎを炒める。

2. 飴色になったら、肉を加えて炒める。

3. 野菜を加える。

4. 水を加えて煮る。

5. スパイスを加える。

しかあなたはこの手続きを関数として表現できるでしょうか。

…できませんよね?何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要からです。

これをオブジェクト指向でやろうとすると、各ステップ副作用として、それらの処理を行うことになります

そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります

あるいは関数として表現するのを諦め、手順全体をDSL記述できるようにします。

このアプローチ関数型プログラミング的です。しか関数型プログラミングサポートした言語の助けなしでは、そのDSL記述するために沢山のユーティリティコードを書かなくてはならないでしょう。

オブジェクト指向アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります

野菜クラスフライパンクラス、ボイルクラスフライクラス、焼き加減クラス、アームクラス野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラスetc...

こうすると早晩レシピプログラムコードから消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動制御オプションとして付記されているのです。

カレーなど、ある種のレシピ限定することで、見た目の理解やすさを得ることができますが、一方それは表現力を損なうことを意味します。

C言語などではマクロを使うこともできますが、それは結局、関数型プログラミングアプローチ意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。

GUI

iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードキャンセルできます

このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。

これをオブジェクト指向で実現しようとすると、

1. 三つの異なるボタンを同じ位置に置くか

2. 同じボタンが三つの異なる機能を持つか

という下らない問題にぶつかります

一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。

「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」

この条件が満たされているうちは、オブジェクト指向GUIを実現することに無理はありません。

しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。

近年、PCのディスプレイの大きさは、頭打ちになってきました。

画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルひとつドットを表すようになってきています

これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。

したがって、未来GUIプログラミングは、注意深く機能ピックアップして制限するというデザイナー努力を脇におけば、

関数型プログラミングの力を頼るしか無いでしょう。

はじめよう、関数型プログラミング

まり

Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ワヒャヒャヒャヒャヒャヒャ

1. google:すごいHaskellたのしく学ぼう を注文する。

2. Download Haskell自分のPCに導入する。

3. コンソールghciと入力して、対話コンソールを立ち上げる。

4. 次の関数コンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。

take 4 $ map (*2) [1..]

5. ステップ1で買った教科書を読んで、学ぶ。


追記:

いかがでしたか

ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全から、とか、より速いから、などという妄言が満ち溢れています

オブジェクト指向関数型プログラミングは、水と油ではありません。プログラマ自分プログラムに最適なアプローチを選ぶことができます

一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティライブラリ最近増えてきています)。

この記事を読んだオブジェクト指向プログラマあなたが、少しでも関数型プログラミングに(そしてHaskell)興味を持ってくださって、ホームセンター大人用オシメのコーナーが大賑わいになれば幸いです。。

2014-02-19

ユーザーコントロール一般的クラス継承したら

継承したクラスコンストラクタで、自分自身の InitializeComponent() を呼び出しましょう。

基底クラスイベントを捕捉する場合には必須

.NET Framework にて。

2013-11-16

武蔵をお迎えして、艦これをきっぱり辞めると決めてから

初めて迎えた土曜日が暇で暇でしょうがない。

はてぶの記事を上から読んでいくのにもすぐに飽きた。

コンビニ飯ももういいや。

モルモットみたいに部屋をうろうろして使ってない2Kの倉庫部屋を開け放したら、

それだけで空気が淀んだ。

部屋の片隅にはここ二年間まともに開いてもない蔵書の山。

一瞥しただけでは分厚い埃が積もって何の本かわからず、

拭ったらそれだけで咳が出た。結城浩さんのデザインパターンの本にマーチンファウラー氏のリファクタリング

ここ最近、参画するプロジェクト業務はテスターばかりで、そんな概念があることすら忘れていた。

PMになってもおかしくない歳で、テスターばかりやっている自分が今更読んで何になるんだよと思いつつ、ぱらぱら捲ってみる。

「このコンストラクタにpublicがないのは同じパッケージ以外からの参照を防ぐため」←ここ使えるっ!

『使える』かよ。ひどく気に障るメモだった。

この本を読んで、いつか設計することを夢見ていた頃の残滓だった。

2012-07-13

いや、わかるけど・・・

初期化は必ずコンストラクタで みたいなことを Javascriptで言い出すなら

もう、自由な言語じゃなくて、C++みたいな 型定義型の言語にしちゃえよ。

2012-06-15

http://anond.hatelabo.jp/20120615111615

スマートポインタは、ここで言われている アドレスの参照指定としてのポインタじゃないよ。単なるコンテナ名前ポインタってついてるからといって、いわゆるポインタじゃない。分類的にはコンテナ

 

const char *str = "hogehoge";

std::string str = "hogehoge";

std::tr1::smart_ptr<std::vectorchar> > hako(new std::vectorchar>);

の3種類があった時に string型も ポインタを代入しているが、 ポインタとは呼ばないだろ。コンテナと呼ぶ。

記法上 new を呼び出すが、 それが嫌なら、そういうコンストラクタ書いてもいいしな。

 

const char*なら

str++ とか str-- str+n という記法アドレス参照 ができるが

スマートポインタは そういう使い方はしない。 あくまでも指定されたオブジェクト管理するだけ。

たいていの使い方をする場合に、参照カウンタの増減なんて手動ではしないから。(というか、ポインタがわからない奴がするな コピコン使え という設計方針でいいとおもう)

そして、マーク&スイープはガベコレの技法からまして、自動でやるもので、たいていのプログラマーに書かせるものじゃない。

http://anond.hatelabo.jp/20120614121920

ポインタ、参照(リファレンス)、束縛(バインディング)、それぞれ似てるけど同様に語ると混乱の元ではないかと。

 

ポインタメモリアドレスに型情報をくっつけたもの。加減算できる点が特徴で、それはメモリアドレス概念由来だろう。

変数というメモリ上の記憶域を指すフィジカルに近い概念で、配列運用(*p++で回すとか)、引数の参照渡し(コピー抑止、複数戻り値の実現)、メモリのもの管理malloc)あたりで、基本手作業による最適化のための仕組みという側面が近いと思う。

 

perlだと、変数はやっぱり記憶域ではあるけれど概念として一段抽象化されていて、メモリという連続した領域じゃなく独立した領域の集合となっているから、リファレンスの加減算はなし。

また、配列も単なるメモリの並びからより抽象化してリストもできたから、配列運用や複数戻り値リストがあるのでリファレンスに頼ることはなくなる。

ただ、オブジェクト概念があって、オブジェクトオブジェクトとして入れる変数は用意せずリファレンスとすることで、文法上の変数の型を増やさない、コピー時のコンストラクタの問題を回避するなどのほか、オブジェクト概念を援用して無名関数無名変数ファイルハンドルなども変数引数として扱えるようにした。

 

で、pythonはもう一段推し進めて、今までの数値や文字、配列オブジェクトとみなし、変数はすべてオブジェクトを指し示すもので、記憶域は変数としてあるのではなくオブジェクトとしてあり、変数リファレンスという特別なものがあるのではなくなり、変数記憶域をもっていて値が代入されるものではなく、既にあるオブジェクト変数名という名前(ラベル)を付けて束縛する行為とされる。

見方を変えると変数はすべてにおいてリファレンスで、代入とは値そのものの代入でなく値へのリファレンスの代入で、引数も参照渡しであるが、引数に代入したところでリファレンスが変わるだけで元の値が変わるわけではなく、しかし他の演算などでは自動的にデリファレンスされており、単純な数値や文字列など、自身を変更する機構を持たない(できない)ものにとっては実質的に今までとの違いはないに等しい。隠ぺいといえば隠ぺいか

java, javascript, rubyもおおむねこの考え方でよかったと思う。

ただ、phpは若干両者が混じったところがあって微妙なところがある。

 

参考

2012-06-14

http://anond.hatelabo.jp/20120614151953

それ、単純にクラスの使い方が悪いってだけに見えるんだが。

少なくともそんなカツカツにタイミング調整が必要になるソフトで、そんな頻繁にオブジェクト生成すること自体間違ってるし、頻繁に生成されるオブジェクトコンストラクタにクソ重い処理を入れているのも問題だし。

回生成したオブジェクトを使い回せないかとか、クソ重いけど一回実行すれば当面実行しなくていいような初期設定処理はファクトリクラスとかに追い出せないかとか、叩きようはいくらでもあるぞ。

http://anond.hatelabo.jp/20120614151953

メモリはいくらでも取っていいが、CPUは有限資産からな。

PC プログラマだけどメモリは潤沢なのに CPU 資源だけ制限があるってすごく不思議に聞こえる。

今頃は PC だったら CPU 資源はほぼ無限 (少なくとも C++ コンストラクタ呼び出しを気にしない程度には) だぞ。

組み込みの話だとしても組み込みなら両方ともきついんじゃね?

http://anond.hatelabo.jp/20120614144026

いや C++コンストラクタが、使わない時にでも動くのが嫌なので

メモリは バルクで取って コンストラクタ必要な時だけ 手動で呼び出すぞ。

メモリはいくらでも取っていいが、CPUは有限資産からな。

 

それこそ、必要な時だけnewすればって考え方もあるが、メモリフラグメントする。

俺らの時代だと、そのへんは脊髄に染み付いているから、考える考えないじゃなくて、普通にやる。

 

なんで?いや、サクサクアニメーションとかを追求すると このへんを突き詰めないと30fpsとか60fpsとか出ないだろ。

欲しいのはメモリ管理じゃなくてUX なんだが、結果 メモリ管理踏み込む

2012-01-04

プログラミング初心者たわごと

JavaScript って生き物っぽいって思ったのがきっかけだった。

なんか菌?に遺伝子いれてたんぱく質生産させるやつ? Function は菌の細胞膜prototype遺伝子で、だから prototype全然関係ない違う生物遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。

インスタンスからじゃないと複製できないのも生き物っぽい。

インスタンスって言い方になにか違和感があるなあ。

だってプロトタイプベースって、生き物しかいない世界じゃない?基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベース世界にはそんな設計図も生き物じゃないものもないよね?なのにわざわざインスタンスっていうのに何か違和感ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。

僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界イメージだ。多分、原始の生物インスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。

オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScriptコンストラクタイメージ

Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python名前空間さえあればなんとかなるよねってのも、JavaScriptハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。(bless という命名はすごく洒落てる)

全然関係ないけど、Django日本語リファレンスは何か萌えるラクダ本日本語訳はむかつくのに。

プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミング技術ってやつだと思ってた。

でも多分違う。

世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界勝手表現されていくし、動き出してく。たまたま僕らの世界オブジェクトもので溢れていて、プログラミング言語進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。

(知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない!)

プログラミング表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマ世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。

やっとプログラミング面白くなってきた初心者より。

2011-03-30

NetBeans の City Lights  で、クラス名が黒くなる問題

→少なくとも4年前には解決していない

http://goo.gl/hvY3k

http://netbeans.org/bugzilla/show_bug.cgi?id=114689

 

→Norway today」を改造して、City Lightsに似たオリジナルを作る。

クラスの色は「Norway today」と同じになるが、バックが黒に文字が黒よりは見やすい。

 デフォルトフォント:Monospaced 16

 

  凡例  前景  背景 その他

 

デフォルト 緑 黒

URL 継承 継承 →エフェクト:下線付き エフェクトカラー:青

インターフェース継承

エラー 白 赤

・エンティティー参照 シアン 継承

キーワード オレンジ 継承

クラス (→マゼンタ) 継承

コメント継承

コンストラクタ 継承 継承 →フォント:継承+ボールド-イタリック

・セパレータ 継承

フィールド 9,134,24 継承 →フォント:継承+ボールド-イタリック

マークアップ属性 0,124,0 継承

マークアップ属性継承(黄色?) 継承

マークアップ要素(タグ)オレンジ 継承

メソッド 継承 継承 →フォント:継承+ボールド-イタリック

メソッドパラメータ 160,96,1 継承

・使用されていない要素 グレー 継承

・公開要素 全継承

・列挙 全継承

局所変数継承

抽象クラスまたはメソッド継承

・数値 黄 継承

・文字 黄 継承

文字列継承

・(演算子) ピンク 継承

・空白 全継承

・識別子 全継承

・公開限定要素 全継承

・静的要素 継承 継承 →フォント:継承+ボールド-イタリック

・非公開要素 全継承

・非推奨の要素 継承 継承 →エフェクト:打ち消し線 エフェクトカラー:濃いグレー

ログイン ユーザー登録
ようこそ ゲスト さん