リファクタリングがしやすいのは、静的型付け言語

1 ：2012/06/10 〜 最終レス ：2012/11/05

Eclipse JDT のリファクタリング機能を探る
http://www.ibm.com/developerworks/jp/opensource/library/os-eclipse-refactoring/
まあ、まずこれを読みましょう。
Eclipseが凄いだけ？ 半分間違っています。
静的型付け言語が凄いから、Eclipseもここまで便利な機能を搭載できるのです。
いくらEclipseでも、動的型付け言語に同レベルの機能は搭載できません。
実際されてません。

2 ：

性的種付け行為？

3 ：

以下、動的型付け言語厨が
エディタで十分！説を披露してくれます

4 ：

いや、言語が酷いからEclipseが凄い環境になったんだろ？
エディタで充分とまでは言わんよ、Eclipseは実際に凄い環境なのだから

5 ：

言語が酷くないとEclipseが対応してくれず
エディタも不十分
詰んでるなｗ

6 ：

言語が酷いとIDEサポートも出来ない。
色つけるだけしかできないのなら、viやemacsで十分。
酷い言語は可哀想である。

7 ：

Eclipseが対応してない言語なんてあるの？

8 ：

動的型付け言語にリファクタリングなんていらないだろ
書いて捨てるだけ

9 ：

参照透明なら順序すら気にせず大胆にリファクタリングできるよ！
これからは純粋関数型言語でリファクタリングの時代ってことだね！

んなわきゃーない

10 ：

C++はかなりやりにくそうだな
名前の変更も苦しそうｊだし

11 ：

>>10
まあ、大変だろうね。開発者の苦労は知らないがこんなことが出来るらしい。
http://www.wholetomato.com/products/featureRefactoring.asp
Rename
Extract Method
Encapsulate Field
Change Signature
Move Implementation to Source File
Add Member
Add Similar Member
Document Method
Create Declaration
Create Implementation
Create from Usage
Implement Interface / Virtual Methods

12 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

13 ：

アイちゃん遅いよｗ

14 ：

操作しやすいな

15 ：

リファクタリングという単語は、勘違いしたゴミッカスOO厨に侵食されたので
これからはソースコードの最適化という単語を使っていく
勘違いなきよう
静的言語がそんなに大好きなら、勝手にやってろと思う
ただし、俺を巻き込むな
一人でやってろ

16 ：

>>15
バカ丸だし

17 ：

ゴミみたいなスレだな

18 ：

アプリのバージョンアップというのは
家の増改築に当たると思う。
最初の想定外の増改築を行う時
既存の部分の補強が必ず必要。
そうしないと言え全体が壊れる。
この補強作業こそがリファクタリング。
リファクタリングはいわば将来への投資
最適化とは目的が違うな。

19 ：

>>15
これは頭が悪いなあ

20 ：

>>18
リファクタリングの必要性を説くべき相手は経営層
「会社の規模が大きくなったら組織化・体制づくりが必須」
みたいなたとえが合ってるんじゃないかな
最適化どころか形式ばったムダばかり生まれる
それでもたがいに足を引っ張り合う秩序崩壊よりはずっとマシ、と

21 ：

頭も悪い奴がどんどん言葉の質を下げていく
勝手にやってろゴミ

22 ：

静的言語はゴミでしかない

23 ：

uyは就職しろ
まじでゴミカスになるぞ

24 ：

ゴミ

25 ：

ゴミカス

26 ：

イザナミだ

27 ：

uyは就職しろ
まじでゴミカスになるぞ

28 ：

人は生きているだけで、他の生物をR
綺麗な魚を、綺麗な鳥を、牛など、野菜を食べ、
そしてゴミを排出する
それが人だ、
だとすれば人はこんなことをやっている場合じゃない
綺麗なものを壊し続けているんだから
多くの命を奪い続けているんだから
せいぜい何かマシで綺麗なものを創作しろ

29 ：

最初にRefactoringBrowserが実装されたのは動的言語であるSmalltalk。
>>11
のリストの機能も代替サポートされとるよ。

30 ：

メソッド名を変更するとき、関係ないクラスのメソッドまで
全部リネームする（そうしないと壊れる）のを「代替機能がある」
と呼ぶなら、そうだね。

31 ：

最初にRefactoringBrowserが実装されたのは動的言語であるSmalltalkだが、
静的型付け言語のほうが、RefactoringBrowserをもっと効率良く
安全に行えることが判明した。

32 ：

1000 ：uy ◆xVOGOO9ev6 ：2012/06/23(土) 12:35:29.68
俺は動的言語の問題点をいくつあげてもｗｗｗｗｗ
静的言語よりはマシだと確信してるわｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

