短いコードはわかりやすい ← これは間違いだった

中級者にありがち。

なんでも一行で済ませようとする。
短く書くのが絶対にいいことだと思って疑わない。

少し冗長に書いたり、付加情報をつけたほうが
コードは読みやすくなる

(自称)中級者の間違いだろ。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

俺も>>1には同意する
ロジックを1行にまとめてしまう部分にも言えるが
設計全体についてもいえる
大規模になるはずの設計を小さくまとめると
複雑さが増したりしてる

で、それを繰り返していくと誰には扱えない超効率的なシステムが出来上がる

俺はそこまでいった後、未熟な俺にも扱えるように、わざと最近はコードを冗長させてることもある
コピペしたほうがいい部分もあるんだよ

すべてを妥協なしでコピペなしで作って果てまでいくと、マジで凄いものが出来上がるぞ
絶対に使えない凄いものが

1行の単純ロジックで、読み易さ云々って、低レベル過ぎだろ。

>>5
p [*"a".."f"].zip(["_"].cycle.with_index(100)).join
よめる？
実行せずに実行結果予測できる？

必要以上に短いコードは判りにくいだけ。

バカは変数名を1文字にする。

>>6

「説明用変数の導入(Introducing Explaining Variable)」
という名前がついているリファクタリングを行う必要があるな。

正直ソースをテキストだけで記述するってのは限界だと思う。
xml化でもいいけど、もっと設計内容や変更履歴、修正内容まで全てぶち込めるような
形式に移行してもいいんじゃないかと。

>>9
そこでWEBですよ。

>>1
まあ一般的にはその通りだが、まさか
Cなどの3項演算子ごときが理解できないんじゃないだろうなｗ

大企業では3項演算子は禁止です＞＜

んなこたあねえだろ
どこの大企業だ

言えるわけ無いだろｗ

恥ずかしすぎるから。

>>9
同意
上から下へ記述するだけの平面的エディタはそろそろ終了

>>15
今時、構造を把握出来ないエディタで仕事になるのか？

そういう事を言ってるわけじゃないんだけどな

>>16
言語にもよる。Prologなんかだと、構造なんて概念がないから要らないと思う。

COBOLを使えということだな

>>19
不要、と実現出来ない、の違いが有るけどな。

具体的に
短くて解らないのを長くして解るようになった例を
見せて

>>21
スレタイでは一般化してるから、2、3の事例では不足だけどな。

>>21
７行プログラミングとかその極みだろ
あとビット数を数えるやつとか1/√nを求めるアルゴリズムとか

>>21

一瞬でも、ん？ って思ったら負けな

n = 28 + (1 / (y % 4 + 1)) * (1 - 1 / (y % 100 + 1)) + (1 / (y % 400 + 1));























n = 28;
if(y % 4 == 0) n++;
if(y % 100 == 0) n--;
if(y % 400 == 0) n++;

普通
if (y % 400 == 0 || (y % 4 == 0 && y % 100 != 0)) n++:
だろ

そもそも、どっちも似たような長さじゃん
趣旨理解してないのか？

>>25
それみても、ん？って思うだろｗ

ん？って一瞬思考が止まるのが
わかりにくいコード。

すらすら読めるのが、わかりやすいコード。


コードの長さを短くするのではなく
（他人が読んだ時に）理解するまでにかかる時間が短いのが
良いコードである。

%って==より優先だっけ？

しかしコード量が多いとわかった気になって罠を見過ごすことも

別にこんなコードでも、ん？とはならないな

n = 28 +!(y % 4) - !(y % 100) + !(y % 400);

そりゃお前が書いたからだろｗ

短いとか長いってこういうののことだと思っていたw
theDay.isLeapYear?
d.isLeap?

なんだメソッド名の長さか？
そんなもんJavaさんの圧勝だろ

「短いコードは読み難いからそんなコード書くな」と言い出す奴の低能率は異常

>>35
リーダブルコード、もう読んだ？

読んでないよねｗ

え？The Art of Readable Code読んだの？と思ったら
日本語訳出てたのか

2012年8月8日以降に販売されるパソコンを全部買ったのか

