オブジェクト指向は愚かな考え。

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://hayabusa3.2ch.net/test/read.cgi/news/1393649485/

オブジェクト指向（英語：Object Oriented）とは、主にソフトウェアの設計や開発における考え方のひとつ。
大きな意味でのデザインパターンである。

近年では「オブジェクト指向」というとC++、Java、C#、Ruby、PHPなどの「オブジェクト指向プログラミング言語」、
およびそれらを用いた「オブジェクト指向プログラミング」が世の大半を占めている関係で、まるでイコールのように
言われることも多いが、あくまで物事の考え方であり、プログラミング言語に限ったものではない。

たとえば、最近ではあまり新規では見かけなくなったが、医療分野で使われているDICOM規格をはじめ、UNIXやLinuxで
今なお使われているX Window Systemの仕様書など、1980年代ごろにはオブジェクト指向規格書やオブジェクト指向
仕様書なるものも大量に存在した。
http://monobook.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

やりー糞スレの２GET!

マジレスすると、美少女かどうかは
顔などの属性（プロパティ）できまるものなので

正しい設計は人間クラスがあって
そのインスタンスの一つとして
美少女がある。美少女自体はクラスにならない。

美少女クラスは人間クラスを継承したクラスじゃないの？個人がインスタンスになるべきでは？

>>4
それだと、「排便メソッドを実装した人間クラスから美少女クラスが作れない。 」
事になってしまう。

それはおかしい（矛盾してしまう）ので美少女はクラスではないということ。

>>1
生きたままヒグマに喰われて死ねゴミ

>>5
矛盾するってことは美少女は人間じゃないってことだから
人間を継承できるべきでないってことになるよね。

人間クラスは美少女クラスを継承したものじゃないの？
サブクラスに排便メソッドを作れば解決

> 人間を継承できるべきでないってことになるよね。

うん。だから人間がクラスで
美少女（や普通の人）はインスタンスだって。

ニートやゴスロリ服は
ミックスインやトレイトなんだろうか。

なんだかんだ言ってオブジェクト指向が
ぴったり当てはまってるじゃんｗ

× ニートやゴスロリ服は
○ ニーソ

>>8
ｿﾚﾀﾞ!人間には生物種としての人間と美少女でないものとしての
人間があるわけだな。

class 生物である人間
class 美少女でない人間 extends 生物である人間

class 生物でない人間
class 美少女である人間 extends 生物でない人間

抽象クラスの神に排便インターフェースを実装したのが女。実装しなかったのが美少女。

たいてい「オブジェクト指向は間違い！」みたいなスレって
言ってる奴が間違ってるだけなんだよな（苦笑）

美少女のように歩き、美少女のように振舞うならなら、それは美少女だ。

ここは精神病だろ

美少女のように歩き、美少女のように振舞うならなら、それは詐欺師だ。

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

どんなメソッドもオーバーライドできるから、
排便だろうとゲロだろうと美しく上書きできる。

美少女オブジェクトはage属性によって老婆オブジェクトに変更される
すると、ウンコをしない老婆が出来てしまう。

それを美老婆オブジェクトという

>>1
死ねカス

排便インターフェースを実装した老婆オブジェクトの実体を生成するために、
美少女を老婆のコンストラクタ引数に渡す。このことに疑問を感じる。

■追加要求仕様
美少女を追加せよ。
ただし美少女には排便メソッドが存在してはならない。

現実でも起こりうる。

>>1
クソスレ立てんなボケ

オブジェクト生成時に時空を確認してフラグを渡しとけ。
サザエさん時空ならageは増えない。

>>23
やっぱりお前のオブジェクト指向は間違ってるよｗ

年齢という属性が違うだけでインスタンスは同じなんだから
age属性を変えるだけだろ。

>>27
これって、MVCにするものでしょ。オブジェクトが一定期間生存したらViewを更新。
美少女はController。

>>28
なんで的はずれなレスをするんだ？

mix-inで解決できる問題。

mix-inはできるが
mix-outはできないので
クラスの機能は必要最小限にするべき。

>>29
年齢って属性自体はModelが持つものだろ。
排便インターフェイスはControllerが実装するものじゃないのか？

排便メソッドってのが、オブジェクト指向のセンスの無さの現われだな。
抽象化がぜんぜんできてないじゃないか。

(不要物の)排出メソッドとか破棄メソッドが元にあって、
人間クラスでは排便という振る舞いが実装されていると考えれ。
美少女クラスでの排出方法は、お好みに合わせて実装しなよ。

排便インターフェイスはモデルにあるべき。
つーか人間クラス＝モデル
ビューは人間の見た目。

>>33
排便時のViewの実装には工数が掛かり過ぎるからダメ。

処理をどう表現するかはビューだが
処理自体はモデルだろ。

>>35
お前は何を言っているんだ？

排泄はメソッドではなくイベントである。
つまりイベントを簡潔明瞭に書けない言語は欠陥品である。

ユーザーがコントローラーの排便メソッドを使って、
Modelにウンコしろってメッセージ送るんじゃないのか？

てかMVCで設計することが間違ってるだろ

>>39
排便は外部から施されるものではない

>>38
これだな

イベントが発生したとしても、実際の振る舞いはメソッドに実装されていると思うけど。

ここでまともに書き込みしてるヤツ>>1だろ

ウンコしないよ

>>41
普通は美少女に対してウンコしろってメッセージを送るよね

>>46
送らないでしょ。
美少女オブジェクトの内部で、排泄の必要が発生したら中からメソッド呼ぶだけでしょ。

排便メソッドがプライベートなら議論する必要なくね？

>>48
それ腸閉塞

排便メソッドは人間クラスじゃなくて、生物クラスから継承しているメソッドだしなぁ…

排便メソッドをオーバーライドすればよくね？
違うの？

何？排便メソッドはfriend classにだけ公開するの?

スカトロマニアの親が持つ排便メソッドを外部へ提供せず隠蔽したいんだよね？
AdapterかBridgeパターン使えば隠せるんじゃないの

>>51
単純に考えたら、それで十分。
美少女クラスが排便メソッドを外部に提供したらダメって問題設定じゃないの？

>>51
美少女に排便メソッド自体が存在してはならない。
例外を返そうが、黄金を返そうがダメ。

性的型付けなら、コンパイル時にウンコするかしないか分かる。
安心してウンコしろってメッセージを送ることができる。
動的型付けだとと実行するまでウンコするかしないか分からない
スカトロビッチだと思って美少女にウンコしろってメッセージを送ると後の祭り。

故に、PythonistやRubyistたちは心に闇を抱えている。

排便っていう行為は哺乳類系の全生物に共通だから抽象的でもないし、オーバーライドも不可能

class 生物 {
final public うんこ 排便(){
ブリブリブリ;
return うんこ;
}
}

戻り値をどう扱うかは美少女次第

彼女がウンコしてるとこ見たことないんだけど。

スカトロビッチを美少女に委譲して、外部に排便メソッドを提供しない。
後は、各クラスにヒューマノイドinterfaceを実装すれば完成。

>>59
俺も見たことないわ

美少女クラスの排便メソッドが黄金を返すようにオーバーライドすればいいじゃない

じゃあunkと黄金には継承関係が成り立つな

wikipediaに継承関係が載ってた

人間と服はオブジェクトとしては別物である。人間はオーガニックな生物の一つとしての継承木に入るが、
服は靴、帽子等の、衣料品の継承木または、民族衣装を分類する上での関連図などに入る。だがもし、
人間と服にしか見えない宇宙人の融合体が存在するとしたら、どのように表現すればよいのか？
http://stackoverflow.com/questions/3756807/why-is-the-object-oriented-model-so-occupying-monopolizing

ウンコしないよ

Haskellみたいな関数型だと、美少女って、どう表現するの？

>>58
排便が返り値を必要とするメソッドかプロパティかは重要な問題だよね

>>68
排便はイベントだ

美少女クラスがあって
それを継承したクラスに人間インターフェイスとか二次元インターフェイスとかアイドルインターフェイスを実装するのかな

人間クラスだとしても

排便メソッドだと浣腸っぽい。
排便プロパティだと人工肛門っぽい。
排便イベントが自然。

>>65
着るか着られるかなら、Compositeパターンが使えそう

>>71
排便Eventって、デザパタで言う所のObserverだよね

>>73
イベントや関数ポインタの概念がない言語だとそうだな。

排便イベントだとダメだな。
あくまで排泄イベント。

唾液なのか汗なのか尿なのか便なのかをボカす必要がある。

この問題を的確にこなせない奴が設計見積するからデスマーチが発生する
お客様はムチャを言う

>>67
モナドだよ

クラスベースが取っ付き易いのはわかるんだが
たまにはプロトタイプベースのオブジェクト指向のことも思い出してあげてください

>>77
モナドって状態遷移なのか?その状態遷移って継承できるの?

>>78
汚いオヤジから美少女のインスタンスが作られると、精神的に気持ち悪いから却下

>>80
ワラタ

美少女のウンコを食えない奴らに美少女を語る資格は無い

>>82
クラスの継承図を辿れば、ウンコも黄金カレーも同じものだからな

これモー娘全盛期のネタだろ。
最近の若いヤツには意味わかんないんじゃね。

なっちはウンコしないよ

class 美少女 extends 天使

あ、もう人間じゃないことになったんですね

アイ　オブジェクト　たべたい

>>68
排便したことによる性的刺激が戻り値だろう

>>78
神は{}から自分に似せてアダムを作り、アダムの肋骨からイブを作った。
排便メソッドが何処で継承されたか誰にも分からなかった。

生物学的に考えて進化の過程では失うものがある。
現状の言語でこの点が実装されているものはあるのか？