静的言語の問題点をなぜ挙げないかって？？
見放してるから、問題点を指摘さえしないってことだよｗｗｗｗｗｗｗｗｗｗｗ
気づけバカｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

33 ：

javascriptゴリゴリ書かせられてるんだが
明らかにクソだとわかってても直す気がなくなっていく
これが動的言語・・・・

34 ：

動的、静的より周辺ツールを作りやすい言語を作るべき
てか、ただのエディタでコード習性とか死ぬ

35 ：

動的言語はまともなツールが作れない

36 ：

スクリプトを書き捨てるだけの言語に
リファクタリングとかある訳ないだろ

37 ：

動的型付言語でリファクタリングで困る事ってなんだ？
関数名書き換えたいってなら、同じシグニチャの関数列挙して
ユーザーがOKを押せば随時置換してくれる用なもんで十分だけど
他に何か困ることがあるか？

38 ：

名前変更・・・動的型付でも可能
移動・・・動的型付でも可能(リファクタリング以前に統合開発環境なら大体できる)
ローカル変数の抽出・・・動的型付でも可能
定数の抽出・・・動的型付でも可能
ローカル変数をフィールドに変換・・・動的型付ならthisなり@なりつければ済むので不要
匿名クラスをネストに変換・・・Java以外の言語なら不要
メンバー・タイプをトップ・レベルに変換・・・動的型付でも可能
インターフェースの抽出・・・動的型付の場合大体は不要、ただしObjective-Cの様に存在する場合でも問題なく可能。
スーパークラスの抽出・・・可能であるが、多用すべきじゃない。
メソッドの抽出・・・動的型付でも可能
インライン化・・・動的型付でも可能
メソッド・シグニチャーの変更・・・同一シグニチャの関数を列挙し確認した上で変更することで可能
　　　　　　　　　　　　　　　　　　　　静的片付けでも変更可能不可を判断しなきゃ行けないんで手間は変わらない
　　　　　　　　　　　　　　　　　　　　むしろインターフェースの分離が必要なので静的型付の方がメンドイ
総称型引数の推測・・・不要
Eclipseの機能だとこんなもんか。てかEclipseのリファクタリング機能って
殆ど単なるマクロ系機能でリファクタリングじゃないよな

39 ：

>>382
お前、「リファクタリング」を知らないだろ。
そこに出ている名前は、リファクタリングの著名な本で
リファクタリングとして定義されている機能なんだが。

40 ：

>>37
その方法で、countっていう名前を
置換したら、バグだらけになったよｗ

41 ：

なんで、>>1にしっかりと
リファクタリングが「しやすい」って書いてあるのに
出来る出来ないの話に持って行こうとするんだろうね。
動的言語の場合は面倒だったり、人間の判断が多く必要だったり
修正完了までに時間がかかったり、バグを起こしやすいってだけで、
出来るか出来ないかで言えば、出来るに決まってるだろ。
それは、反論になっていない。
しにくいという事実を否定してないんだから。

42 ：

>>40
countのどこにシグニチャが出てくるのか詳しく

43 ：

>>41
具体的にどうしにくいの？。
>>38に出てる内容だと、動的静的関係あるのってメソッド名だけだよね。
それ以外リファクタリングツールがあれば何も変わらないよね。

44 ：

>>40
タダの置換じゃなくリファクタリングツールつかえよ

45 ：

>>42
Rubyしらないの？
countという名前のメソッド作れるんだが。
不要な()を書く必要はない。

46 ：

>>43
動的言語だと、実行時にしかわからない情報が多いから
静的なリファクタリングと相性が悪い。
一見修正できたように見えても、実行するとエラーが起きる。
リファクタリングってのは、動作を変えずにコードを変えることだが
静的言語だと、「動作を変えない」という保証を
リファクタリングツールが行えるのに対して、
動的言語だと、人間が保証しなければならない＝時間がかかる。
静的言語・・・リファクタリング開始 → 終了（完璧に動く）
動的言語・・・リファクタリング開始 → テストコードを動かす → 完璧ではなかった → 人間が問題箇所を調べる → 修正する → 完璧になるまで繰り返し → 完璧って保障は誰がするの？

47 ：

>>45
()があるか無いか関係なくね。a.xxxとあれば列挙して名前を書き換えていいか確認したら
置換にOK指示をだせばいいだけじゃん
>>46
コンパイルエラーが発生する代わりに実行時にエラーがでるのはリファクタリングに限った話じゃない
結局テスト云々の問題になる。そもそも静的型付だって安易に関数名を変えられない。
簡単に書き換えられるのは仮想じゃない関数だけだ。関数名変えるなら継承元や
派生全てへの影響を考えて調整する必要がある。動的型と同じ最悪実行時エラーも招く。
(今までオーバーライドしてなかった関数をオーバーライドしてしまった等)