　　　　　　　＼　　　 ;;;--‐''''::::::::::::::::::ヽ　　　　　　　　_,,−''
　　　　　　　　　　／:::::::::::::::::::::::::::::::::::::::::::､　　　 _,,−''
｀−､、　　　　　 /::::::::::::::::::::::::::::::::::::::::::::::::::::､　　　　　　　　_,,−''
　　　　｀−､、　i':::::::::::::::::/､::::::::::::::::::::::::::::::::::::i　　　　　　　　　
　　　　　　　　　|::::::::::::::/　 :､:::::::::::::::::::::::::::::::::|　　
　　　　　　　　　|::::::::;／ ‐─ ヽ─ヾ::::::::::::::::::::|　　　LISPは俺の妄想やねん
────　　　.|:::::i'　　 ヾ●） （●ﾉ 　 ｀i:::::::| 　
　　　　　　　　　.ﾞ:､:|　　 　"" ﾉ ､ ﾞﾞ　 　　 |:::/
　　　　　　　　　 　 |　　 　　 (＿_)　　 　　|　　　　　
　　　 _,,−'　　　　 .i　　 　^t三三ﾃ'　 　　,!　　 ｀−､、
_,,−'' 　　　　　　　 ヽ、 　　　　　　　 　ノ　　　　　　　｀−､、
　　　　　　　　. 　　　　＼___　　　 ___／
　　　　　　　　　 　　 　　　 |￣￣|　　　　　

短いコードほど検索に掛かり難いということはないのかな？

７行プログラミングみたいにやり杉なのはともかく

言語特有の短い記述を利用した事によって
読めない奴が出てくるっていうのは
熟練度の問題だけどね

>>41
いろいろなプログラマレベルが存在することは当然で、ある水準にならないと
読めないコードが存在するなら、それは言語の問題。

チームのコミュニケーションの問題だろ。

オブジェクト指向で書かれたプログラムを与えても、上から下に流れるプログラムしか読めないプログラマ()は読めないから言語の問題だけではないだろう。
新しい方法で綺麗に書けば、新たに学べる人には読みやすいだろうけど、古い読み方しかできない人には読みづらい。
多くの言語は、いろんな書き方ができる。

>短いコードはわかりやすい
単純にして読みやすく

いろんな会社でプログラム組んできたけど
少し自信のある（大抵は若い）プログラマーは
技術の高い人しか分からないような高度なプログラムを書いてるんだ
って思って貰いたい傾向があるから、必要以上に
複雑な処理をしたがる気がする

特徴的に分かり難いと思ったのは、関数分割の時代はとにかく極限まで、
細かい処理に分割するし、オブジェクト指向時代は極限までオブジェクトを
細分化して定義しようとする。そしてそれぞれに付けられる名前は
暗号のような短縮された名前だったりする。
プログラムのエントリーポイントは初めて見た人が見ても
わかりやすい名前ですか？
モジュール分割しているなら、それぞれのモジュールの名前は
その役割が誰でもが分かりやすいものですか？

充分に単純なプログラムは、充分に単純なプログラムで書けるはずです。
単純なプログラムを単純に書けない人は、大規模プログラムを
安全でメンテナンスを容易に書く事は出来ないですよ

要するにあれだ、
漢字を使うと読めない人が出てくるから
みんなひらがなを使いましょう、ってやつだ

短くても読みやすいコードはあるけど
ゴミカスが短くまとめるとゴミカスってだけ
ただ純粋にそいつのスキルが低い

極限まで短くするなら最適解のコードをかけよ？ いや100点とはいわず、せめて90点くらいの
短くまとめたのにアルゴリズム的に点数つけるなら50点とかそこらだとゴミでしかない

uyは小物ほどよく吼えるっていうのを体言してるな

小物（）

口数減らせば大物のフリ出来るよね

>47
ああそういうことか。

つまり、正しいのはこういうことだな。

漢字を使ったら、全部ひらがなよりも分かりやすくなることが多いが
だからといって、必要以上に難しい感じを使うと、読みづらくなる。

法律用語のような難しい言葉で書くよりも
平坦な言葉で書いたほうがわかりやすい。

なんでさぁ
ストレートにそれはそれ。これはこれ。　と、考えりゃいいのに
一々別のものに例えなきゃ思考すらできねーのお前ら

アホなの？

バカなの？

コード書けないから
例えで分かった気になってるだけ

>>52
どうでもよくね？

反論したいわけじゃないでしょ？

>>54は例えるなら人間ではなく動物に近い
例えるならこのスレはまるで牧場のようだな
例えるならスレッドにレスという草が生えていてお前らはさながらそのレスをムシャムシャと
牛のように食べていく家畜に似ている
例えるならしかし実際食べているつもりでもその草には毒草が混じっていて
バカな牛はなぜか毒草をこぞって食べようとする
例えるならそして胃の中で消化不良を起こし体と精神を内面から崩していくのに
そう例えるならお前らは家畜に似た実験動物
実験動物がプログラミングについて語っている様は例えるなら
逃げられない運命からの現実逃避に似ている
例えば意味のないレスに躍起になってレスを返すのはその証拠
例えば「？」というクエスチョンマークはこの場合疑問符ではなく
例えるなら小鳥が親鳥からエサをもらう時に上を見上げ物欲しげな顔をする行為に似ているレスを欲する為の「？」に過ぎない

あー、例え話をしてみたら54を分かった気になれた

「短いのが必ずしもいいプログラムではない」という誰でもわかる誤解のしようがない言葉をわざわざ何かに例える自体、
わざわざ複雑にしたがる、または何でも単純化したがる奴らのすること。

コードの長さは関係ない
一行にまとめようが、数行に分けようが理解の難しさは全く変わらない
それよりも抽象化の多用がコードを読みにくくしている最大の原因

>>57
同意。

begin...end;　　　　vs　　{...}
if (a = b) then　　vs　　if (a == b)
a := b　　　　　　　vs　　a = b

どっちがわかりやすい？

このスレの短くってその話じゃないです

int val = (a == b) ? c : d;
と
int val = c;
if (a == b) {
  val = d;
}
と
int val;
if (a == b) {
   val = c;
} else {
  val = d;
}
短いほどわかりやすくね？

短すぎるとハマった時にハマりまくるとか？

>>24
ん？ 2つ目掛けるのか？
yが100で割り切れる時は * 0
割り切れない時は * 1 になりそうだが。

あ、ん？って思ったら負けなのか

まだ「短くて分かり難い」コードが出ていない件

(defun Y (f)
((lambda (x)
(f (x x)))
(lambda (x)
(f (x x)))))

>>59
どっちも同じ。

構文が違うだけで
表面は同じだから。

そして、文字数は違うがタイピングに
かかる時間にほとんど違いはないだろう。

なぜなら実際の開発では
タイピング以外の部分がコーディング時間の
大半だから。

y f = f (y f)

昔の人は短く書くために色んな技法を使ってたよね
もうわざと読みにくくしてんのかと思うぐらい
そうしたのはいろいろ制約があったからだろうけど
そんなのを保守することがあったから>1の言うことはわかる

短いコードを冗長な等価なコードにトランスレートしてから保守すりゃいいだろカス

やっぱり冗長なのは良くないよ
Javaですら分かってる

http://www.flickr.com/photos/33583790@N00/7465233960/

書く奴がバカなのか

読む奴がバカなのか

>>57
それは設計が間違ってるんじゃね。　アセンブラレベルの命令を判りやすく抽象化したC言語がわかりにくいとは思わない。

馬鹿には無理

>>70
冗長というのは、コードに含まれてる
情報量が同じなのに、長いコードのことを言う。

たとえば、動的言語は型情報をなくしているだけ。
つまり情報量が減っている。その分開発が大変になる。
それと比較して情報量が多いJavaが冗長。という言い方は間違い。

>>69
短いコード: http://nojiriko.asia/prolog/fizzbuzz_6.html
長いコード: http://nojiriko.asia/prolog/fizzbuzz_4.html
w

＞たとえば、動的言語は型情報をなくしているだけ。
＞つまり情報量が減っている。その分開発が大変になる。

開発は楽

大変なのは「デバッグ」な？知ったか君

さすが xor で and や or を再現できる有能なお方は、デバッグが開発工程に入っていないようですねｗｗｗｗ
謝れば楽になるよｗ

それから動的言語は静的言語に比べれば
速度を犠牲にしても書きやすい構文・機能を入れたり
（↑本当は静的言語でも入れられるにもかかわらず入れてこない）

しているんで普通にいまは動的言語で書いていけるレベルなら動的言語のほうが開発効率は高い
いつまで末尾「；」のついてる言語で遊んでんの？
この「；」打つ事が積み重なってどれだけの時間無駄にしているか気づいてないか？

>>77
人の文章読み間違えていらねーもん開発しちゃった方ですか？

デバッグは1人で開発する場面においては全然時間かからないだろうに
まさか自分で書いたコードを完全に忘れるとか、自分で書いたコードのテストに梃子摺るなんていう事態は考えられない
デバッグというのは開発人数が増えるにしたがって加速的に増えていく
少人数なら問題にならない

というのをお前らにいくら「教えても」無駄ってことは分かっているんだ

俺には、1人や少人数で開発したプログラムにおいて

一体どこにデバッグに梃子摺る要素があるのか分からない

分けが分からないｗ
自分で書いたコードすら管理できないならプログラミングやめろよ

>>76
デバッグしてから開発クローズしろよw

誰がお前の意見を聞きたいと言った？
お前に発言権を与えた覚えはない

1人で書いたソースコードのデバッグ作業に梃子摺るようなレベルで
自分で書いたコードすら管理できないならプログラミングやめろよ

I/Fの少ない、或いは抽象度の高いプログラムに限定するなら、同意。
デバッグが必要なプログラミングをしているのなら、何か間違っている。
しかし、GUIやドライバのような自分が全てを知り得ないようなものとのI/Fを
プログラミングするのであれば、相性と言う問題も含めてデバッグが必要になってくる。
或いは、チューニング作業もある意味デバッグと言ってもいいかもしれない。

それはさて、トリッキーで短いコードは判り難いと言うことはそんなに受け容れ難いことなのかねぇ。

それ以前に発言権を奪う権限を与えた覚えがない。
自分の書いたプログラムにバグがないと思ってるのか。よっぽど使い道のないプログラムならそういうこともあるか。

>>66
学生の教育用として開発されたPascal言語と
OSも書ける言語として開発されたC言語、その目指す方向性は違う。

Pascalは教育用として一般の人にも理解しやすい言語仕様となっている。

>if (a = b) then　　vs　　if (a == b)
一般社会では、aとbが等しいかは、”＝”を使っているし
>a := b　　　　　　　vs　　a = b
代入の意味で”＝”を使うこともない。
>begin...end;　　　　vs　　{...}
あと、始まりと終わりを”｛｝”で表すなんて言語仕様をしらないと分からない。

C言語はOSも書けるよう可読性を有る程度犠牲にしても
効率や速度などを重視する。

同じ言語なら可読性が高い方が良いが
可読性は技術者のスキルによっても違ってくる。
初心者に合わせた可読性なんて逆に読みにくいし
上級者ぶって書かれたソースも分かり難い。

つまり、可読性は主観的な部分が多いということ。

上級者は大抵文句たれずに読むから
読めねーって騒ぐ層はおのずと分かる

>>85
>begin...end; 初めと終わり
そういう意味なのか。初めて知った。

そういうやつもいるなら、これしかないな。

こっから→

←いまここ

←ここまで

末尾に；のある言語はゴミ

言語が統一される事がまずないんだよな
でも少し散らばりすぎ
XML（ML)　Lisp（S式）　C系（ふつう。）　begin~end のブロック構文でかける言語
この4種類あたりが必要だと思える

で、消し去った言語の概念はこの4言語がすべてカバーする
言語数が少なくなれば初心者とかあまり関係ない
プログラミングをするにあたっての覚えるべき知識が一気に減る

>>90
勝手に使わなければいいだろ。

いみふ

>>90
> C系（ふつう。）
> begin~end のブロック構文でかける言語

これを分けてる時点で、知恵遅れということがバレバレだな。

ふむ、PascalとCを同一視すると。

begin〜endと { } が
アルゴリズム的にもかなり別物というのを理解してないな

rubyなんかは大体同じだろ
高階関数のシンタックスシュガーに使えるだけで

ブロック構文は別物

1分は書き捨てるだけじゃなくてもっと主張しろよ雑魚

>>95
セマンティックスによるだけだから、別物と決めつけるのも間違い。

誤字どんまい

実際>>90この中から選ぶんだったら
XML　C　Ruby　で十分ってことだよね

その他の言語はいらない

>>79
いいから動的言語向けヘッダライブラリの実物を一つでいいから見せてみろよｗ
謝れば楽になるのにｗ

全部shでいいよ。中にヒアドキュメントで好きな言語書くから。

彼は
include（笑）

とrequireの違いは理解できたのだろうか

もうさ
使わないなら使わないでいいと思うよ
お前らの人生は俺に関係ない
仕事がJAVAしかないなら家でもJAVAで、
そんで何もかもJAVAで、作っていればいいよ
仕事でしかプログラミングやらないやつは、そのほうが幸せなのかもしれない

俺は一番効率の良い道具じゃないと精神的にプログラミングしてられないから
俺はお前らよりも全然ダメだよ
効率のでないプログラミングなんてプログラミングじゃないと思ってんだ
お前たちはJAVAでもかけるっていうならある意味才能
そういう我慢のできる人間共のほうが使い勝手がいいしな
否定すんのやめるよ
JAVAやってろ

でもJAVAＰＧは二度と話しかけんなよ

マシでバカとゴミとJAVAＰＧと低脳とサルとゴミカスと人間共は二度と話しかけんなよ

JavaのHogeHoge hoge = new HogeHoge(foo, bar, baz)
は流石に無いと思った
なんでC++の HogeHoge hoge(foo, bar, baz)から更に冗長になるのだろうか・・・

>>107
そりゃやってることが違うからだろ。

同じだよバカ

そもそもnewの位置がおかしいんだよ
newはメソッドにしろよ
new演算子て。
なに考えて言語作ってんだよ

でもお前らはJAVAやれ

メソッドチェーンをつなげすぎとかね。あんなの自己満足以外の何者でもない。読みづらいし、修正しづらいし。

rubyやってるやつってちょっと頭かわいそうな感じなのは何故？

javaやってるやつってちょっと人生かわいそうな感じなのは何故？

Javaは使い捨て奴隷だからね

それはJavaには限らない

PGSEやってるやつってちょっと人生かわいそうな感じなのはなぜ？

マジレスするとかわいそうな奴しかプログラムなんて組もうと思わないから

Javaのやつらがやってるプログラミングって
まったく頭使わないから楽しくないだろうな
それで給料も安いんだから悲惨

大半の仕事はそんなもんだ
楽しい、給料が高いのどちらかひとつが満たされるだけでも少数派

虚業

>>115
お前の知り合いは、そんなのばっかりって事だ。

>>120
かわいそうな人間の一人だという自覚を持ったほうがいい

35過ぎても派遣でPGならかわいそうと思われてもしかたないかもな

やっと気づいたのかよ
はやく業界脱出できるといいね、、、

そもそも本当に虚業じゃん
プログラミングは一般人からすれば大変で
それなのにほぼ毎日毎日無意味なものを作ってるって悲惨以外になんといったらいいか

プログラマになりたがるにわかが減れば虚業で業界まわさずにすむんだよ
本当はいらない仕事を働き手が余っているという理由でとりあえず
なんかやらせて給料与えてるだけ
プログラマはもういらない

だから実際JAVAとかrubyとか関係ないよ？
そもそも需要と仕事がないところで
無理やり金回してるよ？
言語の効率もゴミカスコードも関係ない
まずプログラマーがこんなにいらないんだから

虚業が儲かるお陰で本当にお金が必要な所に金が回らないということがあればそりゃかなり酷い話だろうな

お客は言語で金くれたりしないよ。
どの言語使っても、給料は同じ

ちょっと何かをこだわってみたり
将来性を考えたりする余裕がないんだろ
バブルとはまた違うんだろうけど
そのうち一気につぶれると思う

預言者現る。

コンピュータ言語の前に
日本語の勉強をしては？

壊れたテープレコーダーみたいに
日本語がー英語がーって


さっさと電池きれろ

自分で自分の電池の心配とかw

壊れ

昔、アセンブラ書いてた頃はソースをプリントアウトするのは必須だった
とても頭の中に収まらないから
でも今は開発環境が素晴らしく良くできているので
素早く目的のコードを出せるしモニタのみで編集できる
とは言ってもモニタに表示できるコードはごく僅か

作った本人ならコードがどんな流れになっているか判っている
しかし人のコードはあっちこっち頻繁に見て確認するハメになる
そんな時、ダラダラと長ったらしいソースだったらどうなるか
発狂する
モニタに１つのモジュールがスクロールせずに表示できるのがベスト

クラス化して読まなくても済むようになってる。

classにそんな機能ありません

君の考えてるプログラミングが幼稚なだけ

いちいちクラスの中のコード読まないと使えないのか。使えないやつは大変だな。

中を読みたくても読めない無能が言う台詞じゃないな

どう考えてもclassの中のコードの話

>>128
スクリプトに拘りを持つヤツがバカなんだよ
制御なりネットワークなりノウハウが溜まる分野はあるだろ

バカでも出来るプログラムって、思ってる奴は
無能自慢が得意なんだね

>>135
カプセル化の機能はそれなりに提供されてる。privateもしらないウンコだと自覚せよ。

そのカプセル化されたprivateメソッドの中の話だというのに話がなぜか通じない
まあクラスの中身を作る or 見る機会のないゴミってことにしておくか

見る”機会”って言ってるってことは、
見ないこともあるって言ってるようなもんだｗ

機会があればいってみたい ← 毎回行っていると思いますか？

>>117
それってrails,PHPも同じだろ

自称天才がいるの？

133 ：デフォルトの名無しさん：2012/08/11(土) 17:10:41.44
昔、アセンブラ書いてた頃はソースをプリントアウトするのは必須だった
とても頭の中に収まらないから
でも今は開発環境が素晴らしく良くできているので
素早く目的のコードを出せるしモニタのみで編集できる
とは言ってもモニタに表示できるコードはごく僅か

作った本人ならコードがどんな流れになっているか判っている
しかし人のコードはあっちこっち頻繁に見て確認するハメになる
そんな時、ダラダラと長ったらしいソースだったらどうなるか
発狂する
モニタに１つのモジュールがスクロールせずに表示できるのがベスト

134 ：デフォルトの名無しさん：2012/08/11(土) 17:20:58.22
クラス化して読まなくても済むようになってる。





会話になってない

そういうのは最初のレスでするもんだ。　おまえの負けだ。

uyの作ったクラスは中のコードをいちいち読まないと使えないそうです。

uyはその辺のブログあさって真に受けた知識とruby信者特有のキモさだけで語ってるから
実際にコード書いたことないよ
書き込みも読む価値なし

rubyの知識で俺様に勝てたら褒めて遣わす

俺の最近のクラスの使い方は
if 条件
　　AAA_class.new
end

こんなんだしな
コンストラクタで全部処理するから戻り値とか受け取る必要なし

数万年前に通り過ぎてもはやクラスをクラスとしては使ってないのに
今更､俺にクラスがどうとか言われてもな

うわひどい

>>152
言っとくけどひどいはRubyのほう
デストラクタなしでどうやってゲーム作るんだよ

デストラクタでオブジェクトの解放のコードを書くのはNGとしても
ゲームっていうのはデストラクタで次のオブジェクトの生成コードを描きたいんだよ

不便すぎてしゃーねーわ
俺様はもうアレな方法で実装しているからいいんだけど
もしrubyのオブジェクト指向に従って書いていたらデストラクタは実装できなかった
俺様設計の勝利

Rubyがウンコなだけだろ。


オレはコンストラクトデーモンとデストラクトデーモンで回避する。

uyはサブルーチンしか使えないんだね。

難しい問題だと思ったよ
デストラクタを言語に実装するとデストラクタに書くべきではない処理を書くアホがでてくるから実装はしないほうがいい
でもゲームでは明らかに必要なんだ
mobの消滅時に消滅しますたっていうメッセージの発行がな
ああ一枚メソッドかませることで実装しましたよでも言語にそなわってればかかずにすむ2行は釈然としない

スマートポインタがあれば、終了処理などを任意のタイミングに制御できる。

黙れ初心者


消滅しますたをデストラクタでかかないとすると
第３者からの監視になるよね
オブジェクトを常に見張るオブジェクトが必要になる
別にかけるけどネストしすぎるんだよ


mazu的にはこのあたりどう考えるんだろう
オブジェクトＡが消滅したことをしりたいオブジェクトＢがあったら
mazuはデストラクタ不要論を押し通して第３者監視型でオブジェクトＢは常にオブジェクトＡを見張る設計を是とするか
やっぱりデストラクタ必要ですねとなるか
いや多分デストラクタの代わりとなる仕組みを一時的に入れるに落ち着くか
だろうな

タスクの１つ１つをメソッドのメタ定義でやって
メソッドミッシングあたりでeachして
タスクの削除はメソッドの削除でやると
メソッドが削除された時に呼ばれるメソッドはあるから
ruby仕様内で合法的に()デストラクタを作る方法もなくはない

まあ、まだプログラム初めて20年ちょっとの初心者ですが。

その程度のコストも支払えない環境で開発するなら、Cでアセンブラ時代にやっていたような仕組みを導入するのがよいです。

固定構造体に確保済み配列を使いまわす例のヤツねｗ

uyが初心者なのは良くわかった

長い短い関係ないよ

プログラムの挙動が容易に想像できる範囲内にあるかどうかだよ。
単一機能がそれなりに複雑になってくると全ての挙動をドキュメント化することも
出来ないので、結局ソースを読むはめに。

単一機能を想像できる範囲に収めるってのが、短いプログラムの意味じゃないか。

>>159
おまえは20年間なにやってたんだよ
どう読み間違えたらタスク周りの問題だと勘違いするんだよおい歴20年

あぁ、デストラクタとファイナライザをごっちゃにしてるのか。

う、うるさい！

結局rubyは小さなものを作る言語なんだよね
いくつかmathは重要な概念を言語からなくして
かけないようにさせて大規模開発でのバグをなくさせようという主張がはいってて
それは正しいんだけど
逆に考えたら常に手抜きせずにガチで設計しソースかかなければrubyでは大規模プログラムがかけないといっているようなものでもある
想定されていないmazuの理解の範疇を超えたプログラムはrubyでは作りにくい場合があるのかもしれない

http://doc.ruby-lang.org/ja/1.9.2/class/ObjectSpace.html
define_finalizer

デストラクタなら自分で定義しろ。

ファイナライザとか関係ないし

現バージョンは1､9､3だし

すでに定義してあってその上で問題点をはなしているのに？

rubyがちゃんと速度でるならデストラクタ以外の実装もありえたが流石にまだ犠牲が大きすぎてやる気がしない
デストラクタはなくせる
それは事実
でもそれはそれ以外の部分がちゃんと作られていることが前提
デストラクタで別オブジェクトに対してのメッセージの発行が必要になる原因は
オブジェクトAの削除を速度的な問題から別オブジェクトCに委任しているから

オブジェクトAからオブジェクトBへ直接メッセージが送れず
かといって無関係のオブジェクトCにAからBのメッセージかくのもおかしい
だからデストラクタが必要になってしまった
ちゃんとつくればオブジェクトCがそもそもなくなるからオブジェクトAからBにダイレクトになってデストラクタもいらない

速度をください

普通のプログラマは適材適所でいろんな言語使うのになんでuyはわざわざ目的に適してないrubyにこだわって文句ばっかり言ってるんだろう
あ、rubyしかでき(

俺が文句さえ言わない言語はもはや見放してる
ム板に自分のメモかいてるようなもんだからスルーでもいいよ

ほとんどコンストラクタに処理詰め込むような設計だし
ruby以外ではかけるかどうか怪しいソースになってる
プログラミングは再利用の効率を高めるのがそれなりに難しい
自分の書いたソースコードを無駄にしない仕組み
そのためには固有情報のような情報を、つまりプログラム内からハードコードィングされたアルゴリズムそのものを消し去る必要がある
あるいはハードコードィングされた部分を変更なしで別の物を作れる設計
静的言語では無理

>>167
http://doc.ruby-lang.org/ja/1.9.3/class/ObjectSpace.html

そのファイナライザと間違ったデストラクタの定義ならrubyにはある。
速度が欲しいのにインタプリタなんて使うなよ。

嘘だらけのメモで初心者がミスリードされたら可愛そうだ。

>>171
>そのためには固有情報のような情報を、つまりプログラム内からハードコードィングされたアルゴリズムそのものを消し去る必要がある
シングルトンしか知らないのか?何の為のステートパターンだ

>>172
そんな単純な方法で実装できるデストラクタはrubyにはない

>>174
Stateパターン知りませんでした
調べてみたらこんなゴミカスパターン使ってる奴がいることを知って涙でてきた･･･

Stateパターンはありえなすぎる
状態によってオブジェクトの振る舞いをかえるとか、どんなゴミ設計だよ
出来るけどやっちゃいけない事だろそれはｗｗｗｗｗｗｗ
変数の中身をちょろちょろ変えんな

シーンの推移をこれで作ってる奴がいるみたいだけど、マジ無駄

これがデザインパターンの弊害だ

>>175
おまえ、デザパタの本を読んだって言ってけれど、最近になって書籍を購入しただろ
妄想を垂れてないで一度ぐらいデザパタが適応されたコードでも読んでみろ

知合いの気がしてならない

何の為にわざわざオブジェクト指向のスクリプトなんて使っているんだろう

＞ おまえ、デザパタの本を読んだって言ってけれど、最近になって書籍を購入しただろ
デザパタの本を読んだ覚えがない　　書籍を購入した覚えがない
２３種？のデザパタを何一つ認めた覚えがない

デザインパターンにそってプログラムを組むというのは、ソースコードの個性をなくして
プログラマAとプログラマBを「同じような存在」として扱うための奴隷機構だぞ？

そもそもデザパタ定義した奴が俺よりもはるかに程度の低いプログラムしか作ってないんだから
それが俺のプロジェクトで通用するわけがないじゃん
身の程を知れ

既にソースコードを完璧にする方法は分かってるんだよ
ただ速度的な観点から、""僅か１箇所""、書き方を変えているだけ
数年後には速度をクリアして、完璧なものへと書き直してると思われる

>>169 適材適所っていうけど、言語コロコロ変えられるような、
それほど小規模なものは作っていない、作っていく段階で壁はあるってだけ

>プログラマAとプログラマBを「同じような存在」として扱うための奴隷機構だぞ？
一人でしかプログラムを書かない、書けないバカが言いだしそうな台詞だな
アルゴリズムとは別の誰が書いても同じような部分は没個性的であればあるほど良いに決まっている
既に築き上げられた定石とイディオムの塊だよ。
vc++やvbから入った奴らのガラパゴス進化したコードなんて読んでみたいと思うか？想像するだけでぞっとする

デザパタはただの金のなる木だろ
一部の奴にとっての。
そこに気づけないのが底辺PG

C++の速度がうらやましくなる事の方が多い
元々が開発効率上げるために速度を許容できるところまで犠牲にしていくスタイルで
その為に動的言語選んでいるようなものだから
将来的なpcスペの向上とrubyに将来（まともな）並列処理がはいることを見越して作ってる
C++では許されるゴミカスアルゴリズムもrubyでは許されない
ちゃんと速度を意識して作らないといけない、

>>181
＞没個性的　＞良いに決まっている
不正解

それを定義した奴が「自分よりも上」なら、いいだろうけど
デザパタを定義した奴よりもスキルが高い奴らはいくらでもいて、そういう奴らか見たらデザパタはゴミなんだよ　わかるかね？

少なくともデザパタの使用によって開発効率は上がりませんよ？
プログラマAがデザパタを使用して書いたソースコードを、
プログラマBがリーディングする時に、効率が上がるってだけ
異論はないですね？

まさに社畜御用達


デザパタにあるようなパターンは自分でオリジナル実装したほうがはるかに優れたものが作れるだろう
あくまでデザパタは、誰にでも扱えるように”簡単”で”基礎的”なパターンを詰め込んだだけのもので
そのような初心者用の機構で開発効率は向上しない

＞vc++やvbから入った奴らのガラパゴス進化したコードなんて読んでみたいと思うか？想像するだけでぞっとする

読んでみたいわ
保守はしたくない

>>182
糞コテよかGoFの方が上だと普通はそう思うよ
>C++の速度がうらやましくなる事の方が多い
おまえ本当にc++でプログラム書いたことあるの?javaで書く方が相当にマシだから

お前いま世界の半数のゲームPGを敵にした

C++よりJAVAがマシって、
何が？
念のため言っておくけどゲームでGCは邪魔だよ

>>186
どう考えてもc++しか他に選択肢がないから仕方なく使っているだろ
>C++よりJAVAがマシって
納期内にメモリリークなんて探したくないから
イディオムも多すぎて、最低でもeffective c++ぐらいは読まないとコードが書けない

君にC++使えとか言ってない

基本的に賢いC++erはC言語拡張としてC++を使うよ
やたらとクラスの機能は使わない

C++で複雑にテンプレート駆使してやっている事は
動的言語で（速度を犠牲にすれば）一瞬で出来る事
あまり意味がない

本当に速度が必要ならそんな高価な機能使わなければいいだけだし
速度がひつようでないなら動的言語でやればいい
C++の深みにハマるやつがアホ

GCないからプログラミングできませんとかいってる奴って
C++が使えないじゃなくて「C言語」が使えないんだろｗ

マシな部分を一般論で答えたんだよ
システムなら速度が重要な部分だけcで書くだろ

>>189
c++のテンプレートは実際にメモリに展開されるから速いってメリットがあるの
javaやc#のジェネリクスとは別物

社会復帰できるといいね。脳内プログラマ君

>>185
>糞コテよかGoFの方が上だと普通はそう思うよ
正確に言うとGoFは発見しただけ、大勢のOO技術者が
長年の経験より導き出したデザインをGoFがまとめたもの。

つまり、「自分は全てのOO技術者より上」だと主張したいのでは？

>>183
>デザパタにあるようなパターンは自分でオリジナル実装したほうがはるかに優れたものが作れるだろう
デザイン＝設計のパターン実装パターンじゃない。

デザインパターンを使わないほうがはるかに優れたものが作れるだろう

に読み替えといて

>>182
> デザパタを定義した奴よりもスキルが高い奴らはいくらでもいて、そういう奴らか見たらデザパタはゴミなんだよ　わかるかね？


デザパタを定義した奴よりスキルが高い奴はいくらでもいるのは事実だが、

そういう人達が、デザパタをゴミといっているのはみかけません。

Gof（笑）が発表しちゃったようなデザインパターン（）のようなものは
これからも定期的にでてくるだろう

ある程度ネタがたまったら誰かそういう技術資料を上手くまとめてうまく世に公表できる奴が発表する
デザインパターン以上のものは既に世にごまんとあると考えるべき
誰もそれをまとめていないだけ

デザインパターンが広まる以前からデザインパターン相当のものを使っていた奴がいたのと同じこと

>>195
ゴミって言ってるように見える

http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_%28%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%29

デザインパターン本の23パターンは主にJava, C++などの静的型付け言語における実装であり、ピーター・ノーヴィグは、23パターンのうちの16パターンは（言語によるサポートによって）単純化できることをLispまたはDylanを用いて実演している。[1]

またデザインパターンに限らず一般的な話として、技術を不適切に使用することで、ソフトウェアの複雑度を不必要に高めてしまうことがある。[2]

http://www.norvig.com/design-patterns/

パターンって呼ばれるほど繰り返し現れるなら、
本来ならメタプログラミングなどで抽象化してしかるべき
何度も似たようなコード書くなんて馬鹿のする事

なのに抽象化出来ないのは言語の表現力が劣ってるから
デザパタなんて有り難がるようなもんじゃない

>23パターンのうちの16パターンは（言語によるサポートによって）単純化できる

構造化設計発表。
　　　↓
有効性が認められる。
　　　↓
言語により構造化設計をサポートする構造化言語が続々と発表。

設計を言語でサポートさせるのは自然なながれ。
だから、デザインパターンは設計パターンで実装パターンじゃない。

1 + 2 を「足し算パターン（キリッ」とか言い出す奴が居たら笑っちゃうだろ
デザパタはそういうレベルなんだよ

183 ：uy：2012/08/12(日) 11:46:35.21
少なくともデザパタの使用によって開発効率は上がりませんよ？
プログラマAがデザパタを使用して書いたソースコードを、
プログラマBがリーディングする時に、効率が上がるってだけ

デザインパターンはドカタ用コミュニケーションツール

初心者がデザパタ本読んでもなに１つ活用できないから、活用されているコードを読む方がいい。

ステートパターンはゲームにこそ向いているもの。　ファイルの読み込み中と読み込み後で挙動が変わるリソース管理クラスとか
破壊前と破壊後で動作が変わるキャラクタオブジェクトなどなど。

>>203
＞ステートパターンはゲームにこそ向いているもの。
むいてないから、やめろ

＞ 破壊前と破壊後で動作が変わるキャラクタオブジェクトなどなど。
やめとけ

>>202
あーなんかそんな感じだ

オブジェクト指向だってデザインパターンだし、配列や連想配列だってデザインパターンだ
デザインパターンという言葉が考え出されたときには既に言語に組み込まれていただけ

いわゆるデザパタ本に載っているデザインパターンだって、現代的な言語では添付クラスや第三者ライブラリで実現可能（または組み込まれている）なものが多い

デザパタも短く書ける方が分かり易い

>>196
デザインパターン＝ゴミという
お前の（あほな）考えを当てはめると

> デザインパターンが広まる以前からデザインパターン相当のものを使っていた奴がいたのと同じこと
ゴミ相当のものを使っていたことになるが？ｗ

>>197
それのどこがゴミなのかと？ デザインパターンを使わないなんて書いてないだろ。
デザインパターンを単純化して書いてるわけだろ。

お前まさか、デザインパターンが実装まで規定してると思ってるの？
Javaでの実装例であって、別にあのように書かないといけないわけじゃないんだが。

大学とかで、これ教えてるんだっけ･･･？

ああ。。。可愛そうに
教育機関は教科書を新しくしたりしていくペースがITの進化よりも
２歩３歩後ろからついてくるしかないからなぁ
まじめな学生は報われないよ

良レスあげ

182 ：uy：2012/08/12(日) 11:42:10.68
デザパタはただの金のなる木だろ
一部の奴にとっての。

183 ：uy：2012/08/12(日) 11:46:35.21
少なくともデザパタの使用によって開発効率は上がりませんよ？
プログラマAがデザパタを使用して書いたソースコードを、
プログラマBがリーディングする時に、効率が上がるってだけ
異論はないですね？


202 ：デフォルトの名無しさん：2012/08/12(日) 13:33:32.12
デザインパターンはドカタ用コミュニケーションツール

>>208
＞ >>196
＞ デザインパターン＝ゴミという
＞ お前の（あほな）考えを当てはめると

＞ > デザインパターンが広まる以前からデザインパターン相当のものを使っていた奴がいたのと同じこと
＞ ゴミ相当のものを使っていたことになるが？ｗ


~~~~この程度~~~~のものをキリッとしながら世に発信してるのがゴミだって事だよ
オブジェクト指向然り。クラウド然り。


経験が浅いとデザインパターン（）にあるアルゴリズムのパターンを
1度も見たことがない or 書いた事がない
って奴がいて、そういう奴らにパターン覚えさせる為に見せるなら有りではあるが
普通はｗｗ自分で書いた事のある or よく使ってきたパターンに勝手に名前付けられてる気がして気分は良くない
デザパタなんてゴミドカタしか賛同しないよ

>>209
教授の頭にカビが生えてるところはUML以前のDFDが使われてるよ

あげ

>自分で書いた事のある or よく使ってきたパターンに勝手に名前付けられてる気がして気分は良くない

普通に思い付くようなパターンで気分を害されてもなぁ。他の人からみたらuyが真似してるようにしか見えない。

俺はどちらかというとデザインパターンで気分は害してない
だいたいOOでプログラムかくことって少ないから使えないんだよね
いくらデザインパターンのライブラリをrubyが用意してくれてもミックスインするクラスがない
興味本位で調べて評価してみただけ

じゃあ語るな

言うこところころ変わるな。

保身してないで言いたいこと言えよ

でっていう

優秀なPGの中には自分の技術を公表しないやつもいる

短いコードじゃなくて、単純なアルゴリズムだろ。

糖質な奴がそう思い込んでいるだけ。

え、糖質なやつって
お前はいま誰のこと思い浮かべてそれかいたの？
明日も顔あわせるような同僚とかですか？
なんでそうゆうことかくの？

7行プログラミングとかワンライナーみたいなのって
短いコードっていうのとはちょっと違うよな。展開するとそこそこあるし。

7行にギッシリ詰め込んだら
普通見やすくにかくと50行くらいはある

Rubyで7行ぎっしり詰め込んだら
Javaに翻訳すると1000行くらいになる

>>222
なぜか選ばれたのが貴方です、糖質に選ばれおめでとう。なんで
反応しちゃったの？

>>222
そうゆうことだからだよ

207 名前：デフォルトの名無しさん [sage]： 2012/08/12(日) 14:22:17.51
デザパタも短く書ける方が分かり易い

213 名前：デフォルトの名無しさん []： 2012/08/12(日) 17:49:01.30
あげ

216 名前：デフォルトの名無しさん [sage]： 2012/08/12(日) 18:47:29.44
じゃあ語るな

217 名前：デフォルトの名無しさん [sage]： 2012/08/12(日) 18:54:29.73
言うこところころ変わるな。

218 名前：デフォルトの名無しさん [sage]： 2012/08/12(日) 19:07:43.27
保身してないで言いたいこと言えよ

220 名前：デフォルトの名無しさん []： 2012/08/12(日) 19:27:12.85
優秀なPGの中には自分の技術を公表しないやつもいる

221 名前：デフォルトの名無しさん []： 2012/08/12(日) 20:13:26.13
短いコードじゃなくて、単純なアルゴリズムだろ。

糖質な奴がそう思い込んでいるだけ。

223 名前：デフォルトの名無しさん [sage]： 2012/08/12(日) 20:21:33.14
7行プログラミングとかワンライナーみたいなのって
短いコードっていうのとはちょっと違うよな。展開するとそこそこあるし。

224 名前：デフォルトの名無しさん []： 2012/08/12(日) 20:27:59.81
7行にギッシリ詰め込んだら
普通見やすくにかくと50行くらいはある

>>226
人の心の汚さを見つめていた

プログラマでC++できないとかそうとう残念な感じだから、大至急使えるようになったほうがいい

C++のうんこさは相当なもんだけど、使えた方が良いのは事実だな

つかそれC、C++から入らなかったやつでしょ
生まれながらにして残念

無理に使わなくてよい
C++は有益ソースとゴミカスソースの見分けがつきにくいんだ
バカにさわってほしくない
ブログに好き勝手かかれると検索結果が汚れる

笑

は？なに笑ってんの

最近C++をバカにする風潮あるけど
C++認めない奴は初心者
積極的に使えとはいってない
ただそのうち素晴らしいものに出来上がるよC++
あと数年だけ待てよ

笑

はあああああああああああああ？

>>235
笑

http://ja.wikipedia.org/wiki/C%2B%2B0x

Rubyって仕事で使ってんの？　マジでC++やっとけよ。

ニートだろ

なんで今更>>239貼ったの？
もしかしてものすごい初心者？

小学生じゃなかったのか。

>>240
はっあああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ？

>>241
はぁ？？？？？？？？？？？？？

>>242
はあああああああああああああああああああ？？？？？？？？？？？

>>243
はーーーーーーーーーーぁ????？？？？？？？？？？？？？？？

>>240
はっああああああああああああああああああああああああああaaaaaaaあああああああああああああああああああああああああああああああああああああああ？
はaaaaaaaaaaaaaぁ？？？？？？？？？？？？？????????

>>241
はaaaaaaaaaaaaaぁ？？？？？？？？？？？？？????????
はあああああああああああaaaaaaaaaaaああああああああaaaaaaaaaaaaaaa？？？？？？？？？？？?????????

>>242
はあああああああああああaaaaaaaaaaaああああああああaaaaaaaaaaaaaaa？？？？？？？？？？？?????????
はーーーーーーーーーーぁaaaaaaaaaaaaaa????？？？？？？？？？？？？？？？?????????????????????

>>243
はーーーーーーーーーーぁaaaaaaaaaaaaaa????？？？？？？？？？？？？？？？?????????????????????
はっああああああああああああああああああああああああああaaaaaaaあああああああああああああああああああああああああああああああああああああああ？

幼稚だなぁ

マジでC++覚えろってマジで。

は？

C++作った奴本当に偉い
現開発者も本当に偉い

C++はモノを作る言語ではなく訓練用言語である
ruybは仕様変更によって多くの人的リソースを消費してきたけど
そういえばC++のほうがひどかったな
rubyはC++ほどじゃないから全然大丈夫ｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

プログラマーの皆さんに質問でーす
プログラミングって数学は必要になりますかー？

スレ違いなんで

結局俺様はrubyで限りなく完璧に近い設計をかけているけど、
それはC++でかけない事が分かってる
そうなると、C++でもかける幼稚なタスクシステムでの書き直し
1日ネタだね

本当はゲーム開発ってC# or Javaが妥当なところなんだろうな
JavaならScalaとかClojureとかその他もろもろついてくるんでしょ jrubyもあるか
どうしてもC++な奴は、スクリプト言語1個拾ってさっさと組み込めよ　としかいえない
ゲームPGは未だにC++狂が多いから悲惨
それでもC++でゲーム作っちゃう奴は作っちゃうのだから凄いスキルと情報処理能力の高さがあるんだろうね

>>250
http://goo.gl/Z2IFB
これでも読んでろ

数学が必要になる処理の多くは既に誰かが作っているから、
情報収集さえ出来れば何も知識いらない

まぁ大学くらいでやるような高度な数学的な処理になると
全然ググってもまともな情報出てこないから
数学できたほうが世界が広がるのは事実

C++にも4,5時間で飽きてしまったぜ

寝る

uyを無視できるブラウザはありますか？

専用ブラウザなら全部無視できる

プライドが高いならNG入れた方がいい

Rubyたん(*´Д`)ﾊｧﾊｧ

>>239
url が 0x じゃなくて 11 になってれば、まだ少しはマシだったのにな。
ついて行けてないのがバレバレ。
コンセプトさんは先送りになったけど知ってる？

お前はC++のコンセプトが分かってなさそうだのう

俺はuyさん結構好きだよ
で、uyさんに質問したいんだけど
俺今C#使ってるんだけどrubyってどんな言語なの？
いい加減c#使いにくいからrubyとやらを試してみたい

島根のlisp方言だよ
もうすぐオタク連中の興味がjsに切り替わるから試さなくて良いよ

ふむ
なんかrubyのページさっきみたけどものすごい使いづらそうなのは俺だけかな？
結局俺はなんの言語がいいのだろう

javaは一回使った事あるけどかなりいい感じだったかなぁ

あれを使い辛そうと思うのはM$畑で遊んでいる奴だけ
officeすらVBAからjsに移行するのでjsで十分だから

>>267
ふむふむ。ありがとう初心者には勉強になるな

見ず知らずの甘酒に好かれても嬉しくない
こんな言語

b = 
class C
  include Module.new {
    def f(x=<<-A) ; return x
      aaa
      A
    end
  }
  self
end.new.f
b = 4.times.with_index(10).map do | i , n |
  b + i.to_s + "#{n}"
end if if true then false end.!
instance_exec 5 do | n |
  p b while (n-=1) > 0
end
a =  C.new.f.gsub(/(aa)/) do |n|  n + "_" + $1 end
p a
/(?<u>\d+)/ =~ "abc 123" 
u.instance_eval do
   p to_i * 5
end

なんとなくわかった　

半分冗談で書いたけど、rubyはなんだろうな
本来の用途は普段の小さな作業の自動化がメインだろうけど
アプリやゲームも作ろうと思えば作れる
each_with_indexなどをはじめとした多数のEnumerableと呼ばれるイテレータメソッドがはいっている
自分で定義も出来る
コードの記述量はやろうと思えばどんどん小さくなると思われる
最強言語
来年の2月に2.0がリリースされる予定

もうちょっと、冗長でありながら、よいコードは出てこないものか。

でっていう


#coding : utf-8
player = "ぐー"
cpu = ["ぐー","ちょき","ぱー"].sample

puts "じゃーんけーん"
# gets
puts "ぽん"
print "player : #{player}"
puts
print "cpu : #{cpu}"
puts

case cpu
when "ぐー"
  print "あいこ"
when "ちょき"
  print "あなたのかち"
when "ぱー"
  print "あなたはしね"
else
  print "しね。"
end

>>273
コードの長さや判り易さ以前に、設計が良くない。
例えば player = "ぱー" にしたら case cpu ... end 内も変更しないといけなくなる。
>>252とは別の人？

% Prolog 分かり易いかどうかは何ともいえないが、冗長なコードの例。

'自然数nの二重階乗を求める'(0,1).
'自然数nの二重階乗を求める'(1,1).
'自然数nの二重階乗を求める'(_m,_x) :-
　　　　'_m が 1 より大きい時、_m - 2 の二重階乗 _x_2 に _m をかけたものが_m の二重階乗 _x となる'(_m,_x).

'_m が 1 より大きい時、_m - 2 の二重階乗 _x_2 に _m をかけたものが_m の二重階乗 _x となる'(_m,_x) :-
　　　　_m > 1,
　　　　_m_2 is _m - 2,
　　　　'自然数nの二重階乗を求める'(_m_2,_x_2),
　　　　_x is _m * _x_2.

>>274
あのさぁ･･･
マジレスしないでいいから･･･

レスがつけられていると思ったらマジレスでびっくりしたよ

抽象化されて短いコードは、
例えば「全体を鶴だと考えてみよう」的な表現は苦手なのではないか。

読み解きにくいけどちゃんと動くコードを書けばクビにならずに会社に居座れるからわざとそうする

自分がいないと回らない状況を作らないと生き残れない会社はいずれ消える

×短いコードはわかりやすい
○無駄に長いコードはわかりにくい
○わかりやすいコードは無駄に長くない

>>277
% これは冗長なコードかな。

迷って鶴か亀に決める(_鶴か亀) :-
　　　　迷って(_文字コード),
　　　　鶴か亀に(_文字コード,_鶴か亀),!.
　
迷って(_文字コード) :-
　　　　repeat,
　　　　_文字コード is random(60000).

鶴か亀に(_文字コード,鶴) :-
　　　　鶴の文字コード(_文字コード).
鶴か亀に(_文字コード,亀) :-
　　　　亀の文字コード(_文字コード).

鶴の文字コード(50401).

亀の文字コード(46517).

>>281
% 決めるを述語にしない理由は？

迷って鶴か亀に決める(_鶴か亀) :-
　　　　迷って(_文字コード),
　　　　鶴か亀に(_文字コード,_鶴か亀),
　　　　決める.

決める :- !.

% 以下略

自分のコードって汚いなぁって思うことが良くある
他の人のコード見ると、MSとかのライブラリィに付いてる
ソースコードみたいになんか綺麗に見える。
どこがって上手く説明できないんだけど、イメージとしては
A4で10ポイントくらいで印刷して１ｍくらい離れてみても
なんか綺麗に見える感じ

でも不思議なことに、そういう綺麗なコードがバグフリーな訳でも無いし
速くコーディングが終わるわけでもない事。
むしろそういう人のコーディングはかえって完成までに時間が掛かる
傾向が強くて、あんまり大事な仕事を任されない不思議。

完璧な英語を話そうとする余り言葉が出なくなっちゃいますよみたいな
ものなのかな？
どうやって話すかよりも、何を話すかの方がよっぽど大事なんだと思うんです。

>>282
その方がいいですね。 ! を「決める」と読むことに魅力を感じて ! の
打ちっ放しにしたのですが、やはり決めるの方がいい。

>>282
待ってください。間違いました。その カット は効かないですね。
鶴や亀の文字コードに複数の選択肢がなかったから、 カット が効いているように
処理系が振る舞ってしまいますが、選択肢を追加したら、複数解を返してくるはずです。
決めるのカットは、決めるの次の節を選択しないのカットですから、
述語 迷って鶴か亀にきめる/1 が目標になったときには、カットとしては働きません。

>>285
そうだった。すみません。>>284は無かったことにしてください。

たびたびすみません。>>282は無かったことにしてください。ですね。

>>283
小さい画面だと余計な改行とか読みにくいので、途中で読むのやめた。

レスがPrologのコードに見えてきた

誰でも思いつくようなバブルソートに
バブルソースって名前をつけた奴って
偉そうだよねｗ

バブルソースｗｗｗ

uyって偉そうだよねwってことか

デザインパターンも
バブルソートと一緒。
誰かがつけた名前にすぎない。

>>289
twitterの最後にピリオドを付ければ全部Prologプログラムっていう
主張はある。ほとんどの場合ピリオド付ける前にシングルクォートで
囲む必要があるだろうけど。

デザパタとか単に慣習をまとめただけだろ
バズワードに近いレベル

誰でも思いつくようなものに名前をつけた奴が偉そうなんじゃなくて
偉い奴がつけた名前が広く使われるんだと思うぞ

>>294
「この時代の政治には、騎士道理想と分かちがたく結びつくひとつの偉大な志があった。」
これをGoogleで検索しても出てこない。「中世の秋」の邦訳だけれど、著作権の制限があり、
全文が載っているサイトはない。こういう部分的な切り取りにはPrologが最有力。

>>295
あるあるネタみたいなもんじゃないかな＞でざぱた

よくあるパターンだから一言で伝わるよう名前決めとこうぜってのがデザパタ

初心者にとってはパターンの紹介
初心者以外にとっては名前の紹介

いやバズワードとまではいってないし
デザインパターンを公表し世に広めるのは意味がある
しかしこれは技術が古くなったら意味がない
使い手がそれに気づけるかどうか
デザインパターン２
デザインパターン３
とこれからも出していく必要がある
最終的にはデザインパターンのみでプログラムが組めれば勝ち
今のところデザインパターンはまだ幼稚なアルゴリズムの発想しか提供してくれず
これ以上はいくらでもあるのが問題

モナドはデザインパターン

>>297
Prologの述語名の部分はデータベース検索に掛かりませんね。
長い述語名を解析して、プログラムがテンポラリに副目標を
生成して実行するには、どうすればいいのですか？

>>302
それ、できません。Prologの組込述語として、現在実行中の述語名、
さらには、現在実行されている副目標を読んでいる目標の関数名(述語名)を、
呼び出せるメタ述語が必要だという声はあります。Prolog上の実行環境に
そのような述語を定義している人もいます。

> Prologの組込述語として、現在実行中の述語名、さらには、現在実行されている
> 副目標を読んでいる目標の関数名(述語名)を、呼び出せるメタ述語

Prologの組込述語として、現在実行中の述語名、さらには、現在実行されている
副目標を呼んでいる目標の関数名(述語名)を、取得できるメタ述語・・・

(読んでいる->呼んでいる 呼び出せる->取得できる) です。

デザインパターンはアルゴリズムと一緒で
特定のコードに名前をつけたものだよ。

バブルソートなど、自分で思いついたものもあるだろう。
だがそれにしたいして、自分勝手に名前をつけても
他人に説明できない。

ああやってこうやってかくかくしかじかして並び替え。
といっても通じない。

デザパタの本にも、デザパタはよくあるコードに名前をつけたものですって
しっかり書いているので、だれでも知ってることなんて言い方は反論にならない。

そしてアルゴリズムがそうであるように、デザパタは
自分で見つけた人にとっては名前であり、
知らない人にとっては、先人の知恵である。

uyは散々デザインパターンは偉そうとか悪とかいってたのに意味を理解すると
ころっと手のひら返すよな自分を持ってないから
恥ずかしい人間だな

明らかに複数人いるけどなuy
ニセモノはドカタくせぇから直ぐ分かる

>>44はuyだなｗ
すぐ分かったｗ

ハズレ。

残像だ

>>44だ。いくらいいレスだったからって自分のものにしようとするなよuy。

小学生とか新しく覚えたことを自慢気に話すよな。たいてい間違って覚えてるけど。

本物はsageって書いてるからすぐに分かるｗ

>>311
きも････

なんでそんなにすぐ出てくんの？

24時間スレ監視してんの？


きっも･･･

めんどくせーからよ、uyコテつけろ
さくっとNGにして差し上げます

デザインパターンとかUMLとかを固定のものとして捉えるなよｗ
よく使うものをまとめたものっていう概念がなぜ理解できないんだろうな暗記大好き君て

よく使うものをまとめたものを提示されても

既にまとめてあって、その次の段階にいってるんですよ


自分でまとめることのできないドカタや概念をまだ知らない初学者に教えるにはいい材料かもしれない

それから暗記をバカにしてはいけない
ほんのちょっと1日1個ずつでも覚えて行けばいいだけ
リファレンスを引く時間を考えたほうがいい

>>314
javaで作ったツールで自動巡回しているのだよ。スマホだから暇なときに見てるだけ。どっかのuyと一緒にしないでくれ。

>>318
広義のデザインパターンである「石の上にも三年」とかの格言でそのレスは表せるな
お前みたいに無駄なレスを書かせないためにもデザインパターンはあるのにまったく理解していない
つまりお前は初心者未満てことだな
天につばを吐く行為が大好きなマゾ野郎だな
お前ダメだ

>>306
×　 uyは自分を持ってないから

無知蒙昧なくせに傲岸不遜なだけ。

先人の知恵に触れるとすぐに平伏し今度は逆に祭り上げて利用するクズ。

＞先人の知恵に触れるとすぐに平伏し今度は逆に祭り上げて利用するクズ。

じゃあもう何も教えてくれなくていいですので


二度と話しかけないでくださいね

>>320
正直どうでもいい
俺はリファレンスを暗記する

お前は暗記しない

それだけの差だろう

まあ、暗記するに越したことはないね
WebやPDF、紙リファレンスを参照するのと、脳内リファレンスを参照
するのとでは、アクセスタイムがまるで違う

> 二度と話しかけないでくださいね

誰も貴様に話しかけてねえよクズ

ところで、
裁判長は法律を記憶してないが法律に基づいた判決を下す。

弁護士は一応法律を暗記するが、実際に裁判をするときには最新の法律を参照しながら組み立てる。

更新の終わった古い規格を使うなら暗記だけでいけるが、
常に更新される最新の規格を使うなら常に参照する必要がある。
リアルタイムに更新されるわけじゃないから覚えなおせばいいわけだが、
なまじ記憶が残ってるとそれが邪魔をする場合がある。

「丸暗記」では理解が不十分だからいつも間違いを起こす。

デザインパターンって、パターン名を丸暗記しても意味ないよなっていうのは俺も思う。

えっ、裁判長と弁護士は別の国家資格だと思っている？

デザインパターンはその概念はともかく
GoF本の23のパターンがうんこすぎた

あんなの有り難がるのJavaドカタだけですよ？

すぐJavaドカタっていうやつJavaにコンプレックスがあるの？

ウェブドカタなんだろう。

OO技術者なら最低限でもGoFの
デザインパターンは理解したほうがいいと思う。

問題：
月曜日から日曜日までの７つのオブジェクトを作成するときに
使用するGoFのデザインパターンは？

これで答えと理由を書いてくれれば
どのくらいGoFのデザインパターンが
理解出来ているか分かると思う。

>>332
デザインパターンはその名の通り
設計（デザイン）のパターン

あなたの問題には、設計を決めるための
情報が全く含まれていない。

なので、答えは出せない。

>>333
ヒントです。
>月曜日から日曜日までの"７つ"のオブジェクトを作成する

>>334
その7つのオブジェクトの性質を言いなさい。

継承関係があるのかどうなのか。
各曜日オブジェクトの関連はどうなのか
どういうコードでオブジェクトを作成したいのか

設計をするための情報がないのであれば
答えが出るわけがないでしょう。

Singletonパターン使えとか言われたらどうしよう
7つって数を強調してるからドキドキする

しかし言うまでもなく、7しか作成できないとは言っていない。
引っ掛けにしか見えんよな。

同じ曜日のオブジェクトを2つ以上作成するかもしれない。
同じ曜日のオブジェクトを2つ作成して相性占いをするかもしれない。

７つといえばドラゴンボール、ドラゴンボールは７つ集めるとシェンロンが出てくる、
シェンロンは願い事を１つかなえることができる、ウーロンの願いはギャルのパンティが欲しいということ、
ギャルのパンティは黒色でいい匂いがするわけであるから例えるならトリュフ、トリュフは三大珍味であり
皮が価値を持つものであるから、デザインパターンでいうとデコレーターパターン。Q.E.D.

>どういうコードでオブジェクトを作成したいのか

たまにいるよな。設計書にコード書いてくるタコ。こいつもその類いか。

最大7つだとして、月曜日を7つ作成していいのか、
質問からは、設計をするための情報が全く読み取れない。

>>336
それも正解、でも理由も書きてほしかった。

>>337
>同じ曜日のオブジェクトを2つ以上作成するかもしれない。
その時に使うデザインパターン？

>>341
いつ、同じ曜日を2つ作成できないようにするとかいたんだい？ｗ

>>341
　 　 　＿＿＿＿
　 　 / ⌒　　⌒　 ＼
　　./( ―） （　●）　 ＼
　 /::⌒（_人＿）⌒::::: 　|　チラッ
　 |　　　 ー　　　　　 　.|
　 ＼ 　　 　　　　　　／

どうですかドカタのコミュニケーション能力の低さは
びっくりしたでしょう？

ドカタは人工無能の一種だと割り切って
直接コードを渡した方が早いですよ

ドカタにコンプレックスでもあんのか？

>>341
uyの言うとおりSingletonパターンはだめだよね
AbstractFactoryあたりで生成させんのがいいんじゃ

>>328
実際に法律を覚えている裁判長などいない。みんなぼけ老人だぞ。

法律とデザインパターンを一緒にするな。

>>342
>いつ、同じ曜日を2つ作成できないようにするとかいたんだい？ｗ
分からないみたいなので、ヒントとして
>その時に使うデザインパターン？
これを書いてみましたが逆に混乱させていむみたいですね。答えは
曜日と言う似たようなオブジェクトならPrototype パターンも使えるかと
自分なら考えます。
（同じ曜日ならなおさらPrototype パターンを考えます）

>>346
Singletonパターンは、一つのオブジェクトしか作らないパターンと考えている人が
多いのですが、本質には作成するオブジェクトの数を制限するパターンなので適用出来ます。


>月曜日から日曜日までの７つのオブジェクトを作成する
これだけの仕様でも二つのデザインパターンの適用を考えることが出来ます。
このようにOO技術者に取ってデザインパターンは必須の知識だと考えます。

>>343
仕様が
>月曜日から日曜日までの７つのオブジェクトを”作成”する
なので生成パターンを考えていましたが、デコレーターパターンもありですね。

>>349
うん、知ってた。

> 同じ曜日のオブジェクトを2つ以上作成するかもしれない。

同じ曜日ならそのオブジェクトはひとつでいい。２つ目は不要。
そのオブジェクトを参照する変数が２つ以上になるだけ。

曜日ごとにオブジェクトを作るっていうのがピンと来ない

>>349
＞本質には作成するオブジェクトの数を制限するパターンなので適用出来ます。

仕様として月〜日オブジェクトが1セットとは明記されていないためSingletonパターンは適用できません。
ありがちな設計ミスです。

＞ > 同じ曜日のオブジェクトを2つ以上作成するかもしれない。
＞ > 同じ曜日のオブジェクトを2つ以上作成するかもしれない。
＞ > 同じ曜日のオブジェクトを2つ以上作成するかもしれない。

いや･･･････････････････
シングルトンって、
複数人で開発する時に変な奴に2個以上存在されたらまずインスタンスを生成されて

そのせいで設計崩壊しないようにするための柵だろ？

コーディングミスをさせない為の柵ではない　と俺は思う

コーディングミスする奴は死ね

いいか、ものほんはこてつけろっつってんだろぼけなすあんぽんたん

×こて
○とり

Ｒｕｂｙたのしすぎわろたｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>351
各曜日オブジェクトのユースケースが提示されていないため
これだけの情報でSingletonパターンを選択することはありえない
そのまま突っ走ればクレーム対象になる可能性があります。

・Aさんの今週のスケジュールに関連した各曜日オブジェクトを変更したら
　Bさんのスケジュールが書き換わりました

たった今おれは悟った
同じことだったと
そして、どのuyが本物だろうと大した問題ではなかったということを

全部本物だよ
uyは病気の一種

# coding : utf-8
class A
  attr_accessor :name
  def initialize name
    @name = name
  end
end
task = %w! 月 火 水 木 金 土 日 !.map { |x| A.new x }
p task


はいはいわろ

>>359
今頃気づいたのかｗ
デフォルトの名無しさん みたいなもんだろ。

>>359
じゃあとりはずすよ

>>363
いやつけといてもらっていい
その方が、本物かの区別はおいといて、ある一人の意見であることがわかる

基本的にこういうのモノは全部同じクラスでいい
最近はどの言語にもlambdaってあるんだろ？

インスタンスを生成してから実装をlambdaで書けば何にでも化ける
lambdaが最強

いいかこれだけはいっておく
名前欄にuyを書いても、トリがなければ違うオブジェクトであると見なす

>>364
俺忙しいしデザパタに興味ない

お前クラス使えないから全部コンストラクタ内で処理を完結させるってってこの間いってただろ

同じuyという値をもつ異なるオブジェクトが増えすぎてるのでGCしてください

Prototypeパターンってただの継承でOKだよね？

interfaceにちかいんでねーの？

>>369
'>>'で参照されてるからコレクトされませんでした

え、だってinterfaceじゃ中身無いじゃん
それってプロトタイプしてなくね？

おいくそuyども
*uyはおなじでいいが、&uyは違うんだから、それをちゃんと明記しろ

>>368
それは俺様の最高設計がそんな感じってだけで、
小さなプログラムや、ライブラリのほうは流石にクラスで書くときもある

コンストラクタで全部処理というのは、
まずコンストラクタがあって、
そこの内部で task_create メソッドを呼んでそこでオブジェクトを作るってだけ
オブジェクトの管理は全て裏方でmy実装されている

コンストラクタで例外飛んだらどうすんだ
リソースリークすんぞ

>>373
同じ機能を複数のクラスで実装することを保証する仕組みがinterface
そのinterfaceとして、自分自身を複製するメソッドを定義しといてやるのが
Prototypeパターンなんじゃないの？

>>377
だとしたら両者違くね？！

> 俺忙しいしデザパタに興味ない

俺忙しいしアルゴリズムに興味ない


こう言ってるのと一緒

すっこみ申しててくださいuyさんは

>>378
両者って何と何？

>>381
interfaceとprototypeだいぶ違くね？

>>382
prototypeパターンはinterfaceの仕組みを使ったクラスの構成方法の一つって
イメージってつもりで書いたんだがちがうの？

てかすまん、寝るｗ

もう一度まとめると
>月曜日から日曜日までの７つのオブジェクトを作成する
この仕様にSingletonパターンを適用した設計にすると
曜日クラス（一つ）から月曜日・火曜日オブジェクトなどが必ず１つだけ作成される。

また、Prototypeパターンを適用すると同じ属性のオブジェクトが
月曜から日曜まで作成できる。

あと、Prototypeパターンを勘違いしている人がいるよだけど
簡単に説明すると、同じ属性（フィールドの値が同じ）オブジェクトを作ること。

だからそれでは>>332のあいまいな問題の要件を満たせてないでしょう？
設計がSingleton使って勝手に制限つけてるどうするんですか？

>月曜日から日曜日までの"７つのオブジェクト"を作成する

それマジレスすると星から作らないとダメ

>>386
ひとつずつ作成するとは一言も書いてないからそこは想定すべきですよ

分りやすいか分り難いかってのは、結局お互いに共通知識があるかどうかで決まるんだよね
原則として、短いコードの方が見通し言いに決まっている
書いたプログラマー本人の頭の中にしかない情報がなければ
読めないのであればそれが読みにくいコードで長いか短いかは関係ないよ
まぁ、通常短いコードは読みにくいといっている奴は、そいつのコミニュケーション能力が低くて
使い物にならないプログラマだったってケースが大半だったりする訳ですがw
単にプロジェクト参加者全員が持っている知識を彼だけか持っていなかったというオチ

デザパタとかもそうなんだよね、デザパタを知らない人とデザパタをを知っている人が混じっていると
非常に非効率な事が起こる、短く書けない。
この時冗長にするのが正解？

まさかね、全員がデザパタを使えるようにして、短く書いても障害にならないようにするのが正しい。
そう思うね

冗長なコード。ひとつできた。

http://nojiriko.asia/prolog/uruutoshi_1.html

>>391
高橋君についてもっと言及するとどうなるの？

> デザパタ
以前のところで思考が違ってますから
知ってるだけじゃダメなんです

分かりやすいコードを書くときの決まり事

1．一つの行に複数の命令文を書くな、馬鹿野郎！
2．条件分岐とその処理や、ループとその処理は3行以上使え！
　　【例】
　　　if(value>=0){
value--;
}
こんなのはかくなよ↓
if(value>=0){value--;}
3．インデントをつけろ！
4．コメントを入れやがれ！

コメントはメンテされずに実装と食い違ってもコンパイルこけないから付けずにわかるプログラム書けよ

394
それは
ただのわかりやすいコードじゃなくて
サルにもわかりやすいコードだけど大丈夫か？

１３４は同意。
２は三項演算子を検討してから分岐にするか考える箇所。

コメントいっさい書くなって人時々見かけるけど、
これだけは理解できないな。
まぁ、難しいコードを書いたことがない人ほどノーコメントって言ってる事が多いようだけど

コメントは入れるべき。
コードの機能が分かっても意図がわからに場合もある。

つーか、メンテしないといけないようなコメントは、コメントになってない気がするんだが...

ちゃんとメンテされる保障があればな

プログラミング能力の個人差を分かっていないの？
俺もコメントはあまり書かない

ちょっと難しい程度のアルゴリズムにコメントは必要ないよ
コメントが必要なのはソースコード量の大きなプログラムで
全体の把握を誰も出来ないだろうって場合は書くしかない

コメントを書くのは、無駄に行数が膨らんでソースを冗長させる行為
それでも見返りがある場合にのみ書く事を許される

>>395
% そうしました。

http://nojiriko.asia/prolog/c143_256.html

// 値を取得する。
getValue();
こういう直訳いらないけど、けっこーある。

あとバージョン管理してるのに、変更箇所をコメントアウトでとっとくやつ邪魔。2012-08-01 xxx 削除とかコメントつきで。

コメントを書かない人の特徴。
・自分は技術力があると自負している。
・人のコードに駄目だしをする。
・バグが多い。

% 十分に冗長であり、コメントを命題(すなわち真)と位置づけている例。

http://nojiriko.asia/prolog/c146_371_4.html

>月曜日から日曜日までの"７つのオブジェクト"を作成する
曜日毎にオブジェクトを作らないで、休日やそのほかの必要になる
性質のオブジェクトを作って、それに合わせたインスタンスを
代入した方が良いのでは？
例えばカレンダープログラムを作ると考えてclass Mondayが必要とは
思わない。

書き方じゃないんだよな、実は

>それに合わせたインスタンスを代入した方が良いのでは？
>例えばカレンダープログラムを作ると考えてclass Mondayが必要とは思わない。
だから、prototypeパターンの適用を考えてみた。

まぁ、プログラムなんてどこまで行っても結局は分かり難いもんなんだよ
あんまり些細なことにとらわれないでがんばって読めよ。
コンパイルが通ってるなら、そのコードは書かれたように動いてるはずだろ
だったらちゃんと読めば何が書かれてるかは分かるはずだ
コメントがあれば確かに助けになることも多いな
でも、コメントに頼らなくちゃいけない時点で、全体のプログラム構造に
何か改善の余地があるのでは？ということを考慮した方が良いかもしれない。
でもまぁ、人間は完璧じゃ無いし、他人の仕事には寛容であって欲しいね

誰がやっても同じ物が出来ると思ってるとか？

そういう方向にもっていく傾向は強いだろ

感想文程度の書き方には無理じゃね

>>395
難解なロジックをコードするなら、コメント無しで記述したらどんなに頑張っても分るコードには成りえない。
難解なロジックを単純に記述する方法はない、それができるなら難解の定義に反する。
それは単純なロジックだったのだ。


まぁなんつーか、LHCとか最先端科学技術の固まりみたいな施設で使われるコードを
銀行業務プログラムの達人に見せても理解できるはず無いよな的な・・・
それでも、そのコードのやりたい事等を解説したコメントがはさんであるなら
達人プログラマであれば何とかするでしょう。
プログラムは手順については語ってくれるが、意図については語らない。
関数名等に埋め込む事である程度の解消もできるが、それを超えるなら混乱を生むだけである。

読み書きできれば、終わりってわけじゃないからね

一ヶ月後の自分なら理解できないな
ってくらいのソース書いたら頑張ってコメント書く。

FWの仕様書にも乗ってない機能を使った処理とか、
ゲームのチェックプログラムで独自の数学的証明式組み込んだりとか、
//※preXXX()直後に呼ぶと吹っ飛ぶ
とか、

ゲームのプログラムは分りやすく作る意味が薄いし気にしても仕方ないように思える
分りやすさは何の為に？と言われた時の効用がほとんど挙げられない

分かり易いか、それとも難いかが焦点のスレなのに、
結局分からせなくてもいいって立場のひとが話題を引っ張ってんじゃ、
まずいのではないか。

ゲームプログラムは作業効率さえよければいい
そしてゲームが完成するまでの間だけでも破綻しなければいい
普通にかけばほとんどが再利用不可能コード

業務系とかはわかりやすさ大事だな。
特に仕様書はソースだと言われた時。

デザインパターンってわかってんのか？
ただの設計思想の一つだ

その話はおわた

> 特に仕様書はソースだと言われた時。
書き方を教えろ
だろ、普通の人は

仕様書はソースとは、なんとおぞましい。。

小手先の書き方知ってるだけじゃ、通用しなくなってきてるってことでしょ
肥大化しすぎて

18000行とかの超謎クラスの解析中に出くわしたコード

if(singleton<hoge>::getInstance(5) == this){
//何かの処理
}

これで何かの処理が始まったときの衝撃
短いとか分かりやすいとかそんなチャチなものじゃ断じて無ぇ
日本の底辺の片鱗を味わったぜ…

ってこれ短いコードじゃないな、スマン

ごめん、実際に処理されるコードの記述で
＞singleton<hoge>::getInstance(5)
のような文って出てくんだっけ？ｗ

あの、ごめん
言っている意味が良く分からない

singletonもどきを作っちゃいました？

おまえ　日本語　学ぶ　半年　ROM　れ

バカでも出来ると思いたい、プログラム？

>>425
singleton==インスタンスがひとつってわけじゃないからそれはいいんじゃないの？
マジックナンバー使ってるのは気になるけどsingletonインスタンスがいくつかあって自分が5番目のインスタンスの時にはなんかするってことでしょ？
forkの戻り値を見て0以外なら親プロセスの処理、0なら子プロセスの処理って分けるパターンの拡張だと思うけど違うん？

::って、実際に実行される文で表れてくるんだっけ？ｗ

>>428
俺が作ったんじゃねぇよぅ
インスタンスが複数作れるシングルトン、とか
謎のコメントが残されていた

あとgetInstance(5)だったり４だったり３だったり
あちこちにそんな処理があったから、
多分何番目に作られたやつはこの処理ってことがやりたかったと思われる

ちなみに確か最大10個作れたと思う
書いたやつは割りと本気で死ねと思う

>>432
日本語で書け

うむ、>>431と被った
多分それで合ってる、代弁ありがとう
これって良くあるやりかたなの？
俺的には衝撃のコードだったんだけど。

で、相変わらず>>432の言いたいことが分からん
ごめんね、読解力無くてごめんね

>>434
つまりだ、if( … )の…の部分に、::が入るような文が来ることがあんのけ？
っていう質問ｗ

ある
staticなメンバ関数を呼ぶときクラス名::メンバ関数名を使う

>>433
デザパタを読みきれんかったんだろうね
（誤読しました？）

433は出来る方なのかな？

>>437
あぁ、とっても初歩的な質問に丁寧にご回答いただき、
どうもありがとうございます。。そゆことか

staticメンバ関数は::で、オブジェクトメンバ関数は.なのか

C++やったことがなく、大変失礼しました

>>435
いや、大丈夫俺も始めてみた
見かけたら読みにくくてぶつぶつ言うと思う
初期設計でこうなったのか継ぎ接ぎ拡張でこうなったのか気になる…

でもインスタンスメソッドでも定義時は::なのよね(´･ω･｀)

>>438
出来る人ならこんな愚痴書いたりしないんだぜ
所詮は底辺土方です

ちなみに解析は他の人にぶん投げました
最後のほう、俺には無理だぜヒャッハーって暴れてたｗ

>>441
基底クラスの関数呼ぶときも
::とか.とか->とかC++って手のかかる子供のようだ…

::を使う必要があるのは仕様上クラス名と同名の変数名が作れるせいだと思う。

>>443
ちょっとまったぁー
クラス名と同名の変数名が作れちゃうとか、そこでだいぶ頭の中が
カオスになってきたんだけど、ひとまず置いといて、
たぶんggrksな内容だと思うけど、->で関数を呼んだりもするの？

>>444
class C{
  void f(){}
  static void g(){}
};
C* C = new C();

C->f();
(*C).f();
C::g();

>>445
ふおぉぉぉぉぉぉーーーーー
ちょっといったんお茶飲んで落ち着いてくる

>>442
逃げ方も上手そうだし
そのうち、なんかあるかもね

>>445
ふぅ。。
とりあえず、沸騰しそうな脳を冷却し、かろうじて思考可能なレベルに
なったと思われるので、足りない脳で解釈してみます

・Cという名前のクラスが宣言されています
・そのCクラスの中には、インスタンスメソッドf()と、クラスメソッドg()が定義されています
・C（クラス）型のポインタ変数Cを定義し、デフォルトコンストラクタで空オブジェクトを生成します
・C型ポインタ変数Cの保持するアドレスをもとに、そのアドレスに格納されているオブジェクトを->で
　参照しf()を呼び出します
・*演算子によって、C型ポインタ変数Cの保持するアドレスにあるオブジェクト自体から、直接的に
　.でf()を呼び出します
・Cというクラス名から、クラスメソッドであるg()を呼び出します

途中で、何言ってっかわからなくなったが、合ってます？？

>>422
引き継いだ時とかに質問した、仕様書はどこですか? に対する答えね。
仕様書はソース。

> C::g();
覚えないほうがいいような、最初は

>>449
そういうことじゃなくて
要求に対する読解力が必要だと

成果物の解説書が必要
なのがよーわからんのよね

ん？あれっ？わかったつもりになってたけどわかってないかも

もしかして、>>445のC::g();って、普通のクラスメソッド呼び出しじゃない？？

>>445のソースで、
C *C = new C();
としたときの
C::g();

と

C C;
としたときの
C::g();
って意味違う？？

書き方覚えたいのなら
上手い人が書いたのをよーくながめることだね

>>451
このアプリに機能追加してくださいと言われたら、仕様書なきゃ何もできないでしょう。ソース読むの?

>>454
はああああああああああああああああああああああああああああああああああああ

出来る奴は先読みしてるんだよ

>>452
意味は同じ　というよりインスタンスとは関係なく

C* a = new C();
C b;

C::g(); // aともbとも無関係
↑
変数名ではなくクラス名

>>456
そうだそうだ、危うくドツボにはまるところだった

まさに、>>443の
＞::を使う必要があるのは仕様上クラス名と同名の変数名が作れるせいだと思う。
の意味がここにあるわけだね

りょーかい！ありがと

しかし、こんなに複雑な言語をコンパイルするC++コンパイラを作った人は
頭おかしいんじゃないかと思うわｗ

実際作れてねーよ

C++やるならそのコンパイラがC++11,0xのどこまでの仕様を満たしてるかをまず調べる必要がある

>>455
何を先読むの?

>>460
さあね

>>459
作れてないのかよｗ
C++やっぱ鬼門だな
クソと言われる所以がようやくおぼろげながらわかってきたぞ

規格のほうが先行してることがあるんだよ
規格ガーとか言ってる方がおかしくねえか

テンプレート可変引数は大至急必要だが、あとはいまのものでなんとかなる。

>>425
特に変なコードには見えなかった
中身みなけりゃ分らないが、シングルトンが配列になっていて順次実行中
5番目の要素を実行する時の特別処理？

分り難いってのは、基本的には共通知識があるかどうかに関わっていて
コードの単純さではないという例のような気がした。

C++はやっぱ拡張しすぎて言語仕様が複雑すぎる
自由度はあるけど

クラス名と変数名じゃ名前空間が違うのから、どの言語でも同じ名前使えると思ってた。規約で防いでるだけで。

phpは変数名の頭に$がつくからと油断してると、
$hoge = new hoge();
$hoge::HOGE;
は、5.3ではokだか、5.2だと
hoge::HOGE;
と書かないと、
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in
と予期せぬダブルコロンと言われる。ラテン語で…。わかるかっ

>>461
お前が何も読めてないのかよw

>>467
ラテン語かよｗ

>>467
ひどすぎわろた

>>392
Prologのプログラムというのは、第一義的には忘備録なのですね。
もちろん、コンピュータ上で動作して、証明できればいいに決まってるけど。

>>468
別に超能力者でもないからね

>>472
お前は出来ないヤツなんだな。

>>473
普通の人は何げに無能自慢したがるからね

こういうスレはLISPのような記号処理言語の人が中心にやるべきだな。
評価らしい評価もできずに、細部にこだわったレスばかりだ。

スレ主にはスレタイで表現できなかった意図もあるだろうから、ある程度の
逸脱は仕方ないと思うけど。

＞スレ主

ニコ厨死ね

コテつけてるけど
よくいる普通の感覚でやってるだけの人な感じだね

この板の連中ってこういう意味不明な発言が大好きみたいだけど

もうちょっと日本語喋ったほうがいい

refrect

>>477
簡単に死ねとか書く人が　意味不明だの日本語だの指摘したところで
そっすねとしか。

ニコ厨死ね

　韓国経済が急激に失速している。一番の原因は、これまで韓国経済を引っ張ってきた原動力である輸出に陰りが見え始めたためだ。

　輸出に次いで内需の鈍化も懸念されている。住宅価格の下落とそれに伴う消費や投資の抑制がみられ、バブル崩壊以降日本が苦しんだ
「日本型長期デフレ」の兆候が現れている、との指摘も少なくない。

■好調に見えたのはヒュンダイやサムスンだけ

　韓国の輸出は、2012年7月の通関ベースで前年同月に比べて8.8％減と大きく減った。マイナス幅は3年ぶりの高い数値だという。

　これまで韓国の輸出をけん引してきた自動車の輸出が頭打ちになったのをはじめ、船舶や石油化学製品、携帯電話など主力製品の輸出が急速に落ち込んだ。

　韓国の輸出額は国内総生産（GDP）対比で50％を超える。「輸出国」といわれる日本でもGDP対比では10％半ばだから、輸出依存度の高さは圧倒的だ。
そのため、輸出の不振は即韓国経済の失速に直結する。

　なかでも韓国経済を支えてきたのが欧州連合（EU）向けの輸出。EUとは自由貿易協定（FTA）を結んでいる。そのEU向けが12年1〜6月期には前年同期に
比べて16.0％も減った。EU諸国の債務危機から発した景気低迷が影響した。

　さらには中国向けも1.2％減った。第一生命経済研究所経済調査部の主任エコノミスト、西?徹氏は、「中国向け輸出の減少はボディブローのように効いています」と話す
。韓国の素材や部品メーカーは中国を介して、間接的にEU向け輸出を増やしてきたからだ。

http://headlines.yahoo.co.jp/hl?a=20120817-00000006-jct-bus_all

個人的には短いコードが好きだけど、短ければいいというもんでもないよな。
Aの中でBを呼ぶのか、A、Bと順番に呼ぶのかとか、
メソッドの依存関係が適当に作られてると、逆に読みにくくなる場合があるね。

自分の技巧度すげーだろ厨の書いた短いコードほど害なものはない

短いほうがいいよ
ながいとバグが

難しく書いて

「俺すげぇぇぇぇぇ」
「馬鹿にはわからないだろな」

をやらなければいいんだよね？

文章と一緒で読者を意識して理解しやすく書けばいい

よくあるケースで、デザインパターン使っただけで「自分の技巧度すげーだろ厨」とか言い出す奴がいて
気絶しそうになる事も多々あり、お前が勉強するのが筋だドアホ

自己顕示欲厨死ねw

>>488
関数型言語使っただけで俺すげー
Ruby使っただけで俺すげー

こちらもよく見かけるｗ

トリつけろっつってんだろ
つけねぇならuyなのんな

なんでお前の願いを
俺が叶えてやらなきゃいかんのｗ

uyとuYが同一かどうか不明だから

端的に言えば、uyと名前欄に入れる意味がないから
名無しで書き込めやカス

鏡ばかり見てるなよ

じゃあ、今までどおり気が向いた時に
uYって書いたりトリップつけたりするわｗｗｗ

クイズ

俺は、誰と同一人物でしょう？

>>497
誰でもないお初のuY

>>498
なぜそう思った？

トリップは同一人物であることが証明できても、
違う人であるという証明はできないのだ。

ちなみに他スレでトリップつけてるアホが居るみたいだが
あれは偽物、俺のなりすましな。
ま、証明はできないが。

>>499
素直に同じトリップをつけてればおまえの発言だって確信持てるから
それで十分事足りる
トリなしuyは、全く意味をなさないので名無しにしろ

なんでこいつこんなに必死なのｗｗｗｗ

だから、お前のお願いを叶えてあげる理由がないんだってばｗｗｗｗ
金でもくれるのか？ｗｗｗｗ
他人はコントロール出来ない。いやならお前が去るしかない。

お前が好きだからに決まってんだろ

uY ◆gXFLM6waxs
uY ◆ZnBI2EKkq.

いまのところ２種確認されている

その二種類が同じ人物であるか
違う人物であるか、

そして、俺はその二人もしくは一人と
同一人物か違うのか、

また、俺がuyと同じ人物であるか
違う人物であるか、
そもそもすべてのuyは同一人物か、

さてどうやって見分ける？

俺は名無しだが、実はどれかのuyと同一人物だって知っているか？

>>506
同じことがわかればそれでいいって何度言えばわかるの？

uyってわざわざ名前をいれるってことは、自分だとわかってほしい訳でしょ？
だったら、統一したトリ入れれば、それの客観性も保てるという、それだけの話

http://logsoku.com/thread/toro.2ch.net/tech/1343290581/544-609

てｓｔ

>>509
それやったらあれは俺じゃないって言い訳できなくなるから嫌なんでしょ

>>512
つまり所詮逃げ口上作っときたいカスってことだな

>>508
何度言えばわかるの？と言われても、
お前に俺が言われたのは初めてだから
どうしようもないよねｗ

そういうやつは名無しで書き込んどけカス

断るｗｗｗ

そもそも人の作ったコードを読む必要があるのか？
OOなら、コードは読まない決めたほうが開発は上手くいくかも。

>>517
バグフィックスや仕様変更があるからなぁ。
それに一年後に適当に自分が書いたソース見てもわからなかったり。
会社としてはシステム保守が人に依存しちゃうから困る。

　　　　 ＿＿_
　　　／|　　　 |
　　　||. |∧_∧|
　　　||. (´･ω･|　うわっ、クソスレに来てしまった。
　　　||oと.　 Ｕ|
　　　||　|（__）Ｊ|
　　　||／￣￣
　　　　 ＿＿_
　　　　|　　 　 |
　　　　|　　 　 |
　　　　|　　　ｏ|
　　　　|　　 　 |
　　　　|　　 　 |
　　　　彡￣￣ ﾊﾟﾀﾝ、

>>518
バグも継承で直せばコードを読む必要もないし
共通クラスライブラリなんかも普通はコードを読まないでしょう。
なぜ自分の書いたコードだけ読む必要があるのか？

>>520
はっきりした。

お前が馬鹿だから、
お前の言うことは間違っている。

はい、結論。

バグが出るたびにサブクラス作って対象メソッド丸ごと書き直しとか斬新だな。
privateメソッドバグってたらどうすんの？コピペか、可視性破壊すんのか。

まっOOが分かっていない人間には
このあたりが理解出来ないんだよな。

Rubyでもモンキーパッチとか言って
こうやってオリジナルを修正しなくても
修正できるぜとか自慢している馬鹿がいるけど、
本来はオリジナルのコードを直すべき。

>>522
全部書き直してもいいし、不具合の出るケースだけ
Adapterパターンで作ってもいい。（そのケースによる）

privateメソッドなんて最初から作成しない。

>>524
>本来はオリジナルのコードを直すべき。
その理由は？

>>1
中級とか関係ねーよ。上級者でもいえる。
perlとかruby厨に対して言えアホ。

>>526
バグを正しく直すというのは、
バグを修正することであって、
バグを別のコードで覆い隠すことではないから

>>525
継承しても、インスタンス生成とか利用しているところ直さなきゃ駄目だし。
それに不具合だと、どこが原因かも読まなきゃわからないし。
そもそも無闇にクラス増やしたくない。

>>528
で、おまえ誰だよ

>>530
お前こそ誰だよ

俺だよ俺

520 ：デフォルトの名無しさん：2012/08/18(土) 17:19:04.62
>>518
バグも継承で直せばコードを読む必要もないし
共通クラスライブラリなんかも普通はコードを読まないでしょう。
なぜ自分の書いたコードだけ読む必要があるのか？





SUGEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!!!!!!!!!!!!!!!!!!!！！！！！！！！！！！！！！！

>>528
主観的な意見で論理的ではないですね。

>>529
>継承しても、インスタンス生成とか利用しているところ直さなきゃ駄目だし。
まっ言語によってはそうかもしれないけど、最近の言語ならメタクラスがあるから修正不要でしょう。
このあたりが理解できていない技術者が以外にも多い。

>それに不具合だと、どこが原因かも読まなきゃわからないし。
必ずしもそうでは無いでしょう。不具合が言語やOS・DBなどの場合
根本的な原因が分からない場合、事象だけで対応するし。
それよりコードに手を入れて他の機能でデグレードが出ないか保障出来る？

>>533
本物きたｗ

ちょっと待て、
トリップつけてる奴は偽物だぞｗ

>>536
じゃあ、そう思われないようにトリつけろよ

>>534
そんな特異なケースで一般化してしまっていいものか。

>>534
外からクラスを書き換えるようなメタメタなパッチが大量にできて
そのうちパッチのパッチのパッチみたいなものもどんどん増えて
パッチつくるコストそのものが無尽蔵にあがっていきそう。

でも、実際にそういう運営でプロジェクト走らせて年月がたったらどうなるかは興味ある。
これでうまいことやってるの？

>>534
修正すべきシステムが最近の言語でかかれていないと、読まなきゃなんだね。
必ずしも必要ないのは同意だけど、逆に読まなきゃいけない場合もあるよね。というか、ドキュメントの不備不整合が多いのでソースが必要なことのが多い。
あと、例外でスタックトレースが出てるとか、ソース読まなきゃどうしようもない不具合。

デグレードが起こるかはテストすればわかるだろう。場合によっては関連潜在バグが発覚する。

基本的なことだけど
A←B←Cという関係でBにバグが見つかったら
その箇所は放置して新規にA←B'←C'にするだけだよ
Cの状態で良いって客もいるから
一度でもリリースしたものは原則として触らない
パッチが存在するとしてもB→B'とC→C'部分だけで
結局最新版のC'が動く状態を維持するだけ
Cの状態で良いって客が仕様を追加してくれとなっても
その時には原因特定できてるからC'←Dとして作るだけ
最近の言語は〜なんて特定機能に依存している手法は
必ず破綻すると断言できる

>>538
そこまで特殊でもないでしょう。

>>539
>パッチつくるコストそのものが無尽蔵にあがっていきそう。
パッチつくるコストも改修するコストもそんなにかわらないとおもうけど。

改修がクラス毎に分かれているから結構扱いやすいよ。

>でも、実際にそういう運営でプロジェクト走らせて年月がたったらどうなるかは興味ある。
>これでうまいことやってるの？
全部じゃないけど（人の作ったクラスだと初めの作りが駄目で、出来ない場合が多い）
それなりに回っている。

>>540
>逆に読まなきゃいけない場合もあるよね。というか、
>ドキュメントの不備不整合が多いのでソースが必要なことのが多い。
絶対読んじゃ駄目ということじゃなく「読む必要がないように作りましょう」という話で
ドキュメントの不備があってもリリース後なんだから詳細設計は分からなくても
機能は分かっているでしょう。

>デグレードが起こるかはテストすればわかるだろう。場合によっては関連潜在バグが発覚する。
でもテストしたプログラムがバグっていることはいくらでもあるでしょう。
テストしたからってデグレードが無い証拠にはならないよと思うけど。

> パッチつくるコストも改修するコストもそんなにかわらないとおもうけど。
外から無理やりパッチ当てる方がコストは掛かる。

当たり前の話で外からパッチを上げるには
パッチを当てられるポイントを探さないといけない。

例えば、関数の中の一行書き換えればいいだけの修正でも
関数全体を置き換えないといけなくなる。
そうやって置き換えた関数が将来正しく動くとは限らない。

>パッチつくるコストも改修するコストも""そんなに""かわらないとおもうけど。
目くじらを立てる反論するところかな？

>>544
それで？

>>542
>「読む必要がないように作りましょう」
できてないから修正必要になるし読むんだよ。

>機能は分かっているでしょう。
機能だけから作るなら、作り直しになるけど、予算出してくれる?

>テストしたからってデグレードが無い証拠にはならないよと思うけど。
だとしたら継承して書き換えた方がデグレード起こりやすいと思うよ。
よって、継承して修正すべきでないね。

uyに匹敵するバカ登場

継承して修正とかどこのOO信者の言葉真に受けたんだ

こうゆうことするやつがいるから継承は嫌われるんだよ

バグはバグでも仕様のバグ修正だろ
プログラムのバグを継承で隠蔽は怖い

。

まぁ、OOならではの方法ではあるが・・・ｗ
たぶん、OOで可能な事を強引に推し進めて、これがOOなんだと間違った解釈をしてしまった人だね。

不具合箇所を見ず、設計書から正しいコードをもう一回起こすとか、不具合と向きあってないな。
こういう人を上に立たせると、多分品質管理の面でボロボロになる。間違いない。

バグを内包したクラスをそのままにして、さらにそれをスーパークラスとして
持っておくとか、正気の沙汰とは思えんな

最後に吾郎さんが悪霊退散してくれるから大丈夫

こんなことされたら怖いから、メソッドにfinalつけてまわらにゃならんやんけ

こんなやり方のどこにメリットがあるんだろう

開放閉鎖原則を変に解釈しちゃったみたいだな

>>554
しかし、それやられたら太刀打ちできないなこの方法じゃｗ

直接はできないだけ

>>558
どーゆーこどだよｗ言語上許されないから無理だろ

>>556
たしかにOCPの「修正に対して閉じている」を変なふうに解釈するとそうなるんだよね。
その勘違い自体はありがちだと思うけど、何の疑問も持たずにそのまま突っ走っちゃったみたいだなぁ

>>545
逆にこっちがコストがかかる根拠がしりたいけどね。

>>546
>できてないから修正必要になるし読むんだよ。
んぅ．．．それは自分の技術力に関係しているとは思わない？

>だとしたら継承して書き換えた方がデグレード起こりやすいと思うよ。
根拠は？　修正箇所だけをクラスにすれば影響は最小限になるけど。

>>548
>継承して修正とかどこのOO信者の言葉真に受けたんだ
どのOOLでも継承はあるけどね。

>>549
>バグはバグでも仕様のバグ修正だろ
そんな決まりいつできたの？主観でしょう。

>>551
>多分品質管理の面でボロボロになる。間違いない。
大丈夫です、上手くやっていますよ。

>>552
>バグを内包したクラスをそのままにして、さらにそれをスーパークラスとして
>持っておくとか、正気の沙汰とは思えんな
バグをそのままにしないための継承して修正なんだがら、わかってる？

それに、標準のクラスライブラリにバグがあるかって修正する？


新しいやり方を、主観的な理由で駄目だと言うのは
技術者的にどうなんだろうね。

>>559
ラップじゃね？

これは新しい池沼

「臭いものに蓋」が新しいやり方？
江戸いろはかるたにすらあるダメなことの代表例ですが

>>561
聞いたことないやり方だったんで質問なんだけど

バグがあるコードをそのまま残しておくってことは、
今後そこのコードはメンテしないものになるわけだから、
何か調査してて引っかかってきても、無視しなきゃいけないと思うんだが、
どういう方法で管理してるの？deprecated1とか何かマークを付けておくとか？

あと、そのメソッドは、もう使用されたくないものなわけだから、
つまり、そのクラスをインスタンス化するなって事になるｔ思うんだけど、
その辺りはどうやって保証していくの？DIコンテナとかを使うことが前提？

ひとつだけ聞きたいな

いま何段階くらいバグ修正の為の継承やってるの？

それから、それは何回までは自分の中で許されると思ってる？

たぶんこの方式とると、人もプロジェクトも成長しない。
動くものが出来上がるだけ。
ユーザーにとってはそれで充分だが、開発者にとってはすごく不幸なことだと思う。

>>561
>>546
>んぅ．．．それは自分の技術力に関係しているとは思わない？
人の作ったものも変更しなきゃだから、読む読まないって話になってる。

>根拠は？　修正箇所だけをクラスにすれば影響は最小限になるけど。

コード修正なら最小単位はコードだけど、継承だと最小単位はメソッドだから。元のメソッドを変更するなら本末転倒。

そんなに優秀なら君の書いたプログラムは修正しなくていいんじゃない?

>>566
２つ聞いてるぞ。

バグの修正に継承？
その継承の使い方は間違ってないか？

継承でパッチをあてて、そのパッチを更に継承でパッチあてて、そのパッチのパッチに更に...
そして、どうしようも無くなってから元のクラスを修正したら...終わりだよね...人生が...

オブジェクト指向がわかってない奴が、
継承を知ると、間違った使い方をするという例だなｗ
で、そういう奴が、オブジェクト指向を叩きだすとｗ

その方法の有効性を論理的に説明してくれないか？
嫌味でいってるのではなく、本当に興味がある。

virtualになってない関数にバグがあっても継承しだす

>>571
それならまだいい。
>>520は間違った使い方に有効性を感じてしまっているから始末が悪いｗ

いやぁ、マジで恐ろしいなぁ
継承による「臭い物には蓋」対処法
バグを先祖代々受け継いでいると、そのうち、本当に収拾つかなくなるぞ
悪いことは言わん、スーパークラスのコードをデバッグするんだ

所詮、プログラマでない素人の考え。
オブジェクト指向を知らない人間が
どう使おうが、子供だと思って笑って見てようｗ

エンカウントしたら､笑ってられない。

俺は 520 じゃないし、対応の仕方がいいか悪いかは評価しないけど
Windows API とか COM とかは 520 みたいな対応の仕方してるよね。

たまにあるな、継承すればオブジェクト指向だとか本気でチームリーダーが思っていて
どう見ても継承が正しいとは思えない局面で継承しろとか、それが正義とばかりに叱咤し始めて
死にそうになりながらコードした経験があるw

錆びたタンカーを新品のペンキで塗りつぶして「大丈夫っす！」って出航
海の真ん中で石油ぶちまけて沈んだ話を思い出した

バグ入りクラスの元クラスの修正が出来ない前提なら
ラッパークラスを作って中に閉じ込めるのが正解だろうな
継承だと使い方次第で修正前の中身がはみ出してしまう

ただ、継承&モンキーパッチ方式を、本来の継承の目的から逸脱してるから以外の理由で
なんで普通しないのかを考えるのはいいと思う

メリット
・ バグったコードは完全な形で残っているので、バグってても問題ない部分はそれをそのまま使えばデグレもおきない
・ ごめん俺じゃこれ以上思い浮かばない

デメリット
・ バグってるコードが、呼べば動作する状態で残される
・ すべてのメソッドについて、継承されることを前提にして組まなければならない
・ パッチ用のサブクラスが際限なく増殖する恐れがある。継承の階層もバグの数だけ増える
・ 普通はしない手法なので、バグ修正ガイドラインを整備し周知し続けないといけない
・ もし1行の修正でもメソッドを丸ごと作り直して、修正箇所がパッチ済みメソッドならさらに新パッチクラスを作らないといけない
・ カプセル化をぶち壊しかねない
・ これをはじめると大本のクラスに手出しできなくなる

個人的には、例に出してる標準ライブラリにモンキーパッチするのは
あくまでチーム外の赤の他人が作って配布してる手出ししづらいものだからであって
自分で作ったものは自分でコントロールできるんだから、バグは消したほうがいいんじゃねと思う

>>578
> 俺は 520 じゃないし、対応の仕方がいいか悪いかは評価しないけど
> Windows API とか COM とかは 520 みたいな対応の仕方してるよね。

してないけど？ 一体何の話してるんだ？

いやぁ、やべーながれだな
げろってみたら、実はそれ普通じゃなかったていう感じのやつがいるな
世の中のどこにそんなコードが使われてるのか知らんが、
命に関わる部分でないことを切に願う

>>565
>何か調査してて引っかかってきても、無視しなきゃいけないと思うんだが、
>どういう方法で管理してるの？deprecated1とか何かマークを付けておくとか？
たしかに不要なコードは悩みどころだけど、クラスが修正毎に階層になっているから
最新から見ていけば修正の意図はわかるよね。

>その辺りはどうやって保証していくの？DIコンテナとかを使うことが前提？
最新のクラスからのみオブジェクトを作ればいいからメタクラスに最新のクラスを設定する。

>>566
>いま何段階くらいバグ修正の為の継承やってるの？
リリースしたものにそんないバグはないでしょう。
確か改修もいれて４階層が一番深かったと思うけど。

>>568
>人の作ったものも変更しなきゃだから、読む読まないって話になってる。
その読む読まないってのがどうなんだろう？

>コード修正なら最小単位はコードだけど、継承だと最小単位はメソッドだから。元のメソッドを変更するなら本末転倒。
"元のメソッドを変更するなら本末転倒"　元のメソッドを変更をしないための継承なんだけど。

>>572
>その方法の有効性を論理的に説明してくれないか？
デグレードを最小限に出来る。既存コードは触らないから新しいプログラムの変更箇所新規クラス部分だけ。
ベース部分（既存）がしっかりしているのは自分には有効だと思える。

>>581
>ラッパークラスを作って中に閉じ込めるのが正解だろうな
それだとクライアント側がどのクラスを使うのか判断しないといけなくなるよね。

> 最新から見ていけば修正の意図はわかるよね。
わかりません。

>>586
>わかりません。
それは残念ですねｗ

コードの中身を見ないって前提だろ。
なんで最新から見ていくんだよｗ

そんなのするぐらいなら、オリジナルのコードを
修正したほうがよい。

バージョン管理をソースコードレベルでやっちゃってる

もしバグっているクラスがあって、修正不可能または、発行元の修正までに掛かる時間が不明の場合どうするか？
COM系ライブラリのように、バグはあってもクラス設計は糞で無く、必要なインターフェイスは揃っている前提として
オレの場合はこんな感じか

バグフィックスをしたクラスに対する要望
１．バグフィックスをしたクラスは、それを利用する関数その他で利用可能であって欲しい
２．バグのあるクラスは、提供元ライブラリはしかたないとしても
　自分たちの作るコード内に利用できないようにブロックしておきたい。
３．バグのあるクラスは、バグフィックスしたクラスのスーパークラスであってはならない
　これは、継承されたクラスが持つべき機能の前提が崩れてオブジェクト指向にならなくなるので
　特にオブジェクトの比較などがある所では、バグがバグを呼んでしまう

590続き
interface IBug バグ付きクラスのインターフェイス
class BugClass : IBug バグ付きクラスは、IBugインターフェイスを持っている

これに対して

interface IBugFixed : IBug バグフィックスしたクラスのインターフェイスは IBug を利用している関数から利用可能
class BugFixedClass : IBugFixed
{
　BugClass innerObject;
　... 以下必要パッチを当てたメソッド類を定義、必要に応じて innerObject を呼び出す
　このクラスは直接生成せずに、関数をオーバーライドして継承したクラスだとしても
　問題はこのクラスの中に閉じ込められる
}

以下、自分たちで使う時は IBugFixed インターフェイスを使って利用すれば
BugClassから利用することは叶わないからBugClassは利用されないだろう
逆に自分たちの作った BugFixedClass は BugClass のインターフェイスに適合するので
提供元ライブラリに対してそのまま使える

grepで影響範囲調べるんだけど不要なクラスあるとそこで引っかかってめちゃ困る
いや、除外すればいいんだけどさそういうのが増えると効率下がる

>>589
ﾄﾘ(´･ω･｀)

今後
短いコードは返上して、ソースプログラムだけでバージョン管理はできるか？
というスレに変更しましょう。

ソースプログラムでバージョン管理しようとする低能^H^Hプロジェクトリーダー様は何とぞ爆発して頂けますようお願いいたしますw
勘弁してください、そんな事をされたら死んでしまいます、ホント

なんか既存コード修正への恐怖心がものすごく伝わってくるんだけど
ユニットテストとか、CVSでいいからバージョン管理システムとか一切使ってないのか？

>>585
>その読む読まないってのがどうなんだろう？
読む読まないの話が不要なら、あなたはこの話に加わる意味がない。

>元のメソッドを変更をしないための継承なんだけど。
だから、元のメソッドを変更しなきゃ、メソッド単位の変更だけで、コード単位の変更はできないでしょ。

この手の継承をする奴は機能の継承ではなくコードの継承をやり腐るから最悪なんだな
機能を見ずに挙動をみてプログラムや設計をするからすぐに身動き取れないコードと化す
にも関わらず俺凄いとか思いこんでいて困る

分かったからおまえら口じゃ無くて手を動かせ

じゃあ、高速タイピングで
２ちゃんねるに書き込みだ！

>>588
>コードの中身を見ないって前提だろ。
そんな前提ないけどね。大丈夫？

>そんなのするぐらいなら、オリジナルのコードを修正したほうがよい。
根拠は？　あくまでも主観だよね。

>>589
>バージョン管理をソースコードレベルでやっちゃってる
んぅ？　継承がソースコードレベルでしか出来ないと思っている？　それとも別の意味？

>>590
>特にオブジェクトの比較などがある所では、バグがバグを呼んでしまう
オブジェクトの比較がなんでバグがバグを呼んでいるんだ？　オブジェクトなんだからアドレス比べるだけ、それが？

>>592
>grepで影響範囲調べるんだけど不要なクラスあるとそこで引っかかってめちゃ困る
それはよくわかる。

>>596
>ユニットテストとか、CVSでいいからバージョン管理システムとか一切使ってないのか？
そんなのでデグレードを起こさない理由になるの？
共通クラスライブラリの修正にはパッチを当てて、自分達が作ったクラスは直接修正する理由は？
それとも共通クラスライブラリも修正しているとか？

>>597
>だから、元のメソッドを変更しなきゃ、メソッド単位の変更だけで、コード単位の変更はできないでしょ。
元のメソッドを変更しない為に継承しているんだけどね。なんか凄い思い込みをしているよね。

> 根拠は？　あくまでも主観だよね。

それをいうなら、まず先に
お前が根拠をいえ。

お前だって主観だろ。

>>601
>元のメソッドを変更しない為に継承しているんだけどね。なんか凄い思い込みをしているよね。

あるメソッドが、２つの結果をもたらします。しかし、１つは仕様変更でになりました。継承修正では2つとも変更が必要ですね?

あるメソッドが、80行のコードからできてました。仕様変更により1行を変更しなければなりません。継承修正では残りの79行も新たに書くのでデグレードの可能性が高いですね?

継承元のバグは、いずれ修正されるからな。

520のスタンスは最初から
「自分のやり方が正しい、反論してるやつはバカ」
ってんだから、何言ったって蛙の面にションベンだろう

少なくとも俺には、他の誰も認めていない自分理論を振りかざしつつ
>まっOOが分かっていない人間には
>このあたりが理解出来ないんだよな。
なんて台詞、恥ずかしくて吐けない
ていうかもう見ているこっちが恥ずかしい

>>520乙

そろそろコボラーの年寄りの臭いがしてきた

えっ、中二くらいだと思ってた。
実用したら使えないのはすぐわかるだろ。

>>602
>お前”だって”主観だろ。
自分が主観だって認めるんだ。

自分が言いたいのはつまり君の技術力なら
それで上手くいくのかもしれないが、他の人は？初心者がやっても同じ結果？っと言うこと。

で、こっちが言っていることはOOPLの機能としての継承だから客観的に見ることが出来るよね。
継承を使う使わないという明確な判断基準があるんだから。

でもソースコードの修正は、どのレベルの人が修正しても同じなの？
良い悪いの前にどうやって評価するの？

>>603
>あるメソッドが、２つの結果をもたらします。しかし、１つは仕様変更でになりました。継承修正では2つとも変更が必要ですね?
必要なし、１つのみ変更。なんで「2つとも変更が必要」と思うのか？

>あるメソッドが、80行のコードからできてました。仕様変更により1行を変更しなければなりません。
>継承修正では残りの79行も新たに書くのでデグレードの可能性が高いですね?
デグレードをなんで行数でくらべるの？　

例えば標準クラスライブラリのクラスがバグていて１行修正すれば直りますと。
ただ標準クラスライブラリのクラスだから何十〜千のプログラム・モジュールで使われています。

問題の起きたプログラムだけ継承して修正したクラスを使うのと、標準クラスを修正するのはどっちが
デグレードが少ないですか？　っと言う感じでデグレードと行数を直接比べられる？

継承はバグに蓋をするものではありません。

以上。

>>609
つまり、それはお前の主観なんだろ？

「それはお前の主観なんだろ？」使えるｗｗｗ

>>609
おまえに賛同する人間が丸一日で一人も出てこない時点で理解できないかな
あと世界規模で使われる標準ライブラリとプロジェクト内だけの共通クラスを一緒にするのも痛いぞ
これ以上恥の上塗りはやめて消えたほうがよくない？

>>1
短く書いてコメント書かないのは
「こんなもの即理解できて当然。分からないの？ぷ」
っていうメッセージなんだよ。

良くも悪くも

>>609
一言で言うとお前みたいなのがプロジェクトチームにいると回りが死ぬ

>>614
それ、良くも悪くもじゃなくて
悪いところしかないじゃないかｗ

上の方をみたら例に挙げているのをみて、それゃ短く書いてるんじゃないだろって1に突っ込みたくなったw

これ関係の話題が大抵荒れるのは>>614みたいな面があるからだろうな

話題としては面白そうなのに中見てみたら、ネタふりの技術レベルが余りに酷かった系は荒れる

じゃネタをふってみると、短くてわかりにくいと感じるのは
お前の頭が悪いだけ。
自分のアホっぷりをコードのせいにすんな、アホ

>>620
具体性のないネタは、ちょっとは反応を得ても続きませんよ。

ほれ突っ込めってやられるなら
ボケが巧けりゃオモシロスレになるんだが発狂するからなw

>>610
>継承はバグに蓋をするものではありません。
根拠は？

>>611
>つまり、それはお前の主観なんだろ？
主張は主観をもとに言うもんだよ。

>>613
>あと世界規模で使われる標準ライブラリとプロジェクト内だけの共通クラスを一緒にするのも痛いぞ
それと、デグレードと行数はどう関係するの？ 書いている意味が分かってないのかな？

>>615
プロジェクトでは結構重要な役割が多いけどね。

>>623
>プロジェクトでは結構重要な役割が多いけどね。
多分そうだろうとしゃべりっぷりからそう思ってた、オレんトコにも居たし
めちゃくちゃ迷惑だから爆発してくれw

>>623
> 根拠は？

継承をバグに蓋をするために使うとする根拠は？

無駄に年重ねてると裸の王様がうまれるといういい例だな

プログラム組んだことないのにリーダーになるとこうなる

>>627
逆だよ、只大量にコードするだけで全然勉強していないエキスパートプログラマの末路

継承をバグ隠しに使うのって、国産のオブジェクト指向本か何かで布教されてるのかな？
520が独自にひらめいて、チームに強制してるならメンバーご愁傷様でいいんだけど
こんな悪法が広まったら、本気で中国人につぶされるぞ

10年もたつとITリテラシが変わるので、再度一から知識リフレッシュをしなければならないんだが
やらずに当時の試行錯誤がさらに力技になった果てに520が生まれるって印象。

>>625
>継承をバグに蓋をするために使うとする根拠は？
んっ、根拠なんてないぞ。　何をいっているだ？

>>631
じゃあ、なんで継承をバグ潰しに
お前は使ってるんだ。
馬鹿じゃないか。

というか誰が何をいっても「それでデグレが減る？」しか帰ってきてない感じだけど
なんでそこまでデグレを恐れてるんだろう。普通は隠蔽工作じゃなくてUTとかで対策するのが普通だと思うんだけど。
このへんがなんかほかの誰ともかみ合ってない感じ

>>629
オブジェクト指向はコード修正は行わずコード追加でバグ対応する
ってネットのどっかに書いてあった
もちろん勘違いしたOO信者のセリフなんだけど
そういうのを読んでまにうけたんじゃないかと思ってる

>>634
昔、活用方法の一つとしてあった頃もあるんだよ、1990年代の話

1990年代は暗黒時代なんやな

>>632
使用できるものを使用するのに根拠がいるのかな？
使用を禁止する方が根拠を示さないと。

>>636
何をやっても目新しい楽しい時代だったよw
今みたいに仮想テーブル使って呼び出すなんて方式がまだ異端で
メールボックスみたいな物準備して、メッセージのやり取りとか普通にあったんだぜw

まあ、ないわー
継承でバグフィックスしちゃってるPGは全てやめろ

520がなにかに似てると思ったらstaticおじさんだった

>>634
オブジェクト指向以外の言語では、ライブラリのバグは自作ライブラリに置き換えるしかなかった
システムのバグはシステム自体を改造して置き換えるしかなかった。
オブジェクト指向はバグのあるクラスだけ、メソッドだけを置き換えるということができ、大いに使える。
そこを否定したらもう原始時代の戻ったほうがいい。

そりゃいつかは根本解決に踏み切るべきだけど、開発効率という尺度では継承バグフィックスは使える。
使わない奴はバカだ。ＰＧやめるか人間やめた方がいい。

>>641
すぐにそれはおかしいだろうという話になったけどな
GNUが活動を活発化し始めた頃でもあって

>>642
もっと合理的な方法使え、継承禁止！

読めません系が何やってもいい方向には向かわないでしょう

>>609
>デグレードをなんで行数でくらべるの？　

経験則と聞いた話。
もし違うなら、問題のあるメソッドだけを上書きしないで、クラス全部書き換えればいいじゃない?

>例えば標準クラスライブラリのクラスがバグていて１行修正すれば直りますと。

あなたの方法は標準のクラスライブラリのような場合に適用されるということですね。しかも、私の知ってる限りのライブラリは直接変更されてる方が多いです。

>問題の起きたプログラムだけ継承して修正したクラスを使うのと、標準クラスを修正するのはどっちが
>デグレードが少ないですか？　っと言う感じでデグレードと行数を直接比べられる？

標準クラスを修正した方がデグレード少ないです。不具合があってもいいユーザは、そのまま前バージョン使うので影響も手間もなし。
継承修正とは継承したクラスにコピペプログラミングするわけですね。

一度、設計手法の勉強をしてオブジェクト指向がなぜ必要かを学ぶか、引退することをお勧めします。

>>642
privateメンバとかvirtual付いてないメンバでやってみろよ

>>646
確かにC++はできねぇな。だから再利用性の低い欠陥言語だと思うよ。
ちなみに俺は１０年前はＣ＋＋マスターで大学で俺以上にＣ＋＋のできる奴は居なかった。
>>643
いやいや合理的でないのはおまえさんだよ。そしてＰＧをいますぐ引退した方がいい。

＞ちなみに俺は１０年前はＣ＋＋マスターで大学で俺以上にＣ＋＋のできる奴は居なかった。

この文に何の意味が

自慢したかったんだから生暖かく見守っとけよぉ

>>647
そして10年後の今腐り果ててしまったんだすね、ご愁傷様w
マジその酷いリテラシなんとかしたほうがいいよ

俺のプロファイルでは

昔はC++に精通してたけど新しいパラダイムについていけなくて切羽詰っている
そのためすぐPGを引退したほうがいいなどの発言をする

ところで標準クラスライブラリのバグってなに？

>>648
まあ確かに意味ないね。大抵は大学入試勉強で忙しくてプログラミング言語習得している奴少ないしなｗｗｗｗ
大学出た後に仕事でどれだけやったかの方が意味あるかもね。
Ｃ＋＋は大分わすれちゃったけど、他の言語はかなりいけますよ。
おまえらよりはな。

小学校で俺より三角乗りが上手い奴は居なかった

１０ねんまえだいがくでおれいじょうにｃ＋＋できるやつはいなかった
てことは30過ぎだよね？30過ぎてまだこんなこといってんの？あたまおかしいんじゃないの？しねば？

>>653
すげぇぇぇぇぇぇぇぇぇぇぇぇ！！！

>>654
すげぇぇぇぇぇぇぇぇぇぇぇぇ！！！

uy言いすぎだぞ

>>655
そう頭おかしいんだよ。人を使う仕事をやれって言われても全部断ってるんで
底辺労働をわざとやっている奇人変人扱いだ。
でも死ぬべきなのはおまえだよ。

死んでほしくても、時々はち合わせるんだよ社会に出ると、しかも年食ってるので割とお偉いさんw
爆発シロと念を込めながらピキピキしながらコーディングだwww

>>655
とり

人を使う仕事ってつまんねーんだよ。コンパイラーは思った通りにやってくれるけど人間は辞めちゃったり裏切るからな。
おまえらの場合は言語がうまく使えないから人を使うしか生きる術は無いんだろ？同情するよ。

簡単だと思いたい（思わせたい）んじゃね、ピンハネ系は

>>645

>だから、元のメソッドを変更しなきゃ、メソッド単位の変更だけで、コード単位の変更はできないでしょ。

>あるメソッドが、２つの結果をもたらします。しかし、１つは仕様変更でになりました。継承修正では2つとも変更が必要ですね?

>あるメソッドが、80行のコードからできてました。仕様変更により1行を変更しなければなりません。
>継承修正では残りの79行も新たに書くのでデグレードの可能性が高いですね?

>継承修正とは継承したクラスにコピペプログラミングするわけですね。

だからね、継承を凄く勘違いしているよね。

継承元のメソッドを呼ぶことができるから
メソッドを一から書く必要はないよ。

つけるの忘れた。
663=520

>>663

＞継承元のメソッドを呼ぶことができるから
＞メソッドを一から書く必要はないよ。

あのぉ、もちろんやらない方法なんだけどさ、かりに継承によってバグフィックスするとして
上書きしたいバグってるスーパーメソッドを呼んでどうすんだよｗ

Aというクラスがあって
その中でBというクラスを使っています。

Bというクラスにバグがあったので
Cとくクラスを作りました。


でもAというクラスは
Bを使っています。

継承でバグを直せませんでした。

はい論破ｗ

だから、標準ライブラリのバグってなんなのさ

>>666
ファクトリーでBを生成してりゃファクトリのBをCに置き換えるだけでバグフィックスできるけどな。
そういう根本的な設計思想も無いんだろうな。ご愁傷様。

Aというクラスのfooメソッドにバグがありました。
Aを継承したBというクラスでfooメソッドをコピペしバグを修正しました。

fooメソッドにはもうひとつバグがありました。
Bというクラスにも当然バグが含まれています。
さらにBを継承したCを作ってバグを修正しました。

fooメソッドにはもうひとつバグがありました。
BにもCにも当然バグが含まれています。
さらにCを継承したDを作ってバグを修正しました。

Aというクラスのfooメソッドが修正されました。
しかし、コピペしたからBとCのバグは修正されません。

デスマ 〜 そして伝説へ

>>668
継承でバグフィックスする設計思想など、こちらからお断りです

>>668
すべてのクラスの生成を全部newから
ファクトリーにしろって話？ｗ

ばーかｗ

> 標準ライブラリのバグ
じゃなくて、うまく使いこなせませんでしたって言いたいんじゃないの？
バグの証明するほうが難しいのにね

>>670
原始時代に(・∀・)ｶｴﾚ!!よ。新しい物を受け入れない奴は化石だ。

>>671
おまえは文系か？なんでΕが∀になる？ファクトリーによる反例を１つ上げただけだお。

古いものだろ

継承でバグ直すって、ようするに関数をコピペするってことだからね。

継承でできることは、スーパークラスのメソッドの
前後にコードを挟みこむことができるが、
メソッドの中にあるコードに、処理を挟むことは出来ない。

バグってのは、メソッドの中にあるコードが問題だから
これを直そうとすると、スーパークラスのメソッド全体を
コピペする（か同等のコードを自作する）しかない。

これがどんなに愚かなことかわかるだろう。

>>674
自分で言っといてあほだなあ全てのクラスにバグがないと証明できない以上∀じゃないと意味ないだろ

>>676
そりゃ全部一人で作って一人で統括して管理してりゃ根本から治すけど、
別人が作ったライブラリだったり、バイナリだったりした場合に
継承バグフィックスは恐ろしく役に立つ。javaに限るけどな。C++はキツイ。

逆かと思っていたw
JavaやC#のような全てヒープになっていて
DIコンテナやサイドバイサイドのような本格的サポートがあるなら継承バグフィックスなんて論外だろうし

>>677
全てのクラスにバグが無いと証明する必要があるなら全部ファクトリーにすりゃいいじゃん。
普通の脳ならそんな非現実的なバカな事は考えないので、
よく変更のある（バグが入りやすい）クラスだけファクトリーにするべき。

それにCOMのバクとかいう話題も出てたし・・・

>>678
お前、部下に直せって指示も出せないの？

>>680
バグが入りやすいと想定してなかったクラスにバグがあったらどうすんだ
そこだけ全newを書き換えてくのか
一貫性ないんだなお前

>>672
そうだよね、標準クラスライブラリにバグがあるって普通は言わないよね
おかしな仕様はたまにあるけど、調べていったら納得する事の方が多いしねぇ

なぜ標準クラスライブラリにバグがあるとか言う奴の話をさらりと受け止められるんだろう？

>>680
よく変更があるのなら、バグが修正されるのも早い
お前の修正継承が、バグの元になるわけだが。

ねえ、こいつ>>673どう思う？

>>682
お前の部下は一生ついてくる忠犬かよ。それにサードパーティのライブラリやら、別会社から提供されるＡＰＩ群だったり色々だろ。
つーか継承バグフィックスもしたことないようなママゴトみたいな小プロジェクトしか
やった事無いやつらなのか？

Aという【他人が作った】クラスがあって
その中でBという【他人が作った】クラスを使っています。

Bという【他人が作った】クラスにバグがあったので
Cというクラスを自分で作りました。


でもAという【他人が作った】クラスは
Bという【他人が作った】クラスを使っています。

継承でバグを直せませんでした。

そこにファクトリーを入れろって言ってるんですか？ｗ

はい論破ｗ

>>687
> お前の部下は一生ついてくる忠犬かよ。

？

部下は一生ついてくる忠犬じゃないですけど、
部下に指示出しますよ？

あなたは部下に指示を出さないということですね？ｗｗｗ

>>684
未熟な時期は自分以外のところに問題があると思うから
ある程度はしかたないことだけど
それをわからせる人が回りにいないことのほうが不幸なのかも

>>689
おまえは文系かよ。なんでΕが∀になるんだ？

>>687
恐らくあなたという存在の話を聞いていたらプロジェクトを崩壊させかねない爆弾だからそういう事態になっているのかとw

>>691
最初に質問を繰り返しますね。

お前、部下に直せって指示も出せないの？

>>693
意味の無い質問に答える必要はないね。
部下に直せって言うレベルの小プロジェクトなんか問題外だ。
外部の会社の提供するＡＰＩ群のバグフィックスが主だろ？
例えばjavaのライブラリってバグあるから継承バグフィックスする事は多い。

部下にバグを直せって言うレベルは
小プロジェクトなんですね！

笑うところですかここはｗｗｗｗ

>>694
デスマーチプロジェクトは規模拡大で解決せよって事ですね、分ります！

だめだ、意味がさっぱり分からん

元ソースがいじれる状態にて、
バグのあるクラスを修正して使うのと、
バグのあるメソッドを上書きしたクラスを使うのと、
ソースが増えて管理がし辛くなる以外にいったい何の差があるの？

え？ でもバグは継承で直せっていうんでしょ？ ﾆﾔﾆﾔ

>>696
なんでバグ直すための継承クラスが０．１％〜１％増えた程度で規模拡大になるんだアホか。
>>698
おまえは文系か？なんで∃が∀になるんだ。文系はＰＧやるなよバグの温床で迷惑だから。

でもバグは継承で直せって部下にいうんでしょ？ ﾆﾔﾆﾔ

>>700
∃が∀になるような文系は文字通りお話にならんね。
で、あなたのご自慢のコミュ力はどの程度ですか？

でもバグは継承で直せって部下にいうんでしょ？ ∃゜∀゜E

∃゜∀゜E ｳﾋｮ　ｳﾋｮ

　　　　∃゜∀゜E 　ｳﾋｮﾋｮﾋｮ

∃゜∀゜E ｳﾋｮ　ｳﾋｮ

継承はスーパークラスのバグを直すためにあるのではありません

以上。

>>704
おまえも∃が∀になるようなアホだな。
だめだなんでこのスレはバカ文系ばっかなんだ？

こいつはもはや人格否定しかできなくなったようだな

継承バグフィックスなんてのは　∃　ある一つ のテクニックに過ぎない。
それがなんで>>704のように∀　全てに一般化されたものとして否定するんだ？
つまりおまえらはアホということですか？

あほということですか？ではなくアホなんだ。これだけは確かなようだ。おまえらはアホだ。

>>707
好きにしろ、そんでもって収拾つかなくなって詰んどけ

とりあえず >>707の集合論の知識と論理的思考力が心配になった

∀(a∈520の脳みそ)[a≡継承！継承！継承！継承！(゜∀゜)]

>>710 集合論じゃない、通常の数学論理記号だ。おまえも文系か。だめだこりゃ。

∃と∀もわからない文系脳ってのは全く話が通じないし議論も噛み合わないから困ったもんだね。
世の中の悪の根源は文系だと思い知らされるわ。

713=韓国人

∃と∀の区別がつかないのも文系脳だし
十分条件(xならばy)がいつのまにか必要十分条件(xならばyかつ　yならばx)に脳内変換されるっていうのも文系脳。

どうやら集合の概念が無くても全称が可能らしい 新しい数学体系だな

まぁ集合論無しでも、∃∀できるだろうけど
この流れ精神分裂の人と話している気分になれるw

ちょっと詳しくない人の為に開設
∃：存在する
∀：全て

と置換して読むと精神分裂の人の言葉が分るよw

>>718
それは文字の成因であって、通常の解釈は
∃：ある一つについて〜がいえる
∀：全てについて〜がいえる
という使い方をするんだよ。中学で習うべきだな。
つうか記号を使ってないだけで中学の数学でも使っている当たり前の概念だけど。

>中学で習うべきだな。
絶対いらねぇwww

「または」、「かつ」、無限を扱わないなら、これだけで十分だよ

じゃあ話を戻そうか。

継承でバグ修正とか言ってる奴は馬鹿

全てについて成り立つという仮定∀xのある一つを否定∃~xすればその仮定は成り立たないことが証明できる。
背理法は中学で習うだろ。いつのまにか∃と∀は使ってんだよ。

>>721
唐突になんだよ。継承バグフィックスもやったことないゴミプログラマですと宣言してるようなもんじゃん。

変な濃度(個数の一般化で各種無限個にも対応できる個数概念)を持つ集合で
それがないと問題発生する時に考えりゃいいんだよ
それまでは a かつ b かつ c ... で上等

昔javaが1.4だったころswingにバグがありましてね。
ボタンがおかしくなるバグを継承バグフィックスしたもんですよ。
（文系脳に断っておくけどこれは一例だからな）

public class BugFixedButton extends JButton {
public BugFixedButton() {
setDefaultCapable(false);
}
}

>>725
いくら俺は正しいんだって叫んでも認められる事は無いから、もうね・・・

>>726
文系どもから認められなくて、村八分になった俺が泣いちゃうとでも思ってるのか？
この田舎物。

これだけは言える
継承によるバグフィックスに対して、一つのテクニックと見なし普通にやってしまう
ソフトウェア設計者とは、絶対に一緒に仕事をしたくない

ここにきて、くだらないお子様みたいな仲間意識を発揮してきたな。
おまえらは自尊心過剰で真理さえも捻じ曲げるのだ。

そんなバカ達に認められない事は光栄なことだｗ

継承の反対は「汎化」というのが原則だからね バグのあるクラスが修正済みクラスを「汎化」したものというのは厳しいし、まあ黒魔術の類であるのは確かだね

つうかおまえらみたいに脳が硬直している奴はもうソフト業界やめろ。
スーパーハード業界へ行けよ。そんな業界無いけどな。

黒魔術にしては思いつきでやってみましたレベル、魔術と呼ぶにはちょっとカッコ悪い
魔術というなら、テンプレートメタプログラミングみたいに参加する者皆驚愕のレベルが欲しいトコロ

オブジェクト指向を確立した人にあやまって欲しい。

おまえらはオブジェクト指向の潜在能力の１％も使ってない事を恥じて欲しい。

時代はMix-inだよ
「クラスに対しての継承」なんてものはもう古いんだよ、俺ほとんどそれはやらないし、Mix-inの効率は理解した
継承関係のようなものが欲しいとしてもやはりそれはmoduleのMix-inで実現すべき
オブジェクトつまりインタンスに対してのMix-inがこれからは主流になる
これの方が拡張性も柔軟性もはるかに高い
出来ない言語は今すぐしぬべき

>>734
バグフィクス指向なあなたは-70%くらい使えてそうですね。
なんで、ooやclassという言葉が使われてるか理解できないんだろうなぁ。

脳が硬直しちゃった奴らはせいぜい浅い世界でうだうだやっててください。
自業自得で勝手にデスマーチやってるのが目に浮かびますわ。

バグを継承で直すってのは、
そのメソッドがメソッドの外部の変数に対して破壊的操作をしてない事が確定してないと無理だし
グローバル変数だけじゃなく、例えばクラスのメンバ変数に対しての破壊的操作もダメだし、
すべてを参照などの引数で渡してる事になる
そしてそのコーディング規則をプロジェクト全体で完全に守っていないといけない
間違ってメソッド外部の変数への、書き込みは行わない ＆ 行ってしまったら検知する
くらいのシステムは作られていますか？
それが出来ているなら有り

>>738
まあ、そこまで管理するなら、スーパークラス直したい

ところで、トリつけてくれてるから>>735と>>738は別人と考えるけどいい？

新しくいいやり方を考え付いたなら、オブジェクト指向でなくて別の名前つけるし。なぜ、オブジェクト指向なんて既存の制約の中でやっているんだ?

バグフィックス指向とか言っちゃっている人もいるけど
新しくもないし普通に誰もがやっている事だろ。
そんな事も知らない人たちの、ここは田舎者の寒村スレなのかもしれないが
まあそんなド田舎者を罵倒している俺も相当アホだが。

とうとうuy参戦か！
オラワクワクしてきたぞ

>>679
C#はスタックにデータもてるよ
構造体変数はスタックに置かれる

>>744
それは関係ないでしょう、ヒープと同様に扱えるならば。
障害になるのは実装方法ではなくインターフェイス
インターフェイスがヒープならそれはプログラムからみて何時でもヒープ。

具体的実装方法ばかり考えていると520のように抽象的な思考ができなくなってしまいますよ

そもそもOSスタックって概念はなんなん
動的伸縮できるならまだしも有限とかアホじゃないの

スタックをハードウェア化すべきと主張したのはダイクストラ
構造化プログラミングに置いてサブルーチン概念を効率よく実装する方法として提案され、それ以降のCPUに採用された。
RISCが搭乗してスタックのような複雑な物を実装するよりも
スタックを実現可能な単純な命令セットを高速に実行した方がパフォーマンスが上げられると判明、
コンパイラにもそれができるだけの技術的・メモリー的余裕ができてからはx86系などのレガシー対応が必要無いCPUからは再び消失した。
それまでは、gotoだけでサブルーチンをプログラマが頑張って作っていた。

さて、gotoだけでオブジェクト指向などという概念も無い時代に繰り返し使うルーチンの実現はかなり高度なプログラミングだが、
無知から始めるなら、このスレッドには何人がサブルーチンを実現できるだけの技量があるか見ものではあるw
あとからならアホとでもバカとでも言えますがねぇ

なんすかOSスタックって
このスレに関係ある話っすか

gotoの戻り番地を呼び出し側で動的に変更すればいい

on goto というbasicの命令を知っているなら、なんとなくでも気づけるかもしれない。
C言語でいうところのswitch文。使っていいのは、ここまで。
gotoの戻り値の変更は不能という条件でよろしく。

>>742
じゃあ、何指向?

アスペ思考

BASICかぁ
VBScriptのClassが面白いなぁ

アスペルガー思考か。なるほど、新しいな。

アスペルガーというよりは精神分裂患者臭いんだけどw

>>750
gotoのみで呼び出し側に戻る方法がわからん。

10 a=0:b=0
20 goto 1000
30 a=1:b=1
40 goto 1000
50 a=0:b=2
60 goto 1000
70 end

1000 if a=0 then print "A"
1010 if a=1 then print "B"
1010 if a=2 then print "C"

2000 if b=0 then 30
2010 if b=1 then 50
2010 if b=2 then 70

2000行目以降の戻り値をプログラムで持たないとダメってことかね？
basicだと、gosub-return命令あったからなあ

>>756
まず、配列をスタック代わりに利用するアルゴリズムを考える
つぎに、配列に戻り先用のヒントになる数値を入れてgotoで処理先にとぶ
サブルーチンから、サブルーチンに飛ぶ場合は、必ずスタック用の配列に戻り先のヒントを入れる
リターンは、スタック用の配列からヒントを取り出し
on s(last) goto 100,200,300
で対応...ただ、面倒臭いねぇ...

まさに配列というのは>>756の変数aであってヒントというのは変数bだから同じだねぇ

おっと、途中で送信押しちまった。

ただサブルーチンからサブルーチンをコールする考慮が抜けていたので
結局、自前でスタック管理しないといけないわけだね。

BASICのgoto縛りの話なのか？
アセンブラなら間接ジャンプ命令ぐらい使えるだろ

>>742
そんなに必死に自己肯定せんでも大丈夫だよ
明らかにあかん方法だから

COBOLのサブルーチン？っぽい命名であるPERFORMなんかを見ていると
当時の混迷ぶりは手に取るように分るね

せっかく整地されたのに当時の混迷を持ち出す奴が520になる訳です
時代変って昔gotoを使ったプログラムが書けない奴は能力不足と言い放っていた人は居た訳ですが
現在も健在です、勘弁してほしい所ですが偉い人にも結構いますw

gotoを絶対使わないといいながら、例外処理をgotoのように使っている人もいるけどね
多重ループからの抜け出し処理でgoto使う人は、まだいそうだな。

コンパイラさんは、そんなことどどこ吹く風でgoto鬼のように生成してるけど
それとこれは別の話でいいよね？

ソースの読みやすさの話をしているのに・・・

>>766
わかってて書きました
ごめんなさい

gotoのような機械的なことはコンパイラさんに任せて、人間は人間にわかりやすい作り方しましょうということでしょう。

>>768
はい、その通りだと思います。

でも周りの技術者?は、ここを通って次はここで…と、やっている。

多重ループからGOTOで抜け出すようなアルゴリズムって
今まで一度も書いたこと無いんだけど
多くの場合において実はそれって別の書き方あるんじゃね？って思う

return

おまえらこれも知らんとか、ニワカもいいとこだろ

for(i=0; i<=10; i++){
　...
　for(j=0; j<=10; i++){
　　...
　　for(k=0; k<=10; i++){
　　　...
　　　if(iku == true)
　　　　technobreak; // 何重ループでも余裕
　　}
　}
}

>>772
あー分かった
俺は再帰でかいてるのかもしれない

添え字集合と処理の分離？
C#などでは割とやりやすい

void MyLoopProcess()
{
　foreach(LoopIndex index in LoopIndex.Enumerate())
　{
　　if(...) break;
　}
}
struct LoopIndex
{
　public int i,j,...;
　public static IEnumerable<LoopIndex> Enumerate()
　{
　　for(int i = 0; i < I ; ++j)
　　　for(int j = 0; j < J ; ++j)
　　　　...
　　　　　yield return new LoopIndex{ i = i , j = j ... }
　}
}

>>761
何が明らかにあかんだよ。おまえは明らかにアカンじゃないか。

>>725みたいにバグを修正して先に進めばいいところを
ＳＵＮやオラクルに問い合わせて返事が来ないから仕事を進められませんとか
他人が悪いからできないと自己肯定しているような愚図であるお前はさっさとこの業界から去れ。

頭を硬直させて他人の足を引っ張ることしか能がないバカがあまりに多いから日本のＩＴはダメなんだな。
そう思えてきたな。

こうして520のプロジェクトは泥沼化していくのでありました、関係者の皆様ご愁傷様・・・

新しい手法は、間違っていたら怖いから試すんだったら趣味でやるべきものだけど
仕事で採用するような余裕があるんなら
それはそれでいいだろ
部外者のお前らが何かいう事じゃない
ありきたりな設計とプログラミングしか考えられない奴はただの社畜

>>777
2chで日本のITを俯瞰出来るとは、2chもメジャーになったな。

新しい手法ではなくて放棄された手法である件(笑)

昔のBASIC以外では、絶対goto文を使わないでと決め付けて今まできたのだが
3重以上の多重ループの場合、最内ループ内の処理で、内側2つ分のループ処理をキャンセルしたい場合
1つはbreakで脱せるが、2つ目はbreakしたことをフラグ等で管理しないといけない、ってケースで悩んだことあるな。
int cnt = 0;
for(int a=0;a<100;a++) {
　boolean flag = false;
　for(int b=0;b<100&&!flag;b++) {
　　for(int c=0;c<100&&!flag;c++) {
　　　if ( isBingo(a,b,c) ) {
　　　　cnt++;
　　　　flag = true;
　　　　break;
　　　}
　　}
　}
}
かならず最初のループに戻る場合なら、これでいいが、1つ外側のループに戻る場合もあるとか、さらにループ階層が多重になった場合、管理できなくならない？
その点、GOTOを使うとすっきりするとは思うけど・・・
int cnt = 0;
for(int a=0;a<100;a++) {
LABEL_JUMP:
　for(int b=0;b<100;b++) {
　　for(int c=0;c<100;c++) {
　　　if ( isBingo(a,b,c) ) {
　　　　cnt++;
　　　　goto LABEL_JUMP;
　　　}
　　}
　}
}

>>782
すっきりしないよ、もう多重ループが深すぎるという段階で
ループネスト数を減らす処置をしないと、余程ループの中身が単純でも無い限りは混沌としてしまう。

>782
こういう制御フローを逆に戻るようなgoto使う奴がいるから
禁止にされるんだろうな

int cnt = 0;
for(int a=0;a<100;a++) {
　for(int b=0;b<100;b++) {
　 　for(int c=0;c<100;c++) {
　 　 　if ( isBingo(a,b,c) ) {
　 　 　 　cnt++;
　 　 　 　goto LABEL_JUMP;
　 　 　}
　 　}
　}
LABEL_JUMP:
}

これなら許せる

別に致命的とは思わないけどな、ただ美しくないし見通しも良好とはいえない

上に巻き戻るgotoとかループの内側に飛び込むgotoとか
コンパイルエラーにすれば良いのにな

>>787
そこまでやるなら素直に、continue / break に拡張施すのが正解だろ

まず、782は上の処理と下の処理は同じじゃないだろ
下の奴は無限ループ発生しそうな典型的なコードに見える

ループ変数の列挙と処理の分離して抽象的に思考するようにすれば、すっきりどうすればいいか分るよ
実行手順を意識し過ぎているんだ
int cnt = 0;
for(int b=0;b<100;b++) {
　for(int c=0;c<100;c++) {
　　for(int a=0;a<100;a++) {
　　　if ( isBingo(a,b,c) ) {
　　　　cnt++;
　　　　break;
　　　}
　　}
　}
}

とかいいながら、ミスってら、脊髄反射せずにもうちょっと考えるべきだったか >>790

bool count_up(int& a, int& b, int& c) {
if (c == 100) {c = 0; b += 1; }
if (b == 100 {b = 0; a += 1;}
return a == 100;
}
的な関数を作って

while (count_up(a, b, c)) {
if (isBingo(a, b, c)) { cnt++; }
}

とかした方がいいんじゃないの

それを言うならこうだろ。
何で素直に書けない奴多いんだ？

int cnt = 0;
for(int a=0;a<100;a++) {
　if(0 == check_value(a))
　 　cnt++;
}

int check_value(int a){
　for(int b=0;b<100;b++) {
　 　for(int c=0;c<100;c++) {
　 　 　if ( isBingo(a,b,c) ) {
　 　 　 　return 0;
　 　 　}
　 　}
　}
return -1;
}

>>792は >>775 スタイルの場当たり版だな

ビンゴって普通5x5=25個の数字があるんだが、お前ら25重ループでも書くつもりなのか？

>>793
ループ変数がこれだけで済んでるならそれで正解だね
話の流れ的にもっと多段になってくると for を回している部分がバラバラになって
メインテナンス性が落ちてくるので考える必要があるかも知れない。

>>796
正解な訳あるかアホ
意味的に全くの誤り
小手先のテクニック

ほんとにruby触ってない奴っていうか
イテレータ使いこなせてない奴って
ソースコードですぐに分かる
for文（）　インクリメント（）　使ってる時点でダメなんだよ

ruby使ってなくても、C++、javaでもIteratorは普通に使うけどね
わざわざ使う必要ないケースもあるわけだ

　 ＿＿＿◎_r‐ﾛﾕ
　└─‐┐ナ┐┌┘　＿　 ヘ＿＿＿＿
　　　　 /./┌┘└┬┘└┼────┘ﾛｺ┌i
　 　　<／　 ￣Ｌ.l￣￣Ｌ.ｌＬ.!　　　　　　 　 ┌┘|
　　　　　　　　　　　　　　　　　　　　　　　　 _,,:-ｰ''"￣￣￣ `ヽ､
　　　　　　　　　　　　　　　　　　　　　　　,r'"　　　　　　　　　　　`ヽ.
　　　　　　　　　　　　　　　　　　　__,,::r'7" ::.　　　　　　　　　　　　　 ヽ＿
　　　　　　　　　　　　　　　__＿__　ﾞl　　|　　::　_ノ　　　　 　ﾍ＿　　 　 ﾞ）　7
　　 　 　　　 　　 　 　　/`ｰ---‐^ヽヽ`l　::　＿_　　　　　　　____　　 ／ノ ）
　　　　　　　　　　　　　l:::　　 　　　lヾミ,l _;;r';;　;;ヽ　　 　　 ん';; ヽ　ﾋ-彡|
　　　　　 　　＿ 　,--､l::::. 　 　　　ﾉ〉"l,_l "|!!;; Ｏ;;!〉;.:)　 f'<!;Ｏ; ;;;!|= ﾞﾚr-{
　　　 ,--､_ノ::　`ｰ'::　　 ､ﾐｰ---‐,,l| ヽ"::::''`ー-‐'´.::;i,　 i　`''-‐' 　　 r';'　}
　　 ,/　　　:::　　　 　 　　 i￣￣　 | ﾞN l　::.　　....:;イ;:'　　l　､　　　　　,l,ﾌ ﾉ|
　 /:::::::. 　 　　　　 l::: 　 　l::::::: 　　l. |_i"ヽ;:...:::／　ﾞ'''=-='''´｀ヽ.　　／i　l"
　l:::::::::::.　　 l::: 　 　!::　 　 |:::::::　　 l　.|　::ﾞl ::´ヽ---‐-‐-‐---/` ,il"..|'". .
　|:::::::::l::::　　l::: 　　 |::　 　 l::::: 　 　 l .{　 ::|　､ ::＼二二二二/,　il 　 |
　|::::::::::l:::. 　 }:::　 　l:::::,r-----　 　 ｌ/ﾄ､　:|.　ﾞl;:　 ::=====:　,i'　,l'　ノﾄ､
　ヽ::::::::l:::: 　 ﾄ:;;;;;;;/-/＿_...........　　/ .|　＼ゝ､ﾞl;:　　　　　　,,/;;,ノ;r'" :|　＼
　　＼::::`ー‐'　　／ l＿＿l;;;;;;;;;;;／'　 |　 　 `''-､`'ー--─'";;-'''"　　 ,| 　 ＼