var Adam = {
haiben : function(){
};

var Eve = {

};

もう250スレにもなるのか

【石川ってウンコするの？確認その２５０】
http://anago.2ch.net/test/read.cgi/ainotane/1271771699/

曾孫受けが「ありえない」と言えるかだよなぁ

>>94
排泄メソッドは隔世遺伝するの？

人間
美少女
ババア

問題は山積みだ

>>95
顧客「美少女はウンコしないよ」
元請「美少女はウンコしないらしいぞ」
下請「美少女はウンコしないことにします」
孫請「…」
派遣「…」

これがデスマーチだ

親クラスの設計が悪いな
実際にうんこしない人間が存在する（人口肛門や食事をしないひとなど）ので
たとえ石川がうんこをしたとしても、この設計は破綻するだろう

オブジェクト指向の弱点は、資産がうんこだと影響範囲が大きくなりすぎることだ

>>97
美少女の排出を観測すれば、波動関数は収束する。

美少女クラスの排出メソッドは、未定義な動作をするのではないか

美少女クラスの排出物はプリンかヨーグルトではないだろうか

前スレ使いきってからにしろハゲ

オブジェクト指向なんて今すぐやめてください
http://toro.2ch.net/test/read.cgi/tech/1384136223/

美少女クラスの排出メソッドは量子的な振る舞いする。
だから、今のOOPLで実装することは不可能。
よく分からないがHaskellのMaybeモナドで実装可能かもしれない。

美少女ってちゃんとウンコしてるのかな？
心配だから今度見てあげなきゃ。

そもそも美少女に排出メソッドは存在してはならない。
消し去る必要がある。

だがババアになったら復活させる必要もある。
さらに人工肛門の実装も考慮しなければならない。

>>105
人工肛門は、ただのStateパターン

人工肛門は割込処理じゃね

人工肛門はセキュリティホールを付いたプログラムの書き換え

双方向反復子は、どのオブジェクトが実装すべきだ

今更気付いたんだけど、CompositeとDecoratorってすごく似てるね
最初に美少女クラスを作って、Decoratorで機能を付加していけばいいのかな

そもそもだな、

美少女も人間だからうんこをする

美少女を人間クラスから継承して作るってのが、そもそも間違えなんじゃね？

うんこクラスを基底にするべき

細胞単位で構築して行って人間を定義するまでどんだけかかるんかな

美少女であるかどうかを判定するクラスを作る

おっぱいをポインタでくれ

>>114
最初に大きな人クラスからはじめて、インクリメンタルに
細部のオブジェクトまで作り込んでいくんじゃないのか？
とはいえ、OSSでのOOPのプロジェクトは大概は失敗してるから、
分析が終わらないようなものは、cで書くのがイイんだろうけども

うんこしない人間がいることを考えると、
うんこするメソッドは人間に組み込まれたものではなくて
任意に着脱可能な関数ポインタ的なアレではないか。

部位によって役割を変えるから細胞ってすごい
それをクラスにするならどんな感じだろうか

特異メソッド?

>>119
全部、ただのS式だよ

オブジェクトと呼ばれるものは連想配列で、
もとを辿れば、それは単なるS式の集合体なんだ。
自己相似的なLispこそ万物を記述する真実の言葉だった。

>>32
読めば読むほどじわじわくる最高にキモいレス

>>32ってMVCの理解は間違ってるの?

>排便メソッドを実装した人間クラスから美少女クラスが作れない。

人間 human = new 人間(〜)
if (human.sex() == Sex.WOMEN && human.age() > 10 && human.age() < 18 && human.face().look() == Look.BEAUTY) {
　print "美少女！"
}

美少女クラスを作ろうってのがそもそも設計ミス

排便メソッドが実装されていないと人間じゃないというなら
美少女は人間じゃないということになる。
要するに美少女を人間ととらえるなら、排便メソッドは人間に定義されるべきではないし、
人間ととらえないなら人間クラスから派生するのが間違い。

カプセル化だけでいい。

継承と多相性は混乱と複雑さをもたらすだけ。たぶん禿が出来心で
持ち込んだだけだろう。

最初はすごいと思ったが、すごいことよりも面倒くささのデメリット
の方が大きい。

テンプレートのせいですっかり呪文コードになった。C++11/14で少しは
改善されつつあるが、本質的には呪文、呪文、呪文、呪文、呪文。

エコエコアザラク

美少女は人間から派生して存在するわけじゃない、人間の一状態でしかない

>>125
human.unko(); // メソッドを隠蔽できない

いや、AbstractFactoryで、スカトロビッチと美少女の実体を作り分けたらいいか

美少女はウンコしないってんなら、それは人間じゃないから、人間の派生クラスではないアイドルや二次元キャラと同様のまったく別のクラスだろ

お前らこういうの好きだよな

外部へAPIを隠蔽したいんだよ

>>1
あちこちのスレにマルチしやがって糞しね

糞しね　・・・　糞して寝ろの略

★マインドコントロールの手法★

・沢山の人が偏った意見を一貫して支持する
　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法


↑マスコミや、カルトのネット工作員がやっていること

TVなどが、偏った思想や考え方に染まっているフリや常識が通じないフリをする人間をよく出演させるのは、
カルトよりキチガイに見える人たちを作ることで批判の矛先をカルトから逸らすことが目的。

リアルでもネットでも、偽装左翼は自分たちの主張に理がないことをわかっているのでまともに議論をしようとしないのが特徴。
..

http://ideone.com/ZUltlB

>>137
それでも美少女はウンコしない

>>137
ブーメラン乙

オーバーライドして SIGILL でも飛ばしとけ

うんこしないよ

するよ

オブジェクト指向では「人間」クラスから排便しない「美少女」クラスが作れないって
それはそもそも"排便しない"は「人間」クラスの設計上ありえない条件なのだから
そう主張してる関数型言語あたりの人が
我々の記法を使うことで「美少女は排便しなくなるのだ！」って主張するオチにして欲しいのではないか。

>>144
人間でも腸閉塞になれば排便しないよ

>>145
そりゃ病気だからunko()メソッドがエラーを返してるだけだ

人間クラスから継承してしまうと、排便以前にトイレの待ち行列に並べてしまうのでまずい。

トイレqueueに並ぶこと自体は問題ない
pop()された後に排便メソッドさえ実行しなければ
排尿メソッドは許可されてるんだろ？

人間がみんなうんこするっていうのは間違ってる。
過去から現在までの人間には当てはまるが
現在から未来の人間に当てはまるかはわからないからな。

つまるところ「人間の定義とは」という話になるだけ
両足がなくて歩くメソッドが使えなくても人間だ
腸に障害があって排便メソッドが使えなくても人間だ

じゃあ人間が共通して備えてる性質って何だ
ホモサピエンスのDNAを持っていることくらいしか絶対共通の定義はできない

そこで登場するのがプロトタイプベースのオブジェクト指向だ
人間という静的なクラスは存在しない
「ホモサピエンスのDNAを持ち排便機能を持ったオブジェクト」や
「排便機能を持たない美少女オブジェクト」などを自由に生成し、ダックタイピングでそれらを識別し扱うことができる

もちろんプロトタイプベースのオブジェクト指向の欠点もあるので決して銀の弾丸ではない

生物クラス
　食事メソッド
　排便メソッド
人間クラス : 生物クラス
男クラス : 人間クラス
女クラス : 人間クラス
　美プロパティ

専用のメソッドが必要なときだけクラスを用意する感じかな
なら男・女はプロパティか

なるほど。プロトタイプベースが現実のオブジェクトにしっくりくるな。

男女は機能の違いが有るからメソッドかと

結局は共通点によるグループ分けなんだよな
全てがオリジナルって考えたらオブジェクト指向は成り立たない
右手と左手は、同じ"手"から派生させて良いものか

Javascript方式かな？
全てがobjectクラスからの派生で、プロトタイプベースで独自機能を持つような感じで。

万能細胞の原理を取り入れるならobjectクラスにほぼすべてが実装されていて、文科の際にメソッドやプロパティが適宜public/privateが切り替わる。
分化先では機能を実装しない。

うーんそう考えると細胞ってすげえな

staticおじさん元気かなぁw

staticとはいったい・・・うごごご！

排便メソッドをオーバーライドしてマシュマロを排出する様にすれば

publicなプロパティを一時的にprivateにする必要がある。
あくまでも一時的に。

オブジェクト指向の概念を現実に適用しようとするからこうなるだけ

うんこしない美少女が現実？

排便メソッドはあるけどprivateになってて外からは見えない

パパラッチオブジェクトでラップするとprivateなメソッドにもアクセスできるようになります。

馬鹿ほど万能解を求める
解法を二つも覚えていられないから

>>164
この世にprivateなど存在しない。

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れないとは、
オブジェクト指向の設計の難しさを表現したものである。

■概要 [編集]
2001年に始まり今なお続く「石川梨華ってウンコするの？」という大論争をオブジェクト指向で設計すると
どうなるのかという問題である。 下品な例だが納期が迫った時期に顧客の要望による大幅な仕様変更、
それに耐えうる設計見積を作れるか、という非常に根の深い問題である。 ベストな答えはまだ得られていない。

■主な見解 [編集]
排便メソッドをオーバーライド [編集]
排便メソッドをオーバーライドし黄金やnullを返すようにするという意見である。
美少女には排便自体が存在してはならない、という意見があり根本的な解決には至っていない。

仕様が間違ってる [編集]
美少女でもウンコはするものであり、そもそも仕様が間違ってるという意見である。顧客との直取引であれば
フルスクラッチからの作り直しになると説明し、高額な見積を提示することで回避すればいいと言う。
だが、顧客の要求仕様は絶対であり、ましてや孫請けの派遣社員、いわゆるITドカタに拒否する権限などない
という反論意見がある。彼らは黒いモノも白いと言わなければならない。
　顧客「美少女はウンコしないよ」
　元請「美少女はウンコしないらしいぞ」
　下請「美少女はウンコしないことにします」
　孫請「…」
　派遣「」
これがデスマーチだ。
https://twitter.com/ProgrammingMono/status/440035904996921344>>163

オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れないとは、
オブジェクト指向の設計の難しさを表現したものである。

■概要 [編集]
2001年に始まり今なお続く「石川梨華ってウンコするの？」という大論争をオブジェクト指向で設計すると
どうなるのかという問題である。 下品な例だが納期が迫った時期に顧客の要望による大幅な仕様変更、
それに耐えうる設計見積を作れるか、という非常に根の深い問題である。 ベストな答えはまだ得られていない。

■主な見解 [編集]
排便メソッドをオーバーライド [編集]
排便メソッドをオーバーライドし黄金やnullを返すようにするという意見である。
美少女には排便自体が存在してはならない、という意見があり根本的な解決には至っていない。

仕様が間違ってる [編集]
美少女でもウンコはするものであり、そもそも仕様が間違ってるという意見である。顧客との直取引であれば
フルスクラッチからの作り直しになると説明し、高額な見積を提示することで回避すればいいと言う。
だが、顧客の要求仕様は絶対であり、ましてや孫請けの派遣社員、いわゆるITドカタに拒否する権限などない
という反論意見がある。彼らは黒いモノも白いと言わなければならない。
　顧客「美少女はウンコしないよ」
　元請「美少女はウンコしないらしいぞ」
　下請「美少女はウンコしないことにします」
　孫請「…」
　派遣「」
これがデスマーチだ。
https://twitter.com/ProgrammingMono/status/440035904996921344

privateであってもNSAには隠せない。

まるでObjective-Cが正しいかのような口ぶりだな

考えよう。
答えは必ずある。

メソッドのようなプル型ではなく、便意ってプッシュ配信なんだよなぁ

非同期的でもある

適切に処理しなければオーバーフローするな

バッファがいっぱいです

>>174
ワラタｗ

オブジェクト指向が愚かなんじゃなくて
設計する奴が愚かなんだろ

>>178
だがここまで誰一人として設計出来ていない。
まともに設計出来る人間が日本に何人いるのかという問題だな。

この問題は建築士と同様に設計行為を国家資格にして構造設計書に法規制を行う必要性を示している。

【受注系SEとの結婚は苦痛すぎ】
低生涯収入
高稼働労働
人格障害者

しっくりこないんです

あそこの具合が

【受注系SEとの結婚は苦痛すぎ】
低生涯収入
高稼働労働
人格障害者
排便メソッドを実装した人間クラスから美少女クラスを設計できない

SEのケツからひりだされた苦悩がこのスレなんだろ

だから人間クラスに排便メソッドって時点で、設計がだめなんだよ。
ちゃんと抽象化していれば、不要物を捨てるメソッドなんだから、
人間はそれを排便でしてるだけで、美少女クラスにまで排便を引きずることも無いんだよ。

低収入だから

人間と美少女の関係はどうなるんだよ

delete bishoujo.haiben;

かつてヒトの祖先は4原色（赤緑青黄）の視覚を持っていた。
だが進化の過程でヒトは染色体をひとつ失い3原色（赤緑青）の視覚となった。
※現在でも4原色を持つヒトは少なからず存在している。

オブジェクト指向はまだまだ発展途上であり改良の余地があるのではなかろうか？

新しい言語を造ろうではないか

精子と卵子から派生する言語か

言語というか新しいパラダイムだろ
ついでだから今トレンドの非同期プログラミングと相性最悪な例外機構もどうにかしてほしい
期待してるぞ頼んだぞ

>>190
多重継承！
多重継承！

キメラが生まれそうです

おまえらはこういうの好きだよなぁ

>>190
継承しても、どちらの特性も備えていない
卵子に精子を委譲し、卵子が別のクラスを生成したと考えるべき

その辺のFactoryの解説を誰か頼む

その辺のクラスだって、create()メソッドぐらい備えているだろ

哺乳動物というクラスを継承していて
このクラスは新しいインスタンスを生成するのに
二つのクラスからプロパティをランダムでミックスして作る
メソッドは後から実装するが多くの場合直接の親クラスが
教育によってインプリメントを行う。
学習過程が終了すると成績により実際の現場に振り分けられ
動作しながら動的に教育が続けられて専門化されてゆく。

十分有用なら同じく有用なペアクラスが配偶され
そのペアから新しいインスタンスが生成される。
無能ならライフサイクルを終えたらただ廃棄される。それだけ

循環参照したら長生きできるな

なにものもガベージコレクターの手を逃れることはまかりならん

美少女の大腸は返り値を0にすればいいんじゃね？
カスも残らず全吸収

なんだこれ

以前嫌儲の同じスレが伸びてたからって
アフィカスがマルチでむりくり盛り上げてんのか？

そもそもニュー速のスレを継承してるみたいだが…

正方形クラスが四角形クラスを継承すべきでないのと同じように、ここで言うような美少女クラスは
人間クラスを継承すべきではない

これオブジェクト指向がというよりクラスベースが硬すぎるって話じゃないの？
プロトタイプベースなら好きなように継承できるからJSとかやればいいと思うよ

オブジェクト指向とは何だったのか

>>192
単一継承できる時点でダメじゃね？
常に2つじゃないと

俺のクラスは一子相伝

そもそも美少女にケツの穴は存在するのか？

肛門は重要だ

「スパコンで魔方陣」を解いた１６歳
http://uni.2ch.net/test/read.cgi/newsplus/1393749755/
２５マスの２億７５００万を超える全パターン算出に成功

俺が初めて作ったプログラムは数独の自動回答だったよ
PC98でも5分くらいで終わった
最近の子供は軟弱だな

そもそも普通の人間と美少女は別物なのだから、人間クラスから継承しようとするのは設計ミス。

>>212
二十歳過ぎたらタダの人の典型だね☆

オブジェクト指向の理解に、このスレは役に立つ

PC98だともう30代だろ
ただのオッサン

プログラム板では20代以下の方が少数派の若僧だと思う

排便メソッドをオーバーライドして生クリームを排出する様にすると猫ひろしになる

美少女クラスから派生された舘ひろしの排便メソッドは何を返すの?
排便メソッドの戻り値は、ウンコも生クリームも同じ親クラスを継承しているの？

少女は年齢と性別でいいとして美とは何だ？仕様が書不足している

bi-shojo{sex=female,age=45}

>>220
ここでいう美少女の美は、形容詞じゃなくて美少女でひとつの名詞だからいいんだよ

美少女は天使だろ

人間クラスじゃなく天使クラスを継承だよ
人間アダプタクラスに入っているだけ

>>223
コードでおｋ

これからはテンプレートメタプログラミングの時代

www.amazon.com/Template-Metaprogramming-Concepts-Techniques-Beyond/dp/0321227255/ref=pd_sxp_f_pt/178-3386828-6807318
www.youtube.com/watch?v=Jfu9Kc1D-gQ
channel9.msdn.com/Shows/Going+Deep/Alexandrescu-Meyers-Sutter-On-Static-If-C11-in-2012-Modern-Libraries-and-Metaprogramming
channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Scott-Meyers-Universal-References-in-Cpp11

ゲームプログラマの俺に言わせれば、オブジェクト指向が愚かな考えとかまるで意味が解らんな。

だって俺ら、まさに多数の物体＝オブジェクトを2D・3D空間内で制御してるんだもん。
プレイヤーキャラ、敵キャラ、アイテム、地面、建物、エフェクトその他もろもろ
オブジェクトそのものを現実に扱ってるんだもん。
特に「ゲームオブジェクト」と呼んだりもする。

多数（数十からときには数千、数万個）の「ゲームオブジェクト」が
座標系・描画・物理・AIといった複数の「コンポーネント」をそれぞれ持ち、
相互に「メッセージ」のやり取りをするのがゲームプログラムの一般的な設計だな。

詳しくはゲームエンジンアーキテクチャという本を読んでくれ
PSのアンチャーテッド・シリーズやラストオブアスのメインプログラマが執筆した本だ。

Amazon.co.jp： Game Engine Architecture: Jeff Lander, Matt Whiting, Jason Gregory: 洋書
http://www.amazon.co.jp/dp/1568814135

俺も中学生の頃、「多数のゲーム空間のオブジェクトを管理する」必要性から
アセンブラやC言語で自然にオブジェクト指向の真似事をやっていたね。
（タスクシステムという言葉もあったがあれは日本のガラパゴスだな）
後にC++とC++が吐くアセンブリコードを見て、同じことやってるじゃねーかと解ったのは実に驚いたものだよ。

要は、分野によってはごく自然に行きつく概念であり発想だということだ。

>>227
その言だとクラスベースのインスタンスがはまる例としか受け取れないな
ここはOOPの基本要素(継承、カプセル化、多態など)が美少女についてうまくはまるかを談笑するネタスレであり、君の書き込みは上から目線な姿勢もあいまってやや空気読めてない素敵な書き込みだと言えよう
何言ってんだお前

やっぱりゲームプログラマはレベル高いな
それにくらべ業務系と来たらorz

平日の昼間にこんなところに居る時点でお察し
如何にフレックスでもこの辺はコアタイムだしね
便所に引きこもってるのかな

クラス：　デザイン
インスタンス：　製品
継承：　盗作

C++<java<Objective-Cぐらいの順番で原義に近い(教科書で習う)オブジェクト指向に近づいてゆくので
>>227みたいなのを見ると「違うよクソ！C++の継承を見て
『俺オブジェクト指向の良さがわかった』とか言ってる奴と同じぐらいむかつく！」

勝手にむかついてろ
んでハゲろ
USUGEMAN~

(違うよクソ！プリキュアに出てくるお母さんキャラを見て「俺熟女の良さわかった」とか言ってる奴と同じ位むかつく！)

3Dゲームがこの話に近い立ち居地ではあるよなぁ。
途中で何を思ったのかMVCを持ち出そうとした時もあったし・・・
俺もweb系だけど、MVCはねーよと思った。

>>230
もういないと思うけど、怪しまれない程度で便所から戻れよー

三次元ゲーム内世界のルール&物理法則がモデル(M)で
ビュー(V)はハードごとの解像度や画面
そしてそれらを繋ぐ"ゲーム"そのものがコントローラ(C)で
別に問題なく実現できそうだけど？

なんで世界まで範囲が広がってんだ

美少女に排便させられないって、そんなの見たことない。
それなんてエロゲ？

>>237
？ MVCの「モデル」っていうのはシステム環境から独立した抽象モデルだから
FPSだったら共通の世界モデルを独立させて、
そことシステム依存のビューをコントローラで繋ぐのが妥当だと思ったけど…？
いったいどこで分けようとされてたの

その方とは違うけどMとCの違いが気になるな
特にCがゲームそのものってなんのこっちゃ？
ゲームそのものなのはルールの方で、コントローラは入力管理とすべきじゃないの。

でもゲームってレンダラや非同期処理AIや通信なんかが絡んでくると結局webのフレームワークみたいにはいかんよ
内部はもうオブジェクト指向設計なんざ知ったことか的な泥臭いキューモデルぶんまわしてて、表層だけをOOPっぽくスクリプトでゆるく書けるように分離してるエンジンばかり

持ち運べるワールドの法則や座標系、物理、キャラステータスとかが「モデル」で
そこの上でモデルの何が何発で壊れる/死ぬ、
何をどうすれば勝ちで負け(ゲームオーバー)なのかなどの
ゲームルール部分は(モデル)「コントローラ」に実装すべきじゃないか？という分類

あれだね"エンジン"部分がモデルで"ゲームルール"部分をコントローラにするか
ゲーム丸ごと独立したモデルにしてコントローラは単なるインタフェースと
捉えるかの違い。

うわぁ……

>>423
return; のみで何の処理もせずに終了するような
美少女クラス::排便メソッド
をオーバーライドする仕様を御提案しましたところ、
貴社におかれましてはそもそもそのようなメソッドの存在が許されざるものであるとの御指摘を頂戴しましたので、

人間クラスの上位クラスとしての美少女クラスを定義することと致し、再提案させて頂きます。

以上

>>239
>>29 >>32 このへん

人間は美少女である。
美少女は人間とは限らない。

こういうことになるが。

やはりお前のMVCは間違っている

俺がMVCだ！

排便メソッドが実行されないと便秘になるという問題を忘れてないか？

まず美少女の体内に便なんてないから

>>248
それはリアルだろがボケ
今時の美少女の諸問題は動的にGCされる
もしくはリファレンスカウンタが、スカトロ系かどうかという分類に基づいた上で視聴者数をカウントして適切なメソッドに監督が分類するから問題ない
不適切な表現を行う監督が存在することは否定しないが、それは設計の問題ではなく監督の問題だと我々視聴者は認識している
異論はあるだろう、存分に申せ。受けて立つ覚悟だ

>>1から読み直せやカス

すみませんでした
読み直して来ました

>>245
人間というサブクラスに bool is美少女 を入れて
is美少女==false の場合にのみ使用するプロパティとして
enum sex={male,female,bysexual}
を用意して、人間::うんこするメソッドを入れれば良い

そこらじゅうにコピペしまくってるあほんだらがいるのはここか！！！！

責任とって全部のスレの削除と
書いてるやつの処理お前らが責任持ってやれよ。

お前のやってることは犯罪だ。

ああ確かにお前の存在は犯罪じみているな

ランボーにぼこぼこにされるぞ

>>254
山崎渉にもよろしくな！

宣伝されてるスレを立ててるBEは全て同一人物なんだよねぇ
無作為にプログラム関係のスレを宣伝するわけでなく必ず特定のBEが立てたスレのみを宣伝する
一体どこの誰がこんなスパム行為をやってるのか知らないが、不思議な話だなぁ

勃起しらわ

美少女は仮想の存在

実身は別にある

つまり人間クラスにvforkメソッドを用意してそこで天使クラスのインスタンスを生成すればよい

あと人間クラスが一定年齢以上だとvforkメソッドで例外発生

便意はプッシュ配信かつ非同期なので人間クラスにイベントとして実装。
天使クラスには実装しない。

天使クラスってなんだよ
麻婆豆腐か

こんな感じでどうよ？

美少女って何歳まで許される？

高校生を少女っていうか?

え、言うだろ

つかまるぞ

80年代にロリコンという新語が流行った時には
女子高生ものが"ロリコン写真集！"って売られてたな。
C++が"オブジェクト指向！"ってのと同じ感じで

現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/

>>272←こいつも精神病だが
このスレ立てた奴も精神病だろ

精神病うざすぎ
しねよ

これが同族嫌悪です

スカトロとかする美少女は美少女じゃないん？

それ美しい少女じゃなくて美が少ない女じゃないですか

馬鹿なこと言ってるんじゃありません

美少女に限らず、人間を物扱いするところから駄目なんですよ！

つうか、そもそもの発端が妄想だから説得力無いんじゃね？
排泄しない人間なんていねえし、美少女だって排泄くらいするんだから
本当にそんなクラス作ったら機能不全で使えねえだろ。

3次元アイドル厨か？随分と次元の高いツッコミですね(棒

OMTに戻ればいいんだよ
あのころがいちばんよかった

OpenWindowsLibraryじゃなくて？

>>282
それを言うならBoochだろ

ポリモーフィズムとは、子であり親である事。

人はクローンなどの例外を除いて皆子である。

つまり、子を産むと親になるから、

子を産まなければ、ポリモーフィズムではない。

逆だろ。たくさんの子ども達が集まってお母さんを作り出すのがポリモーフィズム。

>>285
何か、そう言うとヤバい感じに聞こえるなw

違うよ、iPS細胞だろ、どう考えても

class Human {
list<Excrement> ex;
double energy;

Human() { fu = nil(); ex = nil(); energy = 12.93;};

virtual void eat(Fuel fu) {
double eff = 0.8;
energy += asEnergy(fu,eff));
ex.insert(ex.begin(), asExcrement(fu,1.0 - eff));
};

static void evacuate1(Excrement *ex) { ... }
void evacuate() {
for_each(ex.begin, ex.end(), evacuate1);
}
};

class NonexistentBeauty: public Human {
void eat(Fuel fu) {
energy += asEnergy(fu,1.0);
};
};

ところで、うさぎがほたるちゃんの家でトイレを借りるシーンがあるのだが、
これはどう実装したらよかろうか。

二次元から卒業しろよw

ウサギも蛍も三次元だろ！
みんなみんな生きているんだぞ！

わかりやすいな。

二次卒業式が解けない。

エージェント指向はどうなの？

>>295
あったなー。十数年前、俺が大学一年ぐらいに
先生がオブジェクト指向の次みたいに言ってた。

話を聞いて、使えないことはないけどこれ
次とかじゃなくてオブジェクト指向に情報伝達の
インターフェースを追加しただけじゃんって思ってた。
つまりオブジェクト指向と何も変わっていないと。

今の状況見れば、やっぱりそうだったって感じ。

根本にあるのは構造化およびモジュール化であって
それ以上は単なる規約の追加にしか過ぎんよ
これからも○○指向っていうのはいくらでも出てくるだろうけど
ほとんどバズワードみたいなもの

つうか、それぞれのエージェントがタスク化されてそれぞれの間をメッセージ交換で連絡取り合いながら一連の作業を進めていくという実装上の仕組みは無視か？

エージェントは、なんでもできる万能エージェントか？
まあ、そんなものはありえない。

つまりエージェントには「何が出来て何が出来ないか」の
情報取得インターフェースを持っている。

だが、何が出来るか？っていうのをカタログ化することはできない。
つまり、この関数は何が出来る。このオブジェクトは何が出来る。というのを
定義することは出来ない。曖昧すぎて正確な定義をするのが困難だから。
人間の言葉でなら可能だがね。

情報取得インターフェースをもたせる所まではできるが
「できること」を定義することが出来ない。
エージェント指向なんてのが実用化されるとしたら、曖昧な命令で正しく動くAIができてから。
だが曖昧な命令で正しく動くことは人間でも無理。

情報取得インターフェースもメッセージ交換もそれはオブジェクト指向でできてること。

エージェントは出来る事しかしないんだから、曖昧さなんて存在しないよ。

アスペクト指向もエージェント指向もオブジェクト指向に包摂させるもの？

されないね

>>300
そのできることの定義ができないんだよ。

「私は掛け算が出来ます」ってことを
コンピュータ上でどうやって定義するか？

無理でしょう？

エージェントではなくて、エージェントに指令を出すほうが
エージェントのことを知らないといけない。
掛け算をしたいからMath/Multiplicationエージェントさんに仕事を頼もうって具合に。

これなら実現可能だけど、エージェント指向では
誰に（Math/Multiplicationエージェントさん）ではなくて、仕事内容（掛け算）を
やってくれる人を買ってに見つけるものなので、
正確に仕事内容を伝えなきゃいけない。

仕事を出すために仕事の処理内容を引数にするとかわけわからんｗ
それクロージャーを渡して別スレッドで実行ってことかいな？ｗ

あぁ、根本的に分かってねえなこいつw
いくらエージェントとか言っても、相手はコンピュータ
自然言語理解する訳ねえだろ。

計算式をエージェントが解く場合、まず構文解析エージェントがトークンに分ける。次に演算順序エージェントが順番に並べる。
そしてかけ算エージェント、割り算エージェント、足し算エージェント、引き算エージェントがそれぞれ計算し、演算順序エージェントと協調して結果をとりまとめるエージェントに渡して、人間さまの理解出来る形に変換するエージェントがプリントアウト。

オブジェクト指向だと計算順序から次の処理オブジェクトまで静的に人間様がコーディングするが、エージェントの場合はメッセージだけ規定してコーディング。

理解出来る物しか実行しないというのは、文字通り本当に指定されたメッセージ処理以外しないって事だ。

>>304
それだとエージェントである必要が全く無いですよね？

まず構文解析オブジェクトがトークンに分ける。次に演算順序オブジェクトが順番に並べる。
そしてかけ算オブジェクト、割り算オブジェクト、足し算オブジェクト、引き算オブジェクトがそれぞれ計算し、
演算順序オブジェクトと協調して結果をとりまとめるオブジェクトに渡して、人間さまの理解出来る形に変換する
オブジェクトがプリントアウト。

さて、エージェント特有のものは何でしょうか？

> オブジェクト指向だと計算順序から次の処理オブジェクトまで静的に人間様がコーディングするが、
> エージェントの場合はメッセージだけ規定してコーディング。

そのメッセージを作るのが不可能なんですよ。
メッセージの一例を書いてみてください。

すげー勘違いしてない？
エージェントって言ってるのは呼び出し方がちょっと違うだけの
機能を持ったオブジェクトだよ

２０年くらい前エージェント指向というのが雑誌に書いてあったので読んでこれはダメだと思ったことしか覚えてない。

よく分からんが、エージェント全員に同じメッセージを出して、
受理できるエージェントが自動的に実行するってこと？

実行したエージェントが、次よろしく、とメッセージを出す。
それを受理できるエージェントが・・・

>>306
だからそういうこと。
エージェント指向というものは存在しない。

オブジェクト指向にある種のインターフェースを持たせただけのもの。
エージェント指向で凄いことが出来るように言っているが、
その多くは実現不可能で、現実にはインターフェース以上にものにはなりはしない。

ただのインターフェースなのに指向とか風呂敷を広げ過ぎたんだ。

>>308
うん。そういう宣伝をしているね。

だけどエージェントが全てのメッセージを理解できるわけでもなく
メッセージを出す側がやってほしいことを
ちゃんとエージェントがやるかといったら、
エージェントが勝手に判断してやることなんかない。

結局のところメッセージとは、受理できるエージェントを
指定した関数呼び出しでしかない。

もしかして：分散オブジェクト

>>311
そういうこと。

エージェント指向なんてものはなくて
実態はオブジェクト指向なんだよ。

アスペクト指向も？

アスペクト指向も指向ってほどのものじゃないね。
mixin等と同じようなもの。
オブジェクト指向のフレームワークや言語拡張で提供できてる。

何でもできる神クラスを作ろうとして結局何もできなかったって感じだな。
それだったらGoogleにリクエスト投げた方がよっぽど良い返事がもらえる。

あらゆるプログラミング言語はアセンブリ言語のフレームワークや言語拡張だ、
と言っているようなものだ。実質何も言っていない。

今更だがｗ 十数年前に聞いただけの記憶に頼るのはアレなんで、検索してみた。

http://itpro.nikkeibp.co.jp/word/page/10024992/
> エージェント指向 agent-oriented
>
> オブジェクト指向におけるオブジェクトを、自ら判断し処理できる
> 機能を持ったエージェントと呼ばれるモジュールに置き換えたもの。
> エージェント同士が状況に応じて自律的に連携、協調できるようになることを目指している。
>
> 　エージェント指向システムを構築するに当たっては、
> それを使って解決しようとする問題を分割し、それぞれの問題を
> 解決するエージェントを設計するといった方法などが考えられている。

うん、あってたｗ

問題を小さくし、その問題を解決するエージェントってのは要するにクラスや関数のこと。
そこはオブジェクト指向でも同じなわけで、エージェントのキモは「自ら判断し処理できる」こと。

単純に、○○ができるエージェントさんに仕事を頼むのが、オブジェクト指向であり、こっちは簡単にできる。

エージェント指向では仕事を用意すれば、エージェントが勝手に仕事をするんだが、
その仕事＝メッセージをどうやって定義すればいいのか。
仕事を行ってくれるための、"完ぺきな"命令を用意しなければいけない。大変な作業だよ。

「カレーつくってれ」という簡単なメッセージで人間世界は成り立つかもしれないが
コンピュータの世界じゃ詳細なレシピをメッセージとして、エージェントに渡さないといけないからな。
カレーに野菜が入っているか、肉が入っているかはエージェントにお任せ。
なんてものを人間はコンピュータに求めていないわけで。

日経解説だしな

>>316
あらゆるプログラミング言語はアセンブリ言語のフレームワークや言語拡張だよ。
正確には、アセンブリの中の特定のパターンに
名前をつけて、単純でわかりやすい記述（文法）でかけるようにしたもの。

指向は考え方。だけどエージェント指向やアスペクト指向は考え方ではなくて
機能（エージェント）と文法（アスペクト）にすぎないって話。

別に、使えないものだとは言ってないんだよ。
オブジェクト指向は指向でいいが
エージェントやアスペクトは指向ではないってこと。
だから「指向」としてはオブジェクト指向を置き換えるには至らなかったんでしょ。

機能や文法はオブジェクト指向言語やそのフレームワークに取り入れられたが。

>>318
もっといい解説が存在するなら
それを書いてくれていいよ。

美少女とトイレでばったりとか、美少女のお漏らしとか見れないのん？

オブジェクト指向だって、機能と文法に過ぎないじゃないか。

いえオブジェクト指向は（言語とは無関係の）設計パターンですよ。
オブジェクト同士の関連を表したもので、実装ではありません。

その設計パターンを実装しやすいような文法にしたのが
オブジェクト指向言語です。

その言葉の「オブジェクト」を「アスペクト」に変えてみたらどうかな？

AspectJ は、アスペクト指向のパターンを実装しやすいような文法にしたもの、
以外のなにものでもない、と思うけど。

トランザクションスクリプト全盛期にはインパクトあったじゃん
オブジェクトの外側でロジックが浮いちゃってたからこれを神でも小人でもいいけどエージェントと呼ぶとすっきりした気になった

> すっきりした気になった

それは大事なこと。

class Humen{
　void evacuation{
　　printf("unko");
　　return;
　}
}

class Bisyojo extends Humen{
　void evacuation{
　　　return;
　}
}　

オブジェクト指向が自然を記述する為にあるとかわけの分からん勘違いしてる様な奴は度し難いという一例

ObjectiveC以外でオブジェクト指向しようとするから悩むんだよ。

92,3年頃にでたOMT のツールが使いやすかったんだが名前忘れた。だれかしらない？

オブジェクト指向は指向なんでそこから色んなパターンが生まれてるけど
アスペクトは1パターンでしかないんだよね。

オブジェクト間の連携の間に処理を割りこませる時に使うパターン

>>328
ランボーが自動車をサンプルとして提示したから
現実に適用できる、なんだかすごいやつとして
いつの間にか広がったと信じています

オブジェクト指向って要するに大失敗した米国防総省のAdaプロジェクトの遺物だからな

I Have to Work Faster and Faster
　スケジュールが長かった時代には、ドメインモデルを注意深くモデル化してコードに落とし
こむこともできたが、設計ミスがあると、修正して新バージョンをつくるまで数ヶ月かかって
いた。今日ほとんどのプロジェクトでは、ドメインを的確に理解することは、すばやく価値を
提供することよりも重要ではない。ドメインの理解はいずれにしろすぐに変わっていくし、顧
客側でもデプロイごとに新しい発見をしていく。ドメインのいくつかの側面を誤解していた場
合、リリースを繰り返す中ですばやく修正される。
　もし注意深いモデリングが重要でないのなら、オブジェクトモデルを忠実に実装すること自
体、以前よりも疑いの度を増してくる。アジャイルソフト開発は、品質と変更への対応を大幅
に改善したが、いまどきの要件に対しては、”必要最小限”かつ柔軟に変更に対応できるよう
にコードを保つ方法を考え直さなければならない。関数プログラミングはこのためにある。
shop.oreilly.com/product/0636920021667.do

>>323
OOPでない純C言語でもOOP出来るもんな
言語サポートが無いから「やりにくい」だけで

UML2.0への変化についていけず
ウォーターフォールに戻りました

Cしか知らなかった頃は1関数内千行も書いて怒られていたがC++を知ってからは積極的に処理を外出しする癖がついた
その頃から業務の細分化もできるようになって後輩に仕事を与えやすくなった気がする十五年前の思い出

数千行は極端ですな。おれは15年前は中坊なんで想像もできないですが

一方今は、無数のフォルダ分けがなされて20行もないファイルが数千個ばらまかれ、リファクタツールかける気にもなりようがないメンテナンス不能なjavaプロジェクトみたいな極端も存在します
どっちがマシなんでそ

ぶっちゃけ手のつけようがあるかないかで言うと、(gotoスパゲティがなければ)数千行のcコードの方が望みがあるのかなとか思うんすけどw

>>338
goto大好きBASIC(≠VB)の世代ですんで^ ^

Javaは残念ながら知らないんですが私の場合はC++が
仕様書がなくとも何とか他人が読めるコードを書けと教えてくれた
決して先輩上司ではなくてね

>>337

俺はN88-BASICの時代から１プログラム100行以下を心がけていた。。。たぶん、ストレスなく管理できるのは２００行が限界じゃないかな。

プログラムの重複を整理するとＣ言語で９５％がサブルーチン化できるが、どうしても５％は素直にサブルーチン化できない。
その代表格がsort()関数だろうね。標準ライブラリのsort()関数は最終パラメータにプログラムの開始アドレスを渡している。
この部分が５％にあたる。

　ただ、そう考えるとＣ言語は１００％サブルーチン化出来るとも言える。最後は関数のアドレスをわたしゃいんだから。
そのアドレス渡しを高級文法の中で（知らない間に）使えるようにしたのがＣ＋＋の特徴と言えるべさ。

　もっとも、、、Ｃ言語に関数を示す判りやすいキャストを登録しただけの方がすっきりした気がする。

　ただね、、、オブジェクト指向言語、いや、Ｃ＋＋とそれをお手本にした言語というべきなんだけど、ゼロポストの言うとおり糞だというのは同感なんだ。

　オブジェクト指向の考案者は、もともとは「作業を楽する事を心がけるプログラミング」という意味だったんじゃないかね？
俺はSmallTalkは触ったことないからＣ＋＋しか判らんのでそう思う。

　Ｃ＋＋の作者はクラス化という考え方で「作業を楽する事を心がけるプログラミング」を実現しようとした。
で、それを見た子ネズミ達は、クラス化がオブジェクト指向なんだと勘違いしたのジャマイカ？

　　　　　　　　　　　＊＊＊

　Ｃ＋＋のクラス化って情報処理で落ちこぼれの温床になっていると思うんだが詳しい人いないかな？
クラス化を素直に理解できる人は２種類いると思う。

１）アセンブラをマスターしている人。
　Ｃ＋＋ってのは機械語で仕事していれば実に実に判りやすいんだ。

２）丸暗記に強いタイプ。

　Ｃ＋＋がクソじゃねえか？ってのは、１，２も一般的とは言いがたいと思うというのが理由。

同意。

たぶんクラスというのは元々、構造化プログラミングで関数をばらばらに扱うと
大変なことになってくるのでそれを簡単にする為にグループ化、もしくはモジュール化
していたのを、最初から言語仕様にしてしまおうという目的だったと理解している。

その結果出来たクラス、モジュールの振舞いが、現実世界のものに似ている場合が有る、
ことから誰かがオブジェクト指向なんて名前をつけてしまったんだと思う。

だからあくまでも結果論であって、「オブジェクト」指向から理解しようと思っても
それに当てはまらないケースなんて山ほどあって、結局理解出来ないことになる。
あの、ワンとかニャーの例が初心者を落ちこぼれさす一番最悪な例だと思う。

で、俺もそのワンとかニャーの被害者ｗ

長年理解出来ずに居たが。
結局、よく整理された分かり易いコードを書くようにしていたある時、
その結果のコードが「オブジェクト指向」になっていて、
初めてそこで「オブジェクト指向」と呼ばれていたものが理解出来たという感じ。

　オブジェクト指向の最大の問題点は、過剰な喩えでこれから覚えなくてはいけない人を惑乱したことだろうね。
「メソッドにメッセージを送る」なんて実際に、どっかで呼んだ覚えがある。

　素直に「サブルーチンを呼ぶ」って言えばよい話。
メソッド（オブジェクト指向プログラミングにおいて、各オブジェクトが持っている自身に対する操作）
と気取った言い方をした所で、所詮プログラムはプログラム。

　で、メッセージを送るなんて大袈裟な事言っても、ただ単にメソッドを実行しているだけ。

　コンピュータの構造を理解している人間ほど、電波に感じる言葉遣いをしているって問題もある。

>コンピュータの構造を理解している人間ほど
誤解はよろしくない。
本を書くのはヒマな人間だ。
それがどういう意味かわかるな？

> ただ単にメソッドを実行しているだけ。

そういう論理は、どんなコンピュータも機械語を実行しているだけ。だからアセンブリ言語以外無用。
という無意味な結論にしかならないよ。

メソッドにメッセージを送るのではなく、オブジェクトにメッセージを送るとメソッドがじっこうされる。


メッセージを送るというのを意識した言語なんてRubyとかごく一部な気が。
普通の言語ならメソッドを呼ぶのほうが一般的に使われる(rubyとかも)

メソッドはサブルーチンの一種だから、わざわざ誤解する可能性のあるサブルーチンという用語を使う意味はない

プーチンでも呼んで来い

サブプーチン

サブルーチンという用語だと、データと処理が別々になってしまう印象を受けるな。
メソッドだと、大体はカプセル化されてデータを隠蔽する印象。

呼び出して使う側からすると前者は面倒。呼び出し側がデータの後始末意識しないといけないし。

オブジェクト指向だからといってガベージコレクションやRTTIが完備されてるわけじゃない。

関数とサブルーチンに明確な境目はないけれど、
ちゃんとした関数なら副作用がなくてテストが容易で
コードの中身を見なくても処理が推測できるもので

だめな関数＝サブルーチンは、副作用がメインでテストが難しい
コードの中身を見ないと何をやっているのかさっぱりわからない。
ってイメージが有るな。


たとえば、コードが長くなったから
一部分をそっくり抜き出して、関数にすると
たいていダメな関数＝サブルーチンになってる。

そういうサブルーチンばっかり作っているような技術力の低い所だと
関数（実際はサブルーチン）を使うとあちこちにジャンプする必要があるから
コードが読みにくい！とか言うやつが出てくる。（本当はちゃんとした関数をかけてないから）

おいおい、そんな基本的な話されても…

…なんだここ素人しかいねえよw

俺もワンにゃーでは全く分からんかったな…
スクリプト系で、組み込みの配列や文字列、果てはBigIntや実数どころか
フツーの小さな整数までがオブジェクトとされてる言語を触ってから
「あ、オブジェクトって、たかがそういう話なんだ？」と気付いた
その「たかがオブジェクト」が中々理解に苦しんだ

そう。現実のオブジェクトってどんなものでも多機能なイメージになるよな。
だから、初心者がそのイメージで設計すると、そのまま多機能で大量のメンバー変数と
メソッドを持つクラスになってしまう。

>>354
そうだよ。実は知らない人のほうが理解早いぐらい。
それぐらい普通の概念なんだよね。

俺も小学5年生の時、BASICを少しかけるようになった時、
よしエロいゲームを作ろう。
さて女の子を作るにはどうしたらいいんだ？
頭、顔、足、手、おっぱい、これらをどうやってプログラムすればいいんだ？

で、ここまでで挫折した。

その後オブジェクト指向ではない言語を使ってきて、
体のパーツを作ろうとかいう発想じゃダメだなーってわかったんだが、

オブジェクト指向を理解して、あの時考えたものは
オブジェクトを使うことによって、実装可能であることに気づいた。

>>355
15年後の>>337が１クラスに１０００メソッド詰め込んだ感じか？

　まああれだ、、、古典的な教本ではサブルーチンって読んでいたわけだ。
BASICとかFORTRANの時代な。

　ルーチン（手続き、処理）のサブだから、子プログラムはサブルーチンと読んでいたわけだ。

　Ｃ言語が出現してこれを関数（ファンクション）といい始めた。
Ｋ＆Ｒの主張は、サブルーチンは、x=f()の関係だから関数なんだというもんだったな。

　言っている事は同じなんで違和感がここまではなかった。

　Ｃ＋＋になってメソッドと言いはじめて、、、メッセを送るだと？・・・これでどれだけ有望な技術者が納期を守れず夜逃げしたことか。。。これ実話。

>>347
>メソッドにメッセージを送るのではなく、オブジェクトにメッセージを送るとメソッドがじっこうされる。

　自然言語としてヘンだってことを理解してほしい。
メッセージという言葉がおかしいんだよ。

　メッセというのはマルチタスクで動いているプログラムＡ，Ｂの間でプロセス間通信を利用し、メッセージを送るというのが本来の使い方。
メッセージという言葉使った瞬間にそういう誤解を受ける。これが大問題。

　階層構造を持つ、クラス定義したジャンプテーブルに従い、関数を読んでいるだけなんで、実際にはメッセージでも何でもない。

　現実に即して言うならば、メッセージという言葉を最初に使った時点で思想家を気取った香具師がこの言葉を選らんだのではにかと思うわけだ。

>>346
>そういう論理は、どんなコンピュータも機械語を実行しているだけ。
>だからアセンブリ言語以外無用。という無意味な結論にしかならないよ。

ならんと思うよ。
アセンブラの観点から見ると、FORTRAN->C言語->C++の流れはポインタ操作に関しては先祖返りだというのが良く判る。

FORTRAN/COBOLの時代に、良く使う機能を強化し、レアな機能を隠蔽したわけなんだが、隠蔽されていたポインタはやっぱり必要だろうとＣ言語で復活した。

Ｃ言語ではデータ操作を前提としていたが、サブルーチンもポインタ操作する必要があるというのでＣ＋＋が出現したと言う指摘は可能だ。

>>359
たしかにメッセージという言葉は他にも使われていた用語だから紛らわしいけど、おかしいまではいかないでしょ
言語によって用語の意味が異なることもあるんだし

俺もそれほどメッセージの考え方が好きなわけではないけど、
メソッドがジャンプテーブルになかった時とかメッセージのほうが自然な解釈ができる気がする

>>353
今更かｗ
ここには妄想技術者とか日曜プログラマしかいねーよ

>>362 理解できないのでそう思うのですねわかりますw

副作用があるものまでひっくるめて「関数」と呼んじゃうのはC言語他の悪い慣習に過ぎないな。
一般名詞と、特定の言語仕様におけるテクニカルタームは、ちゃんと峻別しなきゃダメ。

ワナビーくんが駄目出ししたところで意味ないでしょ

いっつも思うんだが、語る資格がないような雑魚ほど語りたがるよなｗ
子供が政治を語ってるような陳腐さになぜ本人は気づかないのか。
ひたすらそれが不思議でならない。

そう思うなら「C言語は関数型言語」とか主張して一生混乱しとけ

> 子供が政治を語ってるような陳腐さになぜ本人は気づかないのか。

自己紹介乙w

もう「手続き」って読んどけよ(笑)

Smalltalk知らなさそう

そりゃしょうがないよ。K&amp;RがC言語は関数型言語だって「プログラミング言語C」の中で言っていたよね？
K&amp;Rは原理的に数学オタクだった気がするなｗｗｗ

　彼らが作ろうとしたUnixが物事を徹底して抽象化して一元化したものだから、さもありなんという気がする。

　こないだLinuxでプロセス管理していたんだが、Linux/Unixって、プロセスをファイルで管理しているのな・・・あれは驚いた。
プログラムを実行するとプロセス番号を名前に持つファイルがポコポコ生まれる。

　実にファンダメンタルだなって思ったよｗｗｗ

　まあミニコンがメモリ８Kだから３２Kだかって時代の名残りかもしれんが。。。

> そりゃしょうがないよ。K&amp;RがC言語は関数型言語だって「プログラミング言語C」の中で言っていたよね？

何頁？

　ただなあ、、、オブジェクト指向が実学ではなく、宗教化しているんじゃないかなあ。。。
　一般的にオブジェクト指向と称している言語の文法を「オブジェクト指向」と誤解しているのは良い事ではないだろう。

　たかがオブジェクト指向、その証拠に、Linux系のコンパイラ系オープンソースの開発のほとんどはC言語ベースで行われている。
C++でオブジェクト指向というのはめったに見かけない。

　つまり世の中のシステムの大半はC言語で十分、いやC++では無理があるということを暗示している。

　　　　　　＊＊＊

　C++でないとダメだって分野もあるから一律否定はしない。

　Linux系のGUIライブラリGTKは、C言語ベースなんだが失敗例だろうな。
GTK+になってクラス化されて始めてまともに使えるようになった。

　C言語だと、GUIライブラリは設計者が上手くないと失敗するんだろうな。
MSのMFCとかGUI関連にクラスライブラリが多いのはそれがC++と相性が良いんだろう。。。

　でもこれは珍しいケースだと思うけどね。

>>371
太古の昔に読んで記憶しかないな。確か、Cではサブルーチンは関数として扱うという記述のところで見たと思う。
あるいは<stdio.h>のあたりかな。

　いや、まてよ・・・main()のところかもしれん。ｗｗｗ
main()関数つまり、それ自体が関数型言語だと自己主張しているように見える。

C言語の「関数」は、単に「そう呼んでるだけ」だから。

>>370
> 　こないだLinuxでプロセス管理していたんだが、Linux/Unixって、プロセスをファイルで管理しているのな・・・あれは驚いた。
> プログラムを実行するとプロセス番号を名前に持つファイルがポコポコ生まれる。

procfsでググれアホ

つーかUNIX的には後付けだな。
Plan9あたりからのバックポート。

>>375

ググッタがね、、、ってかさ、徹底的にファイルで一元管理しているのが凄いと思わんか？
おれはのけぞったよ。

　ユニファイドIOでここまで突き詰めたんだなってのが素直な感想。

一元管理してるわけじゃないよ。
単に、昔はpsコマンドとかが実装に依存して情報を得ていたような所にAPIを横から追加してるだけ。

ネットワークまわりがファイルに乗ってないというUNIXの設計は変わってないし、
「ユニファイドIO」とやらが一体何を指してるのか知らないけど、何も突き詰めてない。

>>377
多分、俺とお前の「管理」が意味するところが違うんだと思うので、これ以上話しても無駄だなという感想

>>379

おれもそう思うよ。
俺は素直に、Unixって原理的にコダワッテイルナと思うわけよ。

こないだ、ディスク管理ツールを作ったんだが、GUIからシェルコマンド叩いてスタンダードIOだけでプログレスバーを表示出来たときには感動したなあ。

ただかまって欲しいだけなんだろうか。

単にいろんなものファイルとして処理するという発想なだけでメモリが少なかったとか関係ないじゃん

ファイルに抽象化して、むしろオーバーヘッドが増えるんだから、メモリは余計に食うよな。

（初期の）BSDなんかは、仮想記憶を使うためにBSDがあるのか、BSDを使うために仮想記憶があるのか、
てな感じにメモリ空間を必要としたようだしw

久々に覗いたら、まじめなはなしになってんな……

美少女クラスの話をしてくれよ！

美少女とは二次元空間にしか存在しない架空の存在である

アニメーターとかは、バスや電車で人物観察してスケッチに残したりする。アンケートの標本みたいに、
現実世界の人々のサンプリングとして使う。が、それって本当に客観的で抽象的なデータなのか？
Googleマップとかでも起こりうるように、そういうのは実際には全部個人情報なのではないか？
美少女キャラといっても、９割方は現実に存在する美少女のパッチワークであり、絵描きがクリエイト
した部分は１割もないのが普通ではないか？宮崎アニメでなぜわざわざ、スタッフの人に似せたキャラ
を出したりするかというと、元のモデルが差し障って使えなかったりするからだろう。

へんなもの食ったのか？

>>384
なにげに良スレになってるな。

ダックタイピングにおける美少女クラスの持つべき属性を
まじめに論じてくれよ。

>>373
Cは関数型言語じゃない
ソースはwiki

Cはただ命令型言語

>>390
命令型で無いものの名前と代表的な言語を教えて頂けますか

>>391
宣言型言語。Scheme, Haskell, Prolog など

今北

外出とは思うがJSみたいなオブジェクト指向なら
メソッドを削除するだけだから何の問題もないな

JCかJKみたいなオブジェクト指向も頼む

２ついいことを教えてやろう。HunterxHunterはなぜ唐突にアリの話になったのか？
『社会生物学』のEdward O. Wilsonが、アリの研究者だからだ。そして、新しいガ
ンダムがなぜレコンギスタなのか？ --- 「The Social Conquest of Earth」という
新著の題名から採ったかは別として、おそらくそのあたりがネタ元のはず。

オブジェクトってのは個体の全ての情報を持っているわけじゃなくて
あるテーマにおける情報と振る舞い方を表してるにすぎない
筆記用具としてのペンと、凶器としてのペンではクラスを別にしないといけない
データベースのレコードがいい例えになる
僕らが扱っているのはオブジェクトではなく、あくまでオブジェクトの側面なのだ。
それどころかオブジェクト自身が側面の集まりであることに気づくべきなのだ

そういうオブジェクト指向の哲学を中心に語った本って何かある？

>>396
おかしい。

あるオブジェクトが筆記用具（クラス）として扱われたり、凶器（クラス）として扱われるというのが、
OOPの多態性の話だというのに。

君が言ってるのは、「クラス」の話なんだから、どこをどうやったら、それが「オブジェクト」の話として、
そういう大上段に構えた主張になれるわけ？

オブジェクト自体には情報が無いって事？
型抜きが増えるたびに情報が付与されていく感じか

ペン自体はそういう形をした物質でしか無いからな。

ん、なんか変だな
そういう形をした物質は、筆記用具としても凶器としても使える。
で問題ない気がする。

そもそもクラスからオブジェクトを生成するってのが変なんだよな
△クラスと□クラスと○クラスが合わさって☆クラスになる
☆クラスのインスタンスが☆オブジェクト

でも現実には☆オブジェクトが先にある
☆の要素を分解したら△、□、○に分解できるわけだ

でも使い方なんてのは無限に付与できるわけで
それは☆が元々持っている情報なのかって話になってくる

新しい使い方が付与されると☆は☆ではなかったという事態になる。
それが☆はそれ自体の側面でしかないってことか。

>>398
そ、それは多態性ではないお。

ペンにwriteメソッドとattackメソッドをつけるのか

ココは memset で構造体初期化しちゃうひとたちの掃き溜まり？

>>404
当たり前だろ
仕様上も問題ないぞ

IEEE754 だったら問題ないね、他あるかね

内部表現が0以外のヌルポな環境もダメだね。
今時そんな環境無いとは思うけどね。

C++のコンストラクタ付きの構造体や、初期化関数付属なら流石にそれに任せるよ

>>408
c++ なら、ゼロ初期化に明示的なコンストラクタは必要ないんだけどね。

struct A {/* 宣言何でも */};

A a = {}; //←とか、
A a = A(); //←でオケ。

>>409
A a = {}; は知ってたし、それが書ける状況なら書いてる。(まあ大概は値も書くけど)

A()はゼロ初期化なのか、知らんかった。

…ただ、一番書きたいのはゼロ初期化よりも任意値での初期化だなあ。
特にコンストラクタ初期化子とnew。最近のC++規格ではできる？

CでもC99からは A a = {0}; でゼロ初期化できる

A a = {.x = 10, .y = 5 } で特定のメンバだけ初期化できる（他の値はゼロ初期化）も便利

オブジェクト指向はクソか？
http://qiita.com/tokomakoma123/items/fb7530232912dc4176c4

お前らみたいなゴミが使うには十分過ぎる

人間ならばクソをする
美少女はクソしない
つまり美少女が人間を継承するのがおかしい

>>414
つ virtual

理解できないものに人は発狂するものなんだね

人間にうんこさせることはできる
美少女にはうんこさせられない
∴美少女クラスのうんこメソッドが呼び出されたら例外を投げればよい。

class Human
{
　　Human() { }
　　virtual void Unko()
　　{
　　　　/* Unko */
　　}
}

class PrettyGirl : Human
{
　　PrettyGirl() { }
　　new void Unko()
　　{
　　　　throw new InvalidOperationException("No pretty girls can excrete.");
　　}
}

だからうんこするなんてメソッド自体無いの

Humanから派生させるのが誤り
終了

>>419
これ
美少女は美少女であって人間ではない

人型基底クラスを作って派生だな。

生命体→動物（うんこ）→人間
　　　→美少女

こうだろ例え隠蔽しようが例外を投げようが美少女にうんこメソッドを持たせること自体が継承関係としておかしい

委託にすればいいだろ

わかったわかった
俺が結論を書いてやる

美少女クラスが全てのスーパークラスだ
人間クラスは美少女クラスのプロパティ値をブサイク側に落としたり、排便メソッドを追加したにすぎん

>>424
お前みたいなやつが設計してくれると助かるんだがなあ

>>424
おいおいおいキモヲタも美少女から派生したって言うのか

>>424
ナイスだねえ

このネタ、方々で妙に盛り上がるけど
よーく考えると、かなりキモイと思わんか

なぜオブジェクト指向で作るのか？
って本でも読んでみなさい
ベストかどうかはわからんがベターな手法がOOだってだけだ

>>428
美少女が万年便秘って話だもんな

みんなそろいもそろって美少女美少女って連呼しているのに
誰もそこにツッコを入れないところが、なんつーか、異常事態なわけだよ。

美少女という名前ならそう呼ぶ以外ないだろ
どんな生き物かみたことないけど

ある種のストレス発散法

美の少ない女

>>429
なぜオブジェクト指向で作るのか？って最悪ではないがわかった気にさせるだけのダメ本だろ

微笑女「ふっ」

メソッドはすべてinterfaceにすべきですか？

人間に排便メソッドを付けるのが間違ってんだろ

美少女の排便メソッドが外部（他人）からpubulic(呼び出せる)と考えると、ありじゃね？
privateだとしても、美少女インスタンスが他の美少女インスタンスの排便メソッドをコールできるんだぜ。ｽｶﾄﾛｼﾞｰｷﾏｼﾀﾜｰ
さらにｃ++だと friendクラスにしておけば男クラスでも美少女の排便メソッドよびだせるんだぜ。この美少女超ビッチ

結論から言うと、オブジェクト指向（美少女）は確かに愚かかもしれない。でも、ありじゃね？

>>439
たとえ同期メソッドで待ちが発生しても大量コールするわ

トイレの排便メソッドに人を渡す

>>441
人オブジェクトを渡されたトイレはそのオブジェクトをどうするんだ？

排便済みフラグを立てるだけだろ

そもそも美少女クラスを人間クラスから継承すること自体が愚かだと思うんだが

美少女判定クラスに人間クラスを渡す

クラス拡張にextendsではなくmutatesを使えばいい

ウンコ　排便(){ 便意 = 0; }

うんこを取り出すpublicメソッドを呼ぶものは無いだろう
あれは不定期のイベント処理だ

>>447
ウンコは不定値かよ

ウンコをリターンするの忘れてた
ウンコがイベント処理だったら催した瞬間ウンコ漏らしちまうから催すイベントの中でウンコ可能かどうかとウンコ我慢可能かどうかの判定をせにゃ

ウンコをリターン…

if( !排便 ){ throw 便秘(); }

ふむ。まずこの「排便」に()がついて無いのが気になった。
C#のプロパティ的な機能がある言語表現だとすれば、名前は「排便可能か(IsHaibenable)」一択だ
便秘はステートとして必要だと思う。だが、このステートを仕様に入れるのであれば、同時に別のステートに対する考慮を網羅する形で完成を目指したい。
痔に悩まされている二次元美少女とは事後の「爽快感」なり「苦痛」なりを返り値に返納する必要があるだろう。
ではHaibenResultクラスが必要だな。

そうだな、まずはこのクラスに何が必要か、ざっくりでいいので洗い出して貰おうかな？
頼んだよ、君には期待している。

()ないのはなんも考えてなかったからだわ
排便メソッドの戻り値はやっぱりウンコであるべきだ思う

// 疾病[編集]
// 排便がスムーズにできない便秘、便がもれてしまう便失禁、便が正常でない下痢などがある。また肛門部にできる痔などは排便時の障害になる。

便秘かどうかはをウンコの硬さと人間の筋肉の強さから算出するべきで例外にするべきじゃなかった
便失禁は人間の筋肉の強さ、下痢はウンコの硬さ
痔は肛門の状態であるべきで排便メソッドで参照してウンコの生成、排便の成否に使う

よってHaibenResultクラスはウンコで初期化して人間の状態を参照しながら便秘やら快便やらであるかどうかを見れるクラスであるのがいいと思う
人間は排便をした後HaibenResultから快便なら爽快感イベントを生成するなり人間の快感度に一定数値加算するなりする

でも美少女はウンコしないから

万年便秘が美少女になれるわけなかろう。

現実を見ろよ、排便メソッドが隠ぺいされてるだけだよ

>>456
排便メソッドはprotectedでpublicな浣腸、下剤メソッドから内部的に呼ばれるだけだよな

publicな排便メソッドの用途って何なのさ？

赤ちゃんなんか紙縒りでこちょこちょすると出ちゃうんですよ

排便メソッドの戻り値をeatメソッドに渡すことができれば
すべて丸く収まる

元々そのようにして宇宙船地球号は丸く収まってる。

>>459
ウサギはそうだったはず。
豚はhumanインスタンスの排便メソッドをeatメソッドで受け取る事ができる。

内蔵クラスが食物クラスを分解してだな

Eatメソッドの引数はfoodオブジェクトだからな
unkoオブジェクトだってfoodオブジェクト足りえるだろ

うるせーnullでも食ってろ

カロリー無いからいくらでもいけるわ

お前らが述べてるのは「ムカデ人間」クラスであって「美少女」クラスなどでは決して、ない。

>>463
直は無理だろ。
最低限、デコレーターが欲しい。

>>467
細かいことは気にするな。C スタイルキャストして口に突っ込んで知らんふりしとけ。

foodは食料であるべきじゃねーの？
口に突っ込めるものが全て食い物って主張するならこの世の物体全てはfood継承して多態性もってることになるぞ

Objectクラスでよくね？

Objectだと仮想物質、エーテルだのダークマターだのまで食っちまうぞ

DrinkメソッドとEatメソッドでどう分けるかだが・・・

カレーはDrinkメソッドでいいのか？

unk()で得たものはどっちだよ
どっちでもいいだろ？

まず原子核くらいから始めようぜ

メソッド名の先頭を大文字にして書くやつ何なの

public class ClassName
{
　　private string _fieldName;

　　public ClassName() { }

　　public void MethodName(int argumentName) { }

　　public FieldName
　　{
　　　　get { return _fieldName; }
　　　　set { _fieldName = value; }
　　}
}

公開するものはたいてい大文字で始める

俺が見聞きしたコード規約では大文字はクラス名か定数だな

C#とJavaとか、言語によってちがうのだ

>>475
.NETの開発者でござろうよ

>>476
このインデントスタイル苦手

>>480
if (foo1) {
　　bar1();　　　　　　//スクリプトとかに多いイメージ
} else if (foo2) {
　　bar2();　　　　　　//同上
}
else if (foo3)
{
　　bar3();　　　　　　//.NETかな？
}
else
{
　　if (foo4)
　　{
　　　　bar4();　　　　//特異
　　}
} else bar5();　　　　//死ね

オブジェクト指向になると名前付け規則が単なるローカルルールだって事を忘れるの？

Ruby「なんだって」

>>480
c#のデフォルトの自動インデントスタイルでしょ。
｛ が後ろに来なくて縦に長くなるので {hoge;} みたいなのも使う。

オブジェクト指向はソフトウェアのためだけにあるんじゃないから

>>479
.NET以外でもMFCとかがそう
いずれにしてもMS流
MFCの時はクラス名の先頭にCがついてたからまだ区別できたけどC#でそれがなくなり、名前空間、クラスメンバー、オブジェクトメンバー、の区切りが全部ドットになって最悪

インデント、最近はC++でもJavaScriptスタイルな括弧の位置が多いよ、Qtとか

ラムダ式の名無し関数とか一々改行してたら気持ち悪いし、括弧が多重になるので見易さにも拘りたい部分

>>486
IDEがあればプレフィックスなどたいして必要ではない

if (foo1)
{
　　bar1();
}

この括弧の位置がいいとされる理由に、} から
視線を上に上げていき { が見つかれば、そこがブロックの開始ってことで
わかりやすい。という意見があるが、

if (foo1) {
　　bar1();
}

別にこれであっても、視線を上にあげていき、文字が見つかった所が
ブロックの開始とわかるので、別に{ }の位置をそろえる必要はない。

理解できなければ、こうかけば、ブロックの開始がわかる。ってことが理解できると思う。

if (foo1) {
　　bar1();
fi

{ が冗長な一文字である。それだけのこと。

VS2008の頃はIDEのインテリセンスが気まぐれだったんよ

大括弧のペアをハイライト表示するIDEとかも有るよな

>>489
c風の{}構文は、K&R式が一番しっくり来る
ご本家には勝てない

おい排便問題はどうした

どっか行った

>>491
クロージャーを多用する現代では
K&Rの関数だけは{を次の行に書くというのは
時代遅れだな。

実際に我々の妄想では出来る事がコンピュータでは出来ない
オブジェクト指向を使っていると創造性が落ちる

>>494
そっちかいw
K&R式だとif, switchが縦長にならなくて良い。

おいおいお前らもっと真面目に美少女の排便問題について語り合ってくださいよ

どっか行った

美少女とかもういいよ
美少女とは何か、その定義が上流設計で曖昧なんだから論議はまとまらない
美少女が排便しないとか意味不明

ウンコしないよ

うんこしない美少女て具体的になんだよ
勿論人間でな

背理法なんだろう

美少女はウンコをしない
うんこをしない人間はいない
ゆえに美少女はおしっこをする。QED

美少女はうんこしないという段階で完全に設計ミス、上流設計から間違ってる

俺もウンコしないから美少女ってことになるな

【石川ってウンコするの？確認その２５０】
http://anago.2ch.net/test/read.cgi/ainotane/1271771699/

顧客が説明した要件
http://search.yahoo.co.jp/search?p=%E7%9F%B3%E5%B7%9D%E3%81%A3%E3%81%A6%E3%82%A6%E3%83%B3%E3%82%B3%E3%81%99%E3%82%8B%E3%81%AE%EF%BC%9F

haibenメソッドにアクセスするにはfriendにならないとね

結局のところメソッドなのかプロパティなのかイベントなのかハッキリしろ

friendになったからといって、任意のタイミングで排便させることができると思うか？
あれは定期イベント処理だ。

排便がイベントだと便所にたどり着く前に漏らすだろ

イベントは便意だなｗ

便意イベント発生　→　一定時間ふんばりメソッド非呼び出し　→　排便イベント発生
↓
ふんばりメソッド呼び出し　→　排便イベント非発生　→　便秘
↓
排便イベント発生

こんな感じか

便意はイベントじゃなくてカウンタ

人工肛門はどう表現するんだよ

adapterパターン

排便メソッドをオーバーライドして甘いクリームが出るようにすれば解決。

なんだ天才か

何だよオーバーライドって
そもそも排便メソッド自体を持ってたらおかしいっつーの

排便や喫煙は表向きあってはならない。

>>520
隠蔽しろ。

美少女がうんこしないのは、実は外見えだけはうんこしてないように見せかけているだけ
実は裏でうんこしている

これは許されるの？

ばれなきゃOK

俺の前ではウンチしてもいいから

新宿コマ前に行け

>>522
喫煙写真で炎上してたヤツとかいるだろ

物質というスーパークラスから
筆記用具や凶器のクラスを派生するべき

>>519
便を観察できなければ排便の証拠はないわけですから
証拠がない以上は推定無罪の原則にしたがいますので、
排便メソッドが存在すること自体は問題ないかと思います。
排便メソッドがnullを返せばいいのですよ。

>>524
ぶりぶりー

今からうんこしてくる

おきばりやす

>>528
nullが見えてる時点でダメ

ニュー速＋に、このスレ貼った人は挙手を！

継承をリアル系に例える奴は無能

なんで＋にはりまくってんだ。
つい開いちゃったじゃないか。そっ閉じ。

アナルセックスは？

undefined property 'anus' in class BeautifulGirl in excrete()

クラスは使えるヤツ。
C++にしたらCには戻れない。

>>76
これはマジ

>>84-85
http://kzho.net/jlab-giga/s/1403790339333.jpg
http://kzho.net/jlab-giga/s/1403790343645.jpg
http://kzho.net/jlab-giga/s/1403790351370.jpg
http://kzho.net/jlab-giga/s/1403790365926.jpg
http://kzho.net/jlab-giga/s/1403790072216.jpg
http://kzho.net/jlab-giga/s/1403790075792.jpg
http://kzho.net/jlab-giga/s/1403790079055.jpg
http://kzho.net/jlab-giga/s/1403790082172.jpg

【画像】　最新の後藤真希＆モー娘OGの方々ｗｗｗｗｗｗｗｗｗ
http://hayabusa3.2ch.net/test/read.cgi/news/1403791336/

>>91
最新の生物学だとティラノサウルスが生き残りを賭け省エネ進化した結果がニワトリだと言われてるからな。
基底クラスに全部を詰め込んで派生クラスは機能を削るのが正解なのかもしれない。

確かに人は尻尾を棄てたな。

>>1
＞オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。

排便メソッドをオーバーライドしてそのメソッドがコールされたら「女の子はうんこなんてしないもん」て喋らせればいいだけだろ

俺は髪を捨てた。
これは進化だ。

まず、うんこしない人間とか自然の摂理に反してる
ないものねだり

自然だろうが不自然だろうがモデル化できるならそれでおしまい

>>541
おもしれぇ･･･。
そういうカタチの進化もあるんだな。
たしかにプログラム続けてると、何でもできるけど重たいもんより、
必要最小限でサクッと動くものに快感を覚えるようになってきたな･･･。

>>547
コンピューターもアホみたいに小型化したからな。
人間も尻尾を棄てたし。

重要な機能を強化するのも進化だし、不要な機能を削るのも進化ってことだな。
依存関係が入り組みすぎて機能を削れない設計こそ愚かの極み。

>>547
そのためにも基底クラスはシンプルにしないといかんよな。
基底は必要最小限の機能。必要な機能のみを追加する。

無駄に複雑に作りたがる若手を撲滅したい
駆け出しの連中の自慰行為で誰が得するんだ・・・

やっぱり美少女は正しい進化を辿った人間なんだな

そういう意味では依存関係を持たず不要な関数をバッサリ削除できる純粋関数型こそ正しいのかもしれない。

>>551
無駄に複雑に作りたがる老害は撲滅しなくていいのかい？

老害はライブラリも使わず長々と書き下すのがシンプルとか思ってそうだよね。

>>550
深い階層構造こそ複雑な依存関係を生む諸悪の根元だ。
とIPのRFCに書いてあった。

>>555
車輪を再発明できるワシかっけけえええ

なんか最近、ココへのリンクを貼ってる奴がいるな。

そいつがどんな人物か、リンクで推測できるなｗ

お前だろ？何がしたいんだよ一体？

スリム化できなくなった結果がCOBOLやJavaの延命案件だからな
スリム化は次のキーワードかもしれない

動的に関数を消せる言語ってあるのか？
プログラマが手作業で消すんじゃこのスレの御題目には適合しないと思うんだが

動的に構文木を書けば
関数型言語の権威が来たようだ

アラン・ケイも関数型は完璧だがITドカタには理解不能だろうという理由でSmallTalkを作ったと言ってるくらいだからな。
愚民はオブジェクト指向で突き進むしかない。

そのSmallTalkがITドカタに理解されてないわけだがｗ

美少女もウンコはする

見たのかよ

観測された事実はないけど理論上はしてもおかしくない

ウンコしないよ

ウサギは朝一のウンコを食すそうだ。
ウンコも色々あるのかもしれない。

ぷろぐらまなら直接見えなくても論理的思考・洞察力と検証技術でカバーできる

eval を使う

>>565
美少女であることを観測していると同時にウンコをしていることを観測できないよ

class Unk extends Food implements Serializable {
　　private long quantity;
　　private Quality qualty;
　　...
}

誰か拡張してくれ
美少女がうんこをするのであれば、果たしてどのようなプロパティを持つのかを考えなければならない

神クラスから人間クラスと美少女クラスをそれぞれ派生させて
人間クラスにだけうんkメソッドを追加すりゃいいんじゃないの

神の定義は

属性が万能なんだけど具体的な機能の定義はない>>575

>>573
Serializableというキーワードみて、胃で消化された物が腸を通過するところを想像したぜｗ

人間のスーパークラスは遺伝子か？いや炭素かな？
まあここまでよく継承してきたもんだ

全知全能の神がウンコできないわけない

>>578
中性子と陽子と電子くらい

>>574
美少女もババアになれば普通の人間に戻る

美少女の年齢は定数

時間経過がないからウンコしないのも当然の帰結という事か

private int age = 49;
public int getAge() {
　　return 17;
}

>>584
きゃーうそつきメソッドよー

>>584
ワロタ
age宣言意味がねぇ

スレが上がったから意味あるだろ

>>584のクラス(KusoClass584)は永遠の17歳とかほざいてるクソクラスなため、
現在deprecatedとなっています。
本来の年齢をしっかり晒すようgetAgeを修正したサブクラスTadashiiClass584の
使用を推奨します。

public class TadashiiClass584 extends KusoClass584 {
　public int getAge() {
　　return age;
　}
}

エラー privateで宣言されたageをサブクラスからアクセスできません

>>589
ほんとクソクラスじゃねーかｗ

オーバーライドによる修正が出来なくて胃が痛くなるデスマパターン

面白いなこれｗ
間違った修正をしようとして泥沼にハマるパターンって、実際結構あるんだよな。
よくよく考えてみたら元の>>584が正解だったていうｗ

そもそも子クラスで親クラスを是正しようというのがお門違い
クラス継承はあくまで拡張するもので、バグ修正ではない
親が17というのなら、子は黙って従うのが筋というもの

意地でも永遠の17歳と言い張りたいのかよという部分は置いといて
ま、>>584が普通の実装だよね

class 美少女 : private 人間
{
以下略

これで人でありながら排便メソッドは隠された（ﾄﾞﾔｧ

class 俺 : 人間
{
　private 美少女[];
}

>>596
ぬるぽ乙

美少女の糞は食用可だから

class 美少女 : public 人間
{
bool CanEatShit() { return true; }
};

それだと美少女が糞食えるってだけじゃねえか。
実際にそんな風に間違った作り方してる人いるけどさぁ

それを言うならher shit is eatableだよ

食えるか食えないかで語れば、病気とか精神的抵抗を鑑みなきゃ食える訳だろ
ある属性立ってたらisDeliciousメソッドにtrueが返るべきだ
そうなるとshitは独立クラスのインスタンスとすべきだ。美少女がうんこの実装や内容を把握している必要はない
e.g.「あらやだ今日の私のアレにはコーンがこんなにも形を保って出てきたのね」なんてことがあってはならない
これは仕様から抹消すべきだ。関数型よろしく、副作用のない形で状態変数を排除することが望ましい
彼女は排便したという事実さえもなかったことにすべきなのだ。事実上は不可能ながら、外部がインターフェースに則ることでこの制約を記述できるのはご承知の通り。
すなわち我々が「あの子、今トイレに行ったって言ってたけどウンコなんかしないはずだよね！？」という混乱を正しk

いい加減きもいわ…。

美少女 akemi = new 美少女();
人間 ore = new 人間();
if (akemi.CanEatShit()) {
while (1) {akemi.Eat(ore.Haiben());}
}

3行で頼む

美少女 akemi = new 美少女();
人間 ore = new 人間();
if (akemi.CanEatShit()) { while (1) {akemi.Eat(ore.Haiben());} }

発注者は絶対神

nozomiからkanaeに移転

次は tamae か

このスレためになるわwww

>>605
意味が分かるだけにきもすぎる。

まあ、普通は、メソッドの最初の文字は小文字にするけどな

>>611
お前の普通は世間では通用しない

大文字派です。

>>605
akemiに俺の糞を食わせ続けるわけかwwww

美少女指向プログラミング

>>612
えっ？
ttp://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.2.3-method-names

メソッドのパスカルケースはC#のMSコーディング規約くらいでしか見ないな
他にもあるのかな

なるほどC#厨だったか。C#ってメソッド名UpperCamelCaseなのな…。
普通のメソッドがどうしてもコンストラクタに見えてしまうわ。。

C#も4.8％といい線いってる方だとは思うけど、上位4言語の関数/メソッド名はLCCだね
どっちが世間の普通かは言わずもがな
ttp://news.mynavi.jp/news/2014/04/11/456/

永遠に出し続ける方も辛そうだな。

西太后だっけか

>>620
Haiben() と Eat() が終わるまで次のループに行かないから心配する必要ないし、すぐに例外吐くかも知れない。

>>617
名前通り、Pascal系のDelphiでなら…
あとMicrosoftのライブラリはC++でもPascalCase使う傾向あるな

ちょっと待てよ。

ウンコは意思どおりに出ない事もあるだろ。
haiben()でウンコでなかったらヌルポじゃないのか？

もっと違う例外吐けよ

って言った手前ちょっと考えてみたけど
サブクラスAnusがIOException吐くくらいしかないのか
それもどうなのかな

うんこ出なかったら、IllegalConditionExcepcionを吐いておけ
これはチェック例外か？動かしてみなきゃわからんわけだしな……どうだろ

血が出る人とか子供出ちゃった人もいるしな

スカトロはスカトロサイトへ

>>628
ちょw

美少女は人間じゃないんだから継承関係なんか無いのが正しい設計。

何でもかんでも継承で片付くと思うのはOOP初心者。

美少女はクラスでなくインタフェースじゃないかなと思う

まあ抽象クラスだろうね

時代によって美少女の定義が変わるからね

結局実装する必要があるので、抽象クラスもインターフェースもめんどいっす

うんこする美少女と、うんこしない美少女を作るしかないの？
インターフェースは違うのに、中身が似てしまうのは、あかん設計だ…

美少女の聖性と性性

うんこしない美少女は観測者側の問題で美少女側の問題では無いだろ
美少女クラスの使用者が排便メソッドを一切使わず体内のうんこを握り潰せ

お前ら揃いも揃って未だに基本設計すら出来ないのかよｗ
それもこれもオブジェクト指向は根本的に物理の原理原則に基づいていないって事だろ

オブジェクト指向なんてやめて自然の法則に倣ったクアンタム指向プログラミング言語を作った方がいい

ウンコするは、汚物を体外へ排出。
ウンコしないは、汚物を体内へ蓄積。

どっちの方がキレイ？

そもそも美少女は人間じゃなくて神

>>641
便秘のオバチャンと、美少女のそれは根本的に別物だぞ。

なんだよこのクソスレ

文字通りのクソスレでﾜﾛﾀｗ

http://ideone.com/B6dqNn

これでよくない？

んー、それだとisBeautifulGirl()で詐称するGenericHumanの派生が発生して…
ってこんなクソスレで何言ってんだおれは

>>640
作らんでも一杯ある
http://en.m.wikipedia.org/wiki/Quantum_programming

作らなくても有るのではなく
作ったから有るるのだろう

ばよえーん

ふぁいやー

ヒャダルコ

ビデ男

七夕うんち

脱糞だ

変なおじさん
あ、変なおじさん