48 ：

> 置換にOK指示をだせばいいだけじゃん
ほらそれそれ、
人間がやる作業がある。
置換してOKか？すぐに分からない。
時間がかかる。

49 ：

>>47
動的言語だと、それが仮想関数かさえわからないよな？
関数名書き換えられないと自分で認めてるのに気づいた？
静的言語だと、ちゃんと仮想関数まで追尾してくれる。
継承元や派生すべての影響を考えて修正してくれるんだよ。
もちろん、今までオーバーライドしていなかった。ということも検知してくれるし、
新たにオーバーライドしてしまうようなリファクタリングをしようとしたら
ちゃんと教えてくれる。

50 ：

>>48
静的型でも同じじゃん
>>49
>関数名書き換えられないと自分で認めてるのに気づいた？
できるけど、静的型でも動的型でも同じ問題にぶつかるって書いてるよ。
>静的言語だと、ちゃんと仮想関数まで追尾してくれる。
>継承元や派生すべての影響を考えて修正してくれるんだよ。
置き換えて大丈夫かどうか調べにゃならんのは同じでしょ

51 ：

>>49
一応言うけど、動的型言語の場合シグニチャが同じなら
全て同じインターフェースの関数を利用してると同義なんだよ。
静的型付でもインターフェースの影響範囲を全部しらべるよね。

52 ：

動的型は、実体が同一のJavaやC++の様なメンバー関数形式じゃなくて
メッセージとメソッド形式だからなぁ。切り口を変えれば手間も対して変わらんってのは
メンバー関数な人には理解しづらいんだろ

53 ：

>>49
>もちろん、今までオーバーライドしていなかった。ということも検知してくれるし、
>新たにオーバーライドしてしまうようなリファクタリングをしようとしたら
>ちゃんと教えてくれる。
動的型付なら同じメソッドもってりゃ全て派生みたいなもんだし
もし警告が出るようなツールがあっても全てのクラスに警告がでるから
そもそも意味がないでしょ

54 ：

>>50
> 置き換えて大丈夫かどうか調べにゃならんのは同じでしょ
なんで、意味的に一致する所を全部書き換えるのに
いちいち調べなきゃならんのだ。

55 ：

>>53
だから、そのさが静的言語のリファクタリングのしやすさに繋がってるの。

56 ：

>>54
addを２つのクラスなりプロトコルなりインターフェースなりから受け継いでて
片方をappendに変える事になったらもう片方にも影響するだろ
この時わざわざ名前を変えたのは"本来意味が違う"のに間違った名前をつけてたからだ
意味と名前がそぐわないから名前を変えるってのはリファクタリング理由の一つだろ？

57 ：

>>55
「だから」になってないよ。同じメソッドを持ってるクラスが全て同じインターフェースを実装してる場合と
何が違うのか一切反論になってないし

58 ：

>>56
その片方に影響するという事実が
静的言語なら検出可能になる。
実際にリファクタリングをしようとしたら
動的言語だと、人間が判断してやるしか無く、
ミスするのが目に見えているが、
静的言語だと、「このメソッドは他のクラスからも継承しているため
変更するのは危険です」と警告が出せるだろう。

59 ：

>>57
> 同じメソッドを持ってるクラスが全て同じインターフェースを実装してる場合
動的言語だと、本当に同じインターフェースを実装しているかが検出不可能。
メソッドを実行時に付け加えたり外したりするから、
どうやっても確実な情報が得られない。

60 ：

>>58
他でも出てるが動的型付なら全て同じインターフェースやプロトコルなんかを実装してるのと同じ。
警告出すんなら全部の同じメソッドを持ったメソッドに出さなきゃならんだけで警告自体意味がない。

61 ：

>>59
それはjavascriptとかプロトタイプベースの問題で
動的型付言語と別問題だろ

62 ：

>>59
静的型付言語に出来ない機能を引き合いに出してどうすんだよ。

63 ：

>>59
golangとかC++のsignature(gcc拡張)とかで静的型言語でも
実装できそうな機能じゃあるが、静的だと簡単になるか？

64 ：

つつく所がメソッドのリネームしか無いのか・・・

65 ：