継承によるコード再利用を改修には使えないと言っている人の意味が分かったよ。
継承によるコード再利用は、元のコードがOOで設計させていないと適用しにくい。
そもそもOOが出来ない人なんだね。

>だから、元のメソッドを変更しなきゃ、メソッド単位の変更だけで、コード単位の変更はできないでしょ。

>あるメソッドが、２つの結果をもたらします。しかし、１つは仕様変更でになりました。継承修正では2つとも変更が必要ですね?

>あるメソッドが、80行のコードからできてました。仕様変更により1行を変更しなければなりません。
>継承修正では残りの79行も新たに書くのでデグレードの可能性が高いですね?

>継承修正とは継承したクラスにコピペプログラミングするわけですね。

だからこんな、わけのわからに事ばかり書くんだ。

>>666
オブジェクトはクラスからしか生成出来ないと思っているよね。

標準ライブラリは出来て、自分の作ったクラスには適用出来ないのはなぜ？
標準ライブラリはOOで正しく設計いるけど、自分の作ったクラスはOOの設計がなっていないと言う事。

結論として
継承による改修は出来ない　（前提条件：OOの設計が出来ていないソースコード）
継承による改修は出来る　　　（前提条件：OOの設計が出来ているソースコード）

ということで、前提条件付きで両方正しいが結論だね。

