オブジェクト指向ってクソかよPart5
レス数が1000を超えています。これ以上書き込みはできません。
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
前前前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前前前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/
前前スレ
オブジェクト指向ってクソじゃねぇかよPart3
https://mevius.5ch.net/test/read.cgi/tech/1542884872/
前スレ
オブジェクト指向ってクソじゃねぇかよPart4
https://mevius.5ch.net/test/read.cgi/tech/1556462315/ >>943
そう思ってるのはお前くらいだから。
つーか、お前、普段何を開発しているんだ？ >>952
システム開発経験なぞ無くても、オブジェクト指向は俺の股間に付いているんだよ！ >>952
お前こそ>>942のちんぽを有効活用してるのかよ なんでも動的にやることが偉いと思う馬鹿が増えただけ。 >>957
オシッコは本体と繋がっている静的メソッド、勃起は独立した自己完結型の動的メソッド。 膀胱の中にオシッコが溜まって尿意がする、それはグローバル変数である。 オブジェクト指向の無いシステム開発は、勃起しないチンポと同じだ！ <オブジェクト指向>
宇宙間に存在する千万無量の物体がけっして各個別々に独立自存するものではなくて、
たがいに相依り相待ってひとつの組織体をなしていることを表示するものである。 チンポは自らの意思で勃起するが、勃起することをそのまま関数オブジェクトとして扱うこともできる。 「チンポがシコシコする」とは、釈尊によって見出された普遍の道理なのである！ 半年前位からPythonをネットで勉強し始めたんだけど（PG未経験）
最初は手続き型でコード書いて、途中からオブジェクト指向もやってみましょう 的な流れ
今迄は 短く簡潔に を意識してきたつもりなのに・・・何でこうなるん？抵抗がある
少し間を間置いてやって、再度やってみたけどイマイチ理解しづらい
途中から切り替えるんじゃなく、最初からオブジェクト指向で習い始めれば良いんじゃネ PythonやRubyのライブラリは強力だからね
オブジェクト指向じゃなくても大体のことはシンプルに解決可能 >>965
プログラミングのスタイルっていうのはいくつもあるんだよ
場合によって違うし、どれでも使える場合もあるし、どれかが最適な場合もある
必ずしもオブジェクト指向が適切なわけではない。ただしオブジェクト指向が適切な場合が多い
だから複数のスタイルを学ぶことには意味がある。
なんで最初手続き型からやってオブジェクト指向なのかというと
オブジェクト指向の方が覚えることが多いから。いろんな機能が増え
歴史的にもオブジェクト指向の方があとで登場した
30年ぐらい前はほぼ手続き型といっていいし、そこから新しく登場した
オブジェクト指向を導入するという流れで、オブジェクト指向を後で勉強するという流れを
今までの人はずっとやってきた。それを受け継いでいるから、
みんな手続き型をやってオブジェクト指向をやるのが当たり前になってる。
オブジェクト指向でも短く簡潔に書くとういことは変わらない。
君はまだコードの行数でしか簡潔かどうかを判断できないのだろう
短く簡潔に書くべきものは動く処理。テストする対象。オブジェクト指向で増えてるのは
処理ではなく定義。関数定義やクラス定義など。これらは動かない。
そういう定義があることで人間が理解しやくなり大きく複雑な構造を持ったシステムが作れる。
だからオブジェクト指向で短く簡潔だったものが複雑になったわけではない。
新たに構造を表す概念が増えた。概念が増えるというこは勉強するものも増えるので
オブジェクト指向の学習があとになるのは必然 オブジェクト指向は大きく複雑なシステムを完結にするものだから
学習最初レベルの短いコードではオブジェクト指向が理解できないのはよくある話。
一人で作ってるシステムを作るのではなくその何倍も大きな物を
複数の人が協力して作ると考えれば、少しでは負担を彫らすために
あったら良い機能ばかりであることに気づくだろう >概念が増えるというこは勉強するものも増えるのでオブジェクト指向の学習があとになるのは必然
>学習最初レベルの短いコードではオブジェクト指向が理解できないのはよくある話
誰でも通る道なんですね
先に進むと見えるものがあるかも知れないので もう少し頑張ってみます ありがとうございました >>969
ttps://i.imgur.com/Y1JgMDU.gif たとえばGUIのクラスライブラリって
継承によってうまく表現されてる例じゃないかな？
おまえらどうおもう？
java.lang.Object
java.awt.Component
java.awt.Container
javax.swing.JComponent
javax.swing.AbstractButton
javax.swing.JButton
継承関係の無い状態にくらべて
ある場合の上記のような構造が
コード全体を理解する助けになってる気がする イベントリスナを持つことと、
他のGUIを複数載っけてリスナ集約することを上手に設計してると思うよ >>971
チェックボックスとか
テキストボックスとかってどこに所属するの？ 継承関係の階層構造って、整理した気になるだけで実態把握には使えない
元のクラスを一部改変した派生クラスを楽に作りたい、というのは分かるんだけど、それ以上の意味（is-a関係とか）を提示しちゃうのは良いの？ってなる
例えば>>971で言えば、JButton <: Containerだけど、本当にそれでいいの？ってなるし、
ボタンの特性だと万人が想像する「クリックしたときに何か起こせる」って、他のComponentでもできる
でよく見るとActionを介して制御できるってあるけど、Actionに関する機能は>>971の継承関係とほとんど関係が無い
他にActionが使えるコンポーネント、どこにどれだけあるかすぐ分かる？俺には分からない
「継承でこんなにシンプルに表現できる！OOP凄い！」って思ってる頭で、同時に「奥深い！こんなこともできるなんて！」と思ってない？
俺はそんな分裂症気味の精神を持ちたくないし、traitを知ってしまったのでいよいよ利点が分からない >>974
意味がわからんっていうか、お前が分かってないだけじゃないか
> 元のクラスを一部改変した派生クラスを楽に作りたい、というのは分かるんだけど、
派生クラスという用語を使うのはやめろ。それは差分プログラミングだ。
そこでお前が言うべき言葉は「元のコードを一部改変した差分プログラミングをしたい」だ
派生クラスは差分プログラミングに含まれるが、派生クラス＝差分プログラミングではない
> それ以上の意味（is-a関係とか）を提示しちゃうのは良いの？ってなる
差分プログラミングをした結果is-a関係ができてしまう、のは間違いに決まってるだろ
派生クラスを作った結果、is-a関係になるのではない。因果関係が逆になってる。
is-a関係を提示したいときに派生クラスを作るんだよ
オブジェクト指向というのは「この何を提示したいか？」を（より多く）コードの中に記述することができる
お前はまず動きそうなコードを書いてしまってる。
何をしたいのか（設計）をコードで記述するというレベルに達していない。 >>974
> 例えば>>971で言えば、JButton <: Containerだけど、本当にそれでいいの？ってなるし、
お前が設計を読み取れてないだけ
オブジェクト指向は現実を表現するためのものじゃない
それを見れば（現実ではなく）「Javaのswingでは」JButtonはContainerの一種として
作られていることが、設計から読み取れる。
例えばHTMLでは、<input type="button">はコンテナの一種ではないが
<button>その他</button>はコンテナの一種だろう
同じボタンでもコンテナタイプと非コンテナタイプが考えられる
お前は現実世界のボタンはどうなんだろうか？って考えてそれでいいの？って思ってるんだろうが
オブジェクト指向は現実世界を表現するためのものじゃない
継承関係から「JButtonはContainerの一種として設計されてる」という事実が読み取れる。
これが重要なこと 念のために言っておくが
「ボタンはコンテナの一種として設計するのは正しいのだろうか？」という話はしてない
「継承関係から設計が読み取れる」という話をしてる
「継承関係から設計が読み取れる話」と
「継承関係から設計を読み取った結果、この設計は正しいのだろうか？」というのは全く別の話
設計が間違ってるなら設計が間違ってるってだけの話だろ。
それは継承関係を用いた「設計の一例」の話であって
継承関係で設計が表現できるという事実とは何の関係もない
そもそも継承関係で設計が表現からこそ、その継承関係だけを見て設計の正しさを議論ができわけで
継承関係をコードとしてかけるというのは、素晴らしいことの証明になってるだろ 長方形正方形問題から察するに、実装の継承は問題点が多い。 >>976
>お前が設計を読み取れてないだけ
>オブジェクト指向は現実を表現するためのものじゃない
夢の世界？ 「現実を表現するためのもの」である
と主張して憚らない人たまにいるよね
マジなんかネタなんか最後までわからんけど オブジェクト指向ではカモノハシを表現できないとかなｗ
カモノハシを表現するための道具じゃないからｗｗｗ 僕オブジェクト演算子を作った人だけど
恩師に褒められた部分は
開発環境でのプロパティのアシストが便利で楽
だけ 恩師って無名の素人やろ？ｗ
あ、大学で有名とかそういうのはいいから
ソフトウェア業界で名前が知られてるかどうか 恩師はC89の開発者の一人
名前を知られているかはわからない 結局必要だったのはネームスペースの閉じ込めだけだったのに
余計なことしてくれたという感想しかない。 正しさを人が議論しなくちゃいけない、それが継承の限界だよ。俺はフツーに数学とコンピュータの力を借りる。 >>976
Sunが作ったGUIフレームワークという事前情報があるから
安心してクラス階層から設計を読み取れるんだと思う
例えば俺（または経験不明の第三者）がオレオレGUIフレームワークを作って同じクラス階層を提示したとすると、
継承の使い方が間違っていてそのフレームワークが実現したいことは
そのクラス階層で正しいのかという疑念がどうしても拭えないだろ？
考慮されたクラス階層ですという保証がない限り、
クラス階層から設計を読み取っても疑念が残る、
または、バグに繋がるケースがある
>>971 はそういうことを言いたいんだと思う
単純な例だとC#のApplicationExceptionとか、
昔はユーザが作る例外はApplicationExceptionを継承するべき、
現在はMSのライブラリチームの人がクラス階層間違って使ったせいで継承するべきでないという方針転換してるが
クラス階層は互換性からそのままになってる >>987
> 例えば俺（または経験不明の第三者）がオレオレGUIフレームワークを作って同じクラス階層を提示したとすると、
> 継承の使い方が間違っていてそのフレームワークが実現したいことは
> そのクラス階層で正しいのかという疑念がどうしても拭えないだろ？
継承に限らないよね？
お前が書いたコードがクソで、そのやり方ではうまく動かないかもしれないし
メンテナンス性が悪いかもしれない
そして>>977の話に戻す
> 念のために言っておくが
>
> 「ボタンはコンテナの一種として設計するのは正しいのだろうか？」という話はしてない
> 「継承関係から設計が読み取れる」という話をしてる
お前のクラス階層が正しいかどうかの話はしてない
「継承関係から設計が読み取れる」という話をしてる 何を読み取れるのって話をしてるんじゃないの？
YはXのサブクラスとしたとき、「YはXの状態と振る舞い全てを持っている」以上の意図は込められないのに、「いやY is a Xだ！」って余計な意図を撒き散らしてる
まずどういう視点でis-a関係なのかの説明が必要だし、別の視点で見るときにそのis-a関係は無価値になる
提示できているかどうかが疑われる方法を使って、提示している知識の価値が低い。そんな不便な道具を使っちゃ駄目だ > YはXのサブクラスとしたとき、「YはXの状態と振る舞い全てを持っている」以上の意図は込められないのに、「いやY is a Xだ！」って余計な意図を撒き散らしてる
だから因果関係が逆。
自分でサブクラス作ったことないでしょ？
他人が作ったサブクラス見て、あーだこーだいってるだけでしょ？
はじめに世界がありました。はじめにサブクラスがありました。じゃないんだからさ
最初はなにもない。なにもない所にサブクラスを作り出す。
Y is a Xとしたいと思ったときに、YをXのサブクラスにするんだよ
そうすると状態と振る舞いもついてくる
なんで、とりあえずサブクラスでなんて考えるのかな？
理由なしにサブクラスになんかしないだろ > まずどういう視点でis-a関係なのか
そんなもん、（自作、既存問わず）フレームワークやライブラリがあって
そのフレームワークやライブラリはクラスを親クラスとして扱う。
それをサブクラスで拡張やカスタマイズできる。
そういうことをしたいときにサブクラスにするに決まってるじゃん
それ以外に理由なんかあんの？理由なんてたった一つなのにそれを説明しろだなんて
お前がその一つの理由を知らないだけとしか思えんが オブジェクト指向とか便利かもしれないけど
普通にクラスのデザインが不味いとオブジェクト指向とか関係なく放棄されるから
オブジェクト指向であっても普通にクソコードは生まれる
免罪符的な何かを期待してもむりじゃね？ >>992
当たり前だろ。なんでできないやつ、素人用の道具だと思ってるんだ？ OOPの概念 ←難しくない
クラス設計 ←難しい
クラス設計が難しい事を自覚すること ←不可能レベルで難しい
クラス設計が難しい事を自覚することなくOOPを批判 ←ありがち 逆じゃねえよ作らねえと分からないのがソフトウェア開発だよ
最初に考えた設計じゃすぐに駄目になるから身軽じゃないといけないし、想定外の使われ方をするから防衛的にしなきゃいけないんだ
そんな世界で、後から変更しづらいことが作る前から分かってる道具を使う理由は何だ？
クラス階層は時間で腐る。最初のロクでもない思いつきがずっと残る。作った奴の意図がコードに込められないから用途も目的もブレる。
継承の階層構造から読み取れる意図なんて幻想だファンタジーだフィクションだ。嘘じゃねえよどれだけ世の中にそびえ立つクソがあるか知ってるだろ？ クラス使っていても特に変更しづらいことはないし何いってんだこいつ？ >>995
よく入門書に書いてあったのは
設計書をプログラムに反映するためのオブジェクト指向のハズだったよな？ >>995みたいなのって、設計もせずにいきなりコード書くんでしょ？
だから、コードを共通化したい＝サブクラスじゃぁっていきなりサブクラスが出てくる。
そしてYはXの状態と振る舞いを全部持ってるだけだ、Y is a Xという意図はない！
あとから意図を聞かれてごまかしてる。
最初に設計（意図）をして、それがY is a Xであるときにサブクラスにする
コードを共通化したいときにサブクラスにするのではない 設計もせずにいきなりコード書くから作らないとわからない
すぐにだめになる。全部書き直し、それはクラスだからみたいな意味不明な結論を持ってくる
最初の設計が破綻してるだけ。そもそも設計してないんだろうがな
最初のロクでもない思いつきでコードを書いてるからそうなる
自分が意図を込めてないから、用途も目的もブレる。
そして相手も意図を込めてないと思ってる。
何も意図を込めてないコードから、意図なんて読み取れるわけがない。
意図が読み取れないのは、書いたやつがクソだけ
世の中にあるクソコード一つが>>995が書いたコード このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 92日 5時間 37分 22秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