>>62
動的言語は静的言語で出来ないことを出来るようにしたために
実行前に判断できていたことをできなくしてしまった。
実行時にメソッドを変更するとか、ほとんど必要とされない機能。
なぜなら、ほとんどのことは実行前に静的に変更すること、
つまり何らかのメタ情報を元にコードを自動生成する機能で対応可能だから。
>>64
シグネチャの変更やクラス構造の変更までくると
動的言語は太刀打ち出来ないからね。
この話をすると、静的言語の圧勝になる。

66 ：

たとえば、Railsとかで有名な
「データベース定義を元に実行時にメソッドを生成する機能」なんかは
データベース定義を元にクラスを生成するコードジェネレータを使えば、
実行前にメソッドを生成することが可能。

67 ：

>>65
プロトタイプの問題で動的型付け関係ないよね

68 ：

>>65
静的型付け言語でメソッド差し替えできた場合は楽にリファクタリングできるの？

69 ：

>>68
メソッド差し替えは目的ではない。
なぜそんなことをするのかから
話を聞こうか。

70 ：

>>69
差し替えのメリットは無効化かな、静的型付言語の場合はデリゲート用。
静的型付言語でのメソッド追加のメリットは型を合わせられる点。
var a Prototype
var b Concept
b = a // Conceptに必要なメンバーが足りないのでコンパイルエラー
a.Example := func( _ Prototype )(){}
b = a // Conceptに必要なメンバーが足りているのでコンパイルが通る。

71 ：

> 差し替えのメリットは無効化かな
意味不明

72 ：

> b = a // Conceptに必要なメンバーが足りないのでコンパイルエラー
> a.Example := func( _ Prototype )(){}
> b = a // Conceptに必要なメンバーが足りているのでコンパイルが通る。
こんなもん、実行前にやればいいだけの話だな。

73 ：

実行時に、メソッドを付け加えたり
外したりするのは間違いなんだよ。
どうせ実行時に付け加えたメソッドを
使っているコードをあらかじめ書いてるんだ？
つまり、実行前にわかっていることなんだよ。
コード見れば実行前にわかっていることを
実行時に行うのはおかしい。

74 ：

>>71
空の動作を与えれば実行したくない動作をしなくなる
応用すれば、使い捨てのスタブオブジェクトを作れる
>>72
静的言語の話だから当然実行前だよ

75 ：

もしかしてクラス内で宣言しないと静的型付言語じゃないと思ってる奴がいる？

76 ：

>>74
実行前に
> b = a // Conceptに必要なメンバーが足りないのでコンパイルエラー
> a.Example := func( _ Prototype )(){}
> b = a // Conceptに必要なメンバーが足りているのでコンパイルが通る。
こんな、実行文のような書き方で
クラス定義をする言語を知らないのだが？
擬似言語ならこんな感じがいいでしょう。
class Concept { ... }
partial class Concept {
　func partial Example() {}
}
C#っぽく書いたが、静的言語でクラス定義をコンパイル時に拡張する方法の提案。
動的言語はアセンブラと同じようなもので、実行時に自分自身を書き換えることで
いろんなことができるけど、それは応急処置みたいなもので、その先に進化の道はない。
本当に実行時にやらなくてはいけないことなんて、すごく少なくて、
それを無くすことで、リファクタリングはより一層便利なものになる。

77 ：

>>73
ぶっちゃけメソッドのつけ外しがメリットが大きなメリットだとは思ってない
静的型言語でも可能だから動的型固有の問題じゃないといいたかっただけ

78 ：

>>76
golangの様な言語じゃないと無理だよ。
C#方式じゃインターフェースとクラスの結合が必須だから実現できない。

79 ：

>>76
実行時か実行前かは関係ないんだっつうの

80 ：

>>79
大有りだってｗ
実行前に決まっていることというのは、
コンピュータがすべてを把握できる。
実行しないとわからないこと、つまり未来はコンピュータにはわからない。
リファクタリングは実行前に行う作業だ。
リファクタリング以前に情報がわかるのとわからないのとでは
できることに大きな差がある。

81 ：

>>77
> 静的型言語でも可能だから動的型固有の問題じゃないといいたかっただけ
そりゃメソッドの追加とか可能だろう。
だけど、それが実行前に行われるってところが重要。
それがリファクタリングのしさすさに影響してくくる。

82 ：

そういやgolang系統じゃなくてもJavaとかなら近いことができるか

Concept b = new Concept()
{
　　　Prototype prototype = new Prototype();
　　　int function()
　　　{
　　　　　　prototype.function();
　　　}
　　　void example(){色々}
}

83 ：

>>80-81 静的型と動的型で同じコードリファクタリングして具体的にどう変わる？

84 ：

>>83
質問が意味不明。
アメリカに行くのに、船で行くのか、飛行機で行くのかと
聞いているようなものだ。
具体的に変わるもの？ 手間と時間だろ。