>だから、元のメソッドを変更しなきゃ、メソッド単位の変更だけで、コード単位の変更はできないでしょ。
>継承修正とは継承したクラスにコピペプログラミングするわけですね。
極端な馬鹿を例にだすなｗ

　　　　　　　　　　　　　　　　　　）
　　　　　　　　　　　　　（
　　　 　　　　　,,　　　　　　　　）　　　　　　）
　　　　 　　　　ﾞﾐ;;;;;,_　　　　　　　　　　　（
　　　　 　　　　　ミ;;;;;;;;､;:..,,.,,,,,
　　　　　　　　　　i;i;i;i; '',',;^′..ヽ
　　　　　　　　　　ﾞゞy､､;:..､）　　｝
　　　　　　　　　　　.¨.､,_,,､_,,r_,ノ′
　　　　 　　　　/;:;":;.:;";i; '',',;;;_~;;;′.ヽ
　　　　　　　　ﾞ{y､､;:...:,:.:.､;:..:,:.:.　._　　､｝
　　　　　　　　".¨ｰ=v ''‐ .:v､,,､_,r_,ノ′
　　　　　　　/;i;i; '',',;;;_~⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′..ヽ
　　　　　　 ﾞ{y､､;:...:,:.:.､;:..:,:.:.　._　　.､）　　､｝
　　　　　　　".¨ｰ=v ''‐ .:v､冫_._ .､,_,,､_,,r_,ノ′
　　　　　　/i;i; '',',;;;_~υ⌒¨;;;;;;;;ヾ.ﾐﾞ´ﾞ^′.ｿ.ヽ
　　　　　　ﾞ{y､､;:..ゞ.:,:.:.､;:.ﾐ.:,:.:.　._υﾟo,,'.､）　　､｝
　　　　　　ヾ,,..;::;;;::,;,::;):;:;:; .:v､冫_._ .､,_,,､_,,r_,ノ′

>>801
標準ライブラリ手出しするような非常事態になったら、第三者はモンキーパッチで一時的に逃げるしかないから仕方なくそうしてるだけで
ベストプラクティスだからやってんじゃないんだよ。ソースに手出しできるライブラリのメンテナならソースを直接いじる。
っていうかやってることは処理を上書きしてるだけだから、OOもクソもないそれこそモンキーな手法。

百歩譲って、オプソ言語の標準ライブラリの開発元が、元のソースのバグを完全放置して
継承パッチだけでしのいでるプロジェクト例を出してみたら、標準ライブラリの例も少しは受け入れられるんじゃね。
お前のプロジェクト以外で

　　　　　＿＿＿＿
　　　 ／∵∴∵∴＼
　　 /∵∴∵∴∵∴＼
　　/∵∴∴,（・）（・）∴|
　　|∵∵／　　 ○　＼|
　　|∵ /　　三　|　三　|　　／￣￣￣￣￣
　　|∵ |　　　＿_|＿_ 　|　＜　馬鹿みたい
　　 ＼|　　　＼＿/　／　　＼＿＿＿＿＿
　 　 　 ＼＿＿＿_／

書き方なんてどうにでもなるんだよ
動かすってことを前提に考えないと

　　　　　　／|＼
　　　　 ／　 |　 ＼
　　　　　　　 |
　　　　　　　 |
　　　　　　　 |
　　　　　　　 |
　　　　 ┏┓　 　 　 　 　 　 　 ┏━┓　 　 　 　 　 ┏┓
　 　 　 ┃┗━┓　 　 ┏┓　 ┗┓┃　 　 　 　 ┏┛┗━┓　 　 　 ┏┓
　 　 　 ┃┏━┛　 ┏┛┗━┓┃┃　 　 　 　 ┗┓┏━┛　 　 ┏┛┗━━━┓
　 　 　 ┃┃　 　 　 ┗┓┏┓┃┗┛　 　 　 　 ┏┛┃┏━┓　 ┗┓┏━━┓┃
　 ┏━┛┗━┓　 ┏┛┃┃┃　 ┏━━┓　 ┃┏┛┗━┛　 ┏┛┃┏━┛┃　 　 ┏━━┓
　 ┃┏┓┏━┛　 ┗━┛┃┃　 ┗━┓┃　 ┃┃┏┓　 　 　 ┗┓┃┃┏┓┗┓　 ┃┏┓┃
　 ┃┗┛┃　 　 　 　 　 ┏┛┃　 　 ┏┛┃　 ┃┃┃┗━┓　 　 ┃┃┃┗┛┏┛　 ┃┗┛┃
　 ┗━━┛　 　 　 　 　 ┗━┛　 　 ┗━┛　 ┗┛┗━━┛　 　 ┗┛┗━━┛　 　 ┗━━┛

動かす気のない奴がやってるのか、最近は？

動かないものを作ると評価が下がりますが
動くものを作っても、動くのは前提条件なので、それだけでは評価はあがりも下がりもしません

>>801
俺は馬鹿なんで良く分からないが...
不用意な継承は望まない結果を生む原因になるので、想定された継承以外での継承はしない方が良いと思うのだが

動いてるけど、思ったっとおりに動かないから
ダメ出しされる理由探しに勤しんでるのかな？

ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。

クラなよ。実で設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。」
ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。
ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。
ｖｖooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。

ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。ｖ
ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。

ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。
ooで設計してるなら、設計に出てこないクラス増やすなよ。実装バグフィクスのために。

同じインターフェースを継承して修正部分以外は元クラスに委譲

これはOK？

そんなもん設計論とかで答えが出るような物だと思うか？

オブジェクトのインターフェースってのはプログラム同士の契約だろ
相手先のオブジェクトが何を求めていて、何をサポートすれば良いかなんて
一般論で分かるはずが無い。
オブジェクトに接続する側はインターフェースの振る舞いは想定するが
実装がどうなっているかなんてことには無関係だ。
正しく動くオブジェクトを作るには、自分だ提供するオブジェクトが
相手が期待する振る舞いを出来るようにするしか無い
元のオブジェクトをラップしてインターフェースを委譲して
大丈夫かどうかは自分たちで確認する以外に無いし
それを設計論で答えを出そうとすることがバグってる。

そんなもん設計論とかで答えが出るような物だと思うか？

オブジェクトのインターフェースってのはプログラム同士の契約だろ
相手先のオブジェクトが何を求めていて、何をサポートすれば良いかなんて
一般論で分かるはずが無い。
オブジェクトに接続する側はインターフェースの振る舞いは想定するが
実装がどうなっているかなんてことには無関係だ。
正しく動くオブジェクトを作るには、自分だ提供するオブジェクトが
相手が期待する振る舞いを出来るようにするしか無い
元のオブジェクトをラップしてインターフェースを委譲して
大丈夫かどうかは自分たちで確認する以外に無いし
それを設計論で答えを出そうとすることがバグってる。

そんなもん設計論とかで答えが出るような物だと思うか？

オブジェクトのインターフェースってのはプログラム同士の契約だろ
相手先のオブジェクトが何を求めていて、何をサポートすれば良いかなんて
一般論で分かるはずが無い。
オブジェクトに接続する側はインターフェースの振る舞いは想定するが
実装がどうなっているかなんてことには無関係だ。
正しく動くオブジェクトを作るには、自分だ提供するオブジェクトが
相手が期待する振る舞いを出来るようにするしか無い
元のオブジェクトをラップしてインターフェースを委譲して
大丈夫かどうかは自分たちで確認する以外に無いし
それを設計論で答えを出そうとすることがバグってる。

そんなもん設計論とかで答えが出るような物だと思うか？

オブジェクトのインターフェースってのはプログラム同士の契約だろ
相手先のオブジェクトが何を求めていて、何をサポートすれば良いかなんて
一般論で分かるはずが無い。
オブジェクトに接続する側はインターフェースの振る舞いは想定するが
実装がどうなっているかなんてことには無関係だ。
正しく動くオブジェクトを作るには、自分だ提供するオブジェクトが
相手が期待する振る舞いを出来るようにするしか無い
元のオブジェクトをラップしてインターフェースを委譲して
大丈夫かどうかは自分たちで確認する以外に無いし
それを設計論で答えを出そうとすることがバグってる。

なんちゃってSEでも目指してる奴がいるとか？

ぶはｗｗｗｗｗｗｗｗｗｗｗ

class A
  def func n
    p "abc" + n
  end
end

a = A.new
p a.func(3) rescue p $!

class B < A
  def func n
    p "abc" + n.to_s
  end
end

b = B.new

b.func(3)



なくはない

なんで発狂してるやつがいるんだ

まともな感覚な人ほど壊れやすいってのもわかってねえのか

rubyはendを何とかしろよ

いや継承でバグ修正でしょ

良いと思うよ

ほとんど利用価値のない継承の
唯一の使いどころかもしれない

>>824
なんとかしてやりましたけど？

A = Class.new {
  define_method :func ,&->n{
    p "abc" + n
  }
}

a = A.new
p a.func(3) rescue p $!

B = Class.new(A) {
  define_method :func ,&->n{
    p "abc" + n.to_s
  }
}

b = B.new

b.func(3)

トリつけないと、偽馬鹿yuと間違えられるぞ

どうでもいい

lambda限定じゃなくて全廃しろよ継承で

でもバグって元々そんなに入れないよね

バグを特定すれば
もしかしたらほんの数文字書き換えるだけで済むものを
再実装やっちゃうのか
バグ特定の方がもしかしたら早くねそれ

継承そのものがいらない概念

おっぱい見せての人の事じゃあないんじゃ無い？
いつも二人か三人組で来る気持ちの悪い人達の事だよ、Iの言う疑心暗鬼な人達は
いつもみかん〜とかメンヘラなんとか〜言ってる奴ら
レイプ魔みたいな人達
レス見るとわかるよ
超気持ち悪い

そりゃソースが触れるんなら直接なおすだろ

>>828
じゃあ、名無しで書き込めカス

でっていう

うわっ、精神分裂しとる、前から片鱗見えてたけどマジモン？

入れ子ループをいてれーたで中傷化してシリアライズすればいい(ｷﾘ

>>804,815,830,832
・直接ソースコードの修正：手続き（手順）に対する修正
・継承による修正：機能に対する修正

手続き（手順）に対する修正と機能に対する修正を
同じレベルと考えるか、別次元と考えるか？、だね。

>>810
>俺は馬鹿なんで良く分からないが...
本当に馬鹿だと思っているなら普通は書かないよね。

>想定された継承以外での継承はしない方が良いと思うのだが
想定は出来ないでしょう。どのようなケースでも対応出来るように設計すると思うけど。

継承修正は一つの次元の修正しかできないのか。使えないな。

で

>>1 というよりスレタイ
短さを求めるなら、関数型でしょう。

なあ
もしかして関数型スレ足りないんじゃないの？
隔離所が足りないから出て来ちゃってる

>>841
きえろ

継承(笑)

520的な間違った継承の使い方だけでなく
真面目に継承使ってるやつって何考えて生きてるのかわからない

それ、どういう効果ねらってんの？

効率？
効率でるかそれ？

>>843
あ、でもやっぱつけてていいや
そっちのほうが名前欄で一括ローカルあぼーんできてよかった

>真面目に継承使ってるやつって何考えて生きてるのかわからない

真面目に「日本語」使ってるやつって何考えて生きてるのかわからない
と同意に聞こえるのは俺だけか？

なんでもそうだが、一般的に「よし」とされている実装方法を守ることは
設計方針がある程度予測できるため、全てのコードを追う必要もなく
引継ぎも苦労しないものなんだよ。

数人以下の小規模プロジェクトでソースの門外不出が約束されている、やっつけ仕事ならアリかもしれんが。

たとえどんなに小規模であろうと
俺が部下なら上司には正しい日本語を使ってもらいたし
俺が上司なら、部下には正しい日本語を教えたいと思うが、
そうではないと考える人もいるんだね。

>>846
え？一般的によしとされてるか？
なんでもかんでも継承って一昔前の話じゃないの？
mix-inあったら普通そっち使うよね
継承されるとコンストラクタが｢無駄に｣複雑になるだけ

コンストラクタにかくべき処理なんてただの初期化
つまりただの代入文がまとまってればいいだけなんだよ
mixinのほうがはるかに単純

>>848
何の言語を使っているか曖昧な状態で、その指摘は何の意味もなさないよ。
まあおそらくruby信仰者なのだろうが。
自分の望む設計ポリシーを持った言語で開発できないケースだってあるという点、注意してね。
「だからjavaはダメなんだよ、俺このプロジェクト絶対やらね」って
まあ、稀にいるけどね、こういう迷惑な人。

またいつの間にか社畜PGの話に推移してるんだけど

>>850
それで関数型だと自然と短く書けるという話はどうなった？

Rubyのmix-inのイメージ
http://www.nicovideo.jp/watch/sm2840707

moduleのない言語はプログラミング言語ですらない
mix-inのない言語はプログラミング言語ですらない

プログラム言語において、便利に使えるものは、大抵の場合、細心の注意を払って利用しないようにするべきものだ

使っていてヤバイと思ったら止めればいいんだが520のようにセンスがないと嵌まっていってしまうのです
基本的にそういう人は抽象的に思考できない人、全体像が見渡せずに今書いているコードにだけ集中し過ぎてしまっているケースが多いね

>>853
moduleなんてあっても使わない。

class module,function module.
ない言語なんてあるのかよ。moduleの意味がわかってないだけか?

>>857
class も function もない言語なら普通にあるだろ。BASICなんかの中には。

>>858
そこらへんは教育用言語だな。
procedure moduleとかあるのはありそうだけど。

moduleいらないとか200年前で知識とまってる奴がいるな

>>860
使うのかい？

rubyの目玉機能だからな
ruby大好き人間は、他を腐すときにmoduleを引き合いに出すものだよ

>>852
ﾜﾛﾀ

継承は捨てられて
ミックスインが主流になってくると思うよ
少なくともプログラムの設計段階で、
いままでクラスの継承関係でツリーを作ってたんだろうけどそれはミックスインで置き換わる

クラス継承を使う場面も一応存在する
クラスでライブラリのクラスの拡張するときは
親クラスのコンストラクタの呼び出しが必要になってくるから継承は必要になる
つうかそれもmix-inでやるようにライブラリが作られていないのが悪いんだけど
いまのところそれ以外の場所での継承は無意味だと思ってる

どんな設計してんだ。

おしえない

やっぱRubyは大した言語じゃないのか

Python使いであればその言葉は許される
それですらなければ負け惜しみにもならないよ

mixinは多重継承に制限つけた機能でしょ？
いまさらどうこう、っていうより、ちゃんと設計できる人ならC++でも
同じ考え方の元で、やっていた話。これから、とか意味わからん。

継承っていう概念はちょっと機能のまとめ方を誤ったんだと思うよ
スーパークラスのメソッドはデフォルトでは呼び出せなくていい
呼び出さずにオーバーライドだけする事の方が多いんだから

設計したことないんだな。

rubyのmix-inを学べばすぐに分かる
プログラムの設計に継承を使うような風習は終わっていくから、覚えておくように

プログラミングは実装ですることだろ。
やっぱり設計したことないんだな。

設計を継承（笑）でやってる時点で設計したことねーようなもんだろうｗえらそうにｗｗｗっうぇｗｗｗｗ

世界に物凄い数の継承（笑）で設計されてしまったプログラムが存在し
やっと間違いに気づき始める奴らが出てきた

俺もC++使ってたころ、色々とクラスの機能は使ったけど継承だけは使わなかったんだよね
プログラミング初めて最初の瞬間から既に継承って概念に違和感持ってた
その違和感はmix-inに触れてよく分かった

継承は複数の役割を1個の機能で実現しようとしちゃってるんだよ
通りで使いたくならないわけだったわ

継承そのものがプログラミングの概念の中にあるバグのようなものだから
これを使ってバグ修正だ　といわれても別に驚かない
バグをバグで潰すなんて素晴らしい
いいぞ　もっとやれ

現実世界は継承で出来ているので、自然と設計も継承になる。

じゃあいいよ
お前は二度とmix-in使うなよ

>>877
今後お前がmix-in使う事あったら負けな？

uYに負けた敗北者だからな？
ちなみに俺はmix-inも使うし、継承も使う

使い分けることが出来るからｗｗｗｗｗｗｗｗｗ

どっちしか使えないのかw

どっちかしか使えないのかw

絶対に今後一生mix-in使うなよ
すべて継承でやれよ

Rubyのmix-inはクラスの多重継承だね。
まつもとゆきひろ氏も多重継承と言っているよね。

なんでメソッドの継承とクラスの継承を比べるのか
不思議だったけどこれでわかったよ。

>>880,881
え？何？もしかして？ｗｗｗｗ
タイプミスですかｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ恥ずかしいｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ



継承ってタイプミスしても大丈夫なんだな

なぜおまえの命令を聞かねばならんのだ。

さっきは継承はバグのようなものだと言ってたのに使うのか。

そもそも、mixinも継承なのに、継承(笑)っておかしくない？
理解してないのバレてない？

>>872
>rubyのmix-inを学べばすぐに分かる
>プログラムの設計に継承を使うような風習は終わっていくから、覚えておくように

>>883
>まつもとゆきひろ氏も多重継承と言っているよね。
www

お前が学べよｗ

この人はmix-inってオモチャがよほど楽しいようだけど。
クラスＡ内に使いたいクラスＢのフィールドを定義するのと同等じゃね？
mix-inって何が凄いの？

性質でなく機能として見てるから、おかしなこと言っちゃうんだよ。

　　　






　





　





　


　

　
　
　
　






　


　


　

　


　


　

　

　




　


　


　


　


　


　


　

　


　


　


　


　


　

　


　


　

　

　

　


　

　


　

　


　





　


　

　



　


　


　


　


　


　

　

　
　
　
　

>>888
委譲でも困る事は少ないよね。
単一継承は不便といえば不便だけど、ミックスインだってトレイトだって不便な多重継承なわけで、どの辺でバランスを取るかだと思う。

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

うああああああああああああああ

　　　　　　　　　　＿＿＿＿__
　　　　　　　　 ／___　　　　　　＼　　　　＿＿___　　　思った通り
　　　　　　　　（ （ 　）) ￣ ＼　 　＼. ／　　　　　＼　　小っさい脳みそだお
　　　　／￣￣￣￣＼　.　　 ＼ 　／　 　 　 　　 　 ＼
　　　/;;::　　　　　　 ::;::::ヽ　 　　／ ノ 　 　 ー　　　　 ＼
　　　￣￣￣￣￣￣￣￣　　　.|　（●） 　（●） 　 　　　|
　　　　　　　　　　　　　　　　　　＼　（__人__）　 　 　　／
　　　　　　　　　　　　　　　　　 　 /　｀ ⌒´　　　　 　 ＼ 　　 　
　　　 　 ／::::::::＼　
　 /:::::::::::::::::::::::::::::::::::::::＼ 〜
　 |:::::::::::::;;;;;;|＿|＿|＿|＿| 〜
　 |;;;;;;;;;;ノ∪ 　＼,) ,,／ ヽ 〜 ←>>1
　 |::（ 6∪ ー─◎─◎　） 〜
　 |ノ　　（∵∴　（ o o）∴） 〜
　 |　∪<　∵∵　　 ３　∵>　ﾑｯｷｰ !!
　　＼　　　　　　　 ⌒　ノ＿＿＿＿＿_
　　　　＼＿＿＿＿_／　| 　 |￣￣＼　＼
＿＿_／　　　　　　＼ 　 | 　 |　　　　|￣￣|
|:::::::/　　＼＿＿＿ 　 ＼| 　 |　　　　|＿＿|
|:::::::|　＼＿＿＿＿|⊃⊂|＿_|＿＿／　／
|:::::/　　　　　　　　|￣￣￣￣|　　〔￣￣〕

　　　　　　　　　　　　　　　　　,! 　＼
　 　 　 　 　　 ,!＼　 　 　 　 　　! 　 　＼　　　 　　こういうスレ、マジでもういいから･･･
　　　　　 　 　i　　＼ 　 　 　 　 l　　 　　 ＼,,..__
　 　 　 　 　 ,i′　　,＼___,,--―l　　　 　　　＼::ﾞ'冖ｰi､、
　　　　 　　 i　　　　　:;＼::::::::::..l　　　 　　　　　　　　　 `'‐､、
　　　　 　 /__,..;:ｒ---―-､,..__.　 　　　,;'il:;}　　 　　　 　　　.;:::｀Ｌ_＿
　　 ,.:ｆ''""ﾞﾞﾞ´　　　 　 　　　 ､￣ヽ,／／　　　　　 　　　　 ...::::::ｌ;;;:;;::::
　 _/　　　　　　　......　　、 　 ＼／／、　　　　　　　　　 　 ::::::::ﾘ;;:::::::::....
／/ 　 　 　 ......:;::::::::::::.　ヽ､＼　ﾞヽ　 ﾍ　 　 ●　　 　 　....:::::::::i';;;;::::::::::::
;;/　　　　::::::::::::;;;;;ﾉ￣＼::　〉　〉ﾞ'、 `ヽ_ﾉ　　　　　　 ......:::::::.;;;:ﾉ:;;;:::::::::::::
/　　　　..::::､__;;ノ;;;｀ヽ_/:　/　/⌒)メ､_ﾉ/　　 　 　 　 .....:::::;;;/;;;:::::;;:::::::::
　　　　　..:::ｲ;;.ヽ::;;;;;;;;;(__ノ　/'"..:::::::::::::/　 ...............:::::::::::;;;,;ノ;;::::::::::::::::
　　　　 :::::::l;;;;;;;;;＼;;;;;;;,.(__ノ;.;:.＼:::::::::/::::::::::::::::::::::::::::;;;;;／;:::::::::::::::::
　　　　::::::::,!::;;;;;;;;;;:.｀ﾞ'-､、　　:::　＼_/::::::::::;;;___,.;-―''"::::::::::::::::::::::::
　 　..::::::::::,!;;;;;:;;;;;:::;;;;;:::;;;;;;｀ﾞ￣'''冖''―--―'";;;;;;;;;:::::::::::::::::::::::::

mix-inはmix-inだからさあ、
すぐ ○○ ＝＝ ××　って当てはめようとするなよ　継　承　と　は　別　概　念　だ


Matzはコミュ障だから、昔から説明を端折る癖がある
ruby使いであればmix-inが多重継承とは違う事くらいすぐにわかる


継承はタイプミスしても大丈夫なんですか？