85 ：

>>84
例えば>>82と動的型言語で等価なコードを書いてた場合どう変わる？
メソッドを追加するという行為に対して結局どっちもリファクタリングの手間は変わらないじゃん。

86 ：

メソッドを追加するのは、動きが変わっているから
リファクタリングではない。単なる機能追加だ。

87 ：

もっと具体的に書こうか。名前変更の際、静的型付言語ならConceptというインターフェースのexampleメソッド全てを書き換える。
動的型言語ならexampleというインターフェースのexampleというメソッド全てを書き換える。
結局手間は変わらない。

88 ：

>>86
国語ができないなら書き込むなよ

89 ：

リファクタリングではないが、メソッドの追加に
伴う問題に、静的型付け言語のメリットは存在するぞ。

あるクラスAにfooというメソッドを追加するとき
Aを継承したクラスBですでにfooというメソッドを定義していた。
こういう場合は予期せぬバグになるだろうから
実行前に検出するのがベターだ。
つまりJavaのoverrideアノテーション機能の話だよ。

90 ：

>>86
メソッド追加をリファクタリングか議論してるんじゃなくて
メソッド追加があるものをリファクタリングするのは難しいって話してるんだよ〜
わかるぅぼくぅ？

91 ：

>>87
意図的に手間がかかる部分を省略しないように。
Conceptというインターフェースのexampleメソッド全てを書き換える。
書き換えた場合に、Conceptというインターフェースそのものではなく、
そのexampleメソッドを使っているコードすべてを書き換えないといけない。
ここ、ここが一番手間がかかる部分で
お前が意図的に省略したところだよ。
これ、全て自動でやってくれるんですよ。
静的型付け言語のリファクタリング機能なら。

92 ：

>>89
うん凄くどうでもいい

93 ：

>>92
ならレスしないように

94 ：

>>91
なるほど、たしかにそれはそのとおりだ。
exampleすべてを置換するわけにもいかない。
exampleが該当クラスのexampleであるかは
obj.exampleのobjが該当クラスかどうかの情報が必要になる。
つまり変数の型情報が必要になる。

95 ：

>>91
動的片付けなら同一シグニチャのexample全てを書き換える
明示的にインターフェースを分離したいなら最初から
conceptExampleの用にインターフェース名が名前に含まれる訳で結局変わらんよ

96 ：

> 動的片付けなら同一シグニチャのexample全てを書き換える
同一シグニチャでも、全く関係ないメソッドはどうする？

97 ：

Objective-Cの糞長いメッセージ名なんかがいい例じゃん
メッセージ名が同じなら同じインターフェース。メッセージ名が違うなら違うインターフェース。

98 ：

型がない言語だと、シグニチャ＝引数の数になっちゃうから
関係ないのに同一シグニチャになる可能性が多いんだよな。

99 ：

>>96
動的型付言語の流儀として最初から作っちゃいかんだろ
もし有ったらそれこそリファクタリングして別名に分けなきゃ

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Borland C++ Compiler オ　ワ　タ (313)
proce55ing　プログラミングアート全般 (622)
GCCについて part10 (220)
だめです！ HSP厨は絶対に犯罪です。 (946)
Microsoft Silverlight その9 (379)
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5 (937)
--log9.info------------------
【近畿】関西ドライブ情報スレ Part16【2府4県】 (231)
え〜〜おいおい、どうして代車がこれなんだＹＯ？ (421)
代車借りるとすること (249)
○ ATF(フルード/オイル)情報交換スレッド Part8 ○ (892)
ケツから入れるのが普通じゃないんですか？ (519)
車のエンジンオイルに関する常識は？ (375)
深夜のドライブ　第七十五話★ (385)
【自働】オートバックス 19店舗目【後退】 (215)
【激務】ディーラー総合スレッド16【薄給】 (430)
　　　ミニバンでも「高級車」は別格　　 (381)
エンジンルーム洗浄 (364)
【業者】ガラスコーティングスレ【依頼】5 (468)
洗車剤・コーティング剤総合82 (285)
【うまい奴】高速道路の走り方・12【へたな奴】 (571)
【俺ルール】車に常備するもの (589)
30超えてコンパクトカーはやばいですか？★33台目 (220)
--log55.com------------------
【Rank0.175↑】グランブルーファンタジースレ1074
グラブルアニメ実況スレ
【mobage】アイドルマスターシンデレラガールズ26897人目
───プリンセスナイト
お昼のまったりグラブル雑談スレ
【mobage】アイドルマスターシンデレラガールズ26898人目
グラブルの話題盛り沢山のスレ
アンチラ！なかにだすぞ！