オブジェクト指向ってクソかよPart5
レス数が950を超えています。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/ >>850
そうかもな
つまり
オブジェクト指向を使っても使わなくてもデスマになる
でおｋ 残った事実は、マクドナルドとオブジェクト指向の両方が
世界から求められているという事実 オブジェクト指向が多くのプロジェクトで採用されている
これは事実
その多くのプロジェクトがデスマである
これも事実
オブジェクト指向がデスマを引き起こしている
これの検証はするべき >>853
3ヶ月ぐらい前だと思うよ
ちょうと近々行こうかと思ってたけど 僕の話はこれで終わりです、なにも期待しないでください マクドは世界一食べられてる〜ってネタは
あれ結論が美味しいになってるのが間違いであって
世界の需要に一番マッチしてるというのなら正しいんだよね。
結局の所マクドは世界一優れたハンバーガーなのは
間違いないので、その正しい結論を言ってしまうと
あの話はすべてが覆ってしまうんだよね 需要も価値も意味ない
問題は検索の上位に来るか否か 試しに処理の要旨をコメント化してみた
バイナリーサーチのプログラムをコピーしてコメント追加
短い二分探索のコードだけど徹底的に仕様なり要旨なりを残さないと何をやっているのか見失う
テキトーな英語をgoogle翻訳で推敲(意味が伝わるか不明)
バグはご容赦
C++
// Binary search returns key position or key addition position
// key is found, return position
// not found, returns insertion position
// if found, return is 0..len-1
// if not found, return is -1..-len
// illegal call for array size 0 is return -1
// if position < 0, insert position is (abs (insertpos) -1)
int bsf(int v,int *t,int len){
// ガード、要素数０で呼び出された時の切り分け
if (len < 1) return -1;
int right(len), left(-1), vval(v);// ON register?
while((right - left) > 1){//最小時要素数１、(1 - (-1)) > 1状態になる
int mid = right - (right - left)/2;//要素数１でmid = 0
int cval(t[mid]); // ON register?
if (cval >= vval){
if (cval == vval) return mid;
right = mid;
} else left = mid;
}
return -(right +1);
} オブジェクト指向を採用して完遂したプロジェクト数
オブジェクト指向を採用して完遂しなかったプロジェクト数
オブジェクト指向を採用せずに完遂したプロジェクト数
オブジェクト指向を採用せずに完遂しなかったプロジェクト数
を比較すれば明瞭かもしれない。オブジェクト指向を採用する側に
有能な人が集まりやすいという難点があるが >>864
> オブジェクト指向を採用して完遂したプロジェクト数
5件
> オブジェクト指向を採用して完遂しなかったプロジェクト数
1件
> オブジェクト指向を採用せずに完遂したプロジェクト数
0件
> オブジェクト指向を採用せずに完遂しなかったプロジェクト数
0件
職場でオブジェクト指向に頼らない案件がない。
学生時代、Win32APIとDXライブラリで非オブジェクト指向なプログラムを何度も書いてたけど...開発歴が300時間越える頃には非OOPに限界を感じたよ。
SONYや任天堂のゲームって何であんな品質を保てるんだろうって考えた結果、オブジェクト指向にたどり着いたよ。 オブジェクト指向は俺の股間に付いているのであって、オブジェクト指向プログラミングはどうでもいい！ ところでwebアプリはそもそもオブジェクト指向で書けないよね >>868
ウェブアプリの殆どはオブジェクト指向だよ
Railsとか C++20でコンセプトが入るところ見ると、インターフェースによって持つ特性を表明するという考え方はそんなに間違ってなかったんじゃないかな。
インターフェースはちょっと厳しすぎたのかもしれない。 操作主体が音を出せと命令する場合、命令されたオブジェクトがラジオであっても猫であっても、音を出すはず。
猫とラジオは継承関係にないはずだけど、それでも音は出せるので、どちらにも音を出せと命令できるはず。 >>869
オブジェクトの実装に要件定義が必要になると考えます
練習として二分探索のコードの仕様を記述してみました
本来、コメントの次はクラスの定義になります
要件定義ー命名ーリファクタリングこれの繰り返しが
オブジェクト指向にも必要だと思います >>870
教科書で教えてるような、is-a 関係などを用いたオブジェクト指向で「直接」書いていない ポテトチップスやカップラーメンは売れているが体に良いわけではない
売れていること使用されていることが必ずしも良い結果に結び付くとは限らない >>876
それはお前が書いてないだけだろ
フレームワークはオブジェクト指向だ >>877
それでいい結果になるものは何？
たとえ話じゃなくて、○○指向って言ってみな >>879
数が多い→正しいではない可能性があるということ
もちろん
数が多い→正しい
が正であることもある
つまり
「オブジェクト指向の有効性はわからない」
「オブジェクト指向の有効性またその逆を主張するためにはオブジェクト指向のプロジェクトとそうでないプロジェクトの成功数と失敗数が必要でかつその条件の正当性を検証することは困難を極める」
が現在の結論
それ以上でもそれ以下でもない
これを理解することで
それ以外の主張をする人間は全て詐欺師だと言い切れる >>880
お前のせいでオブジェクト指向はクソと言えなくなった まあ落ち着きな。オブジェクト指向の採用例が沢山ある、というのは「このスレでは」明らかに証拠として挙げられないよ
Java/Rubyを使っているからオブジェクト指向！という論理が成り立たないからね
これはOO肯定派から出てきた理屈だし、否定派もそれは認めている
あと、建設的になりたいなら、もう一度「OOとは何か？」を棚卸ししてみたほうが良い
昔は盛んに吹聴されていたOOのメリットの多くは、OO以外の方法でやることが増えている
継承はアンチパターンになっているし、多相性はむしろ関数型の方が得意だったりするから余計に オブジェクト指向の継承など特徴的な性質を考えると評価が分かれる
Cの構造体をクラスにまとめて名前の重複等を回避する
パッケージ補助機能と捉えると悪くないと思う >>882
なぜオブジェクト指向を採用するのか？
という質問をしています 難しい問題はどんな方法論を使って書いても難しいままだし
能力のない人にはどんな優秀な方法論を与えてもぐちゃぐちゃにする
この二点だけは間違えないな >>886
・再利用できるソフトウェアモジュールが作りやすくなるから。
・作業分担がしやすくなるから。 >>886
・たくさんのライブラリがそうできてるし、サンプルに従って書くとそうなる
・そもそも継承しないと使えない機能があって本当は嫌なのに引きづられる
実態はゴミ
モスのがうまい パッケージツール化というのは、他人がしょんべんをしていても自分はしないということ。
チンポはチンポでも、他人のチンポと自分のチンポは違うからだ。 チンポは俺というパッケージの中の、名前空間に属する固有のオブジェクトなのだ。 チンポは俺自身でありかつ俺の肉片であり、かつ独立した生き物である！ >>887
オブジェクト指向や関数型といったプログラミングパラダイムは
そういう意味では道具に近いのかもしれないね
包丁一つとっても使い慣れてる人とそうじゃない人とでは
できあがりに大きな差がでる >>886
JavaやC#といったオブジェクト指向型の言語のシェアが高くて
書ける人が多いから人を集めやすかったり
作られたものが多かったりするんじゃないかろうかと
ではなぜJavaが高いシェアを得るに至ったかというと
それ以前に覇権を握っていたC言語と文法が似てたからじゃないかなと
あと理解しやすかったとか少なくともC言語から関数型言語に移行するよりはハードルが低かった
しかもオブジェクト指向はなんか良いものらしいぞという
風潮が当時あって受け入れやすさがあったのだろうと思う >>894
マイクロソフト製品以外では、Javaくらいしか代替製品がなかった時代があったんだよ。 >>889
Q なぜたくさん採用されているのかを聞いておるのだ
A たくさんのライブラリがそうできてるし、サンプルに従って書くとそうなる
どういうことなの いわゆる業界標準(デファクトスタンダード)だな
え、死語? >>896
だから引きづられて使うことになってるだけってことだ 偉い人が採用したオブジェクト指向に
引きづられってこと？
結局採用するんだ。オブジェクト指向を >>899
そしてデスマになる
だからデスマになる
オブジェクト指向を疑え
メリットのない技術を信用するな >>900
「オブジェクト指向」を何に置き換えても通じるなw 悪魔の証明ではないけれども
オブジェクト指向がダメな理由を指摘できる人は
オブジェクト指向を使いこなしてる人に限られるんじゃないかな
限界を知らないと否定することは難しい
ろくにコード書かないで本だけ読んでわかった気になって
オレオレオブジェクト指向で無駄に複雑なコードを書く人が
出てくるのはどうにかならんもんかなと思う
まあかくいう僕もその道をしっかり歩んで来たわけですが >>900
オブジェクト指向以外で
まともに作れたソフトなんてごく僅かだよ 有名なソフトをいくつか言えばいいのに
こういうレスしか返せないわけだ >>905
Windows APIはオブジェクト指向ではない。 >>906
APIがオブジェクト指向じゃないだけでしょ？
Windowsはオブジェクト指向で作られてる Win32はC言語でオブジェクト指向を実践する良い例だね >>907
え？それは嘘やろ
なんかそういう証拠あるん？ CreateWindowとか見るとオブジェクト指向やなってわかる
第一引数が、ClassNameだったりするし、引数にhInstanceってあるし
オブジェクト指向を踏まえてるとしか思えない ClassNameもhInstanceも事実だけど？ とりま「オブジェクト指向」の定義…というか
暗黙のうちに前提にされがちな歴史的経緯を共有しとかないと
お互いに欠けてる部分の揚げ足取りの応酬に終始して議論なんか無理
たとえば定番の↓に書かれてることなんかは全て常識…ってくらいじゃなきゃダメだろう
https://qr.ae/TWsn7X Windows SDKでの開発はオブジェクト指向というわけではない。 オブジェクト指向って、文字通り「指向」なのだから、
指向しているかしていないかなんて正確に判定できんだろ
人によって違う
例えばfopenはオブジェクト指向と言う人もいれば言わない人もいる
そこに正解はないよ 雑多な実装を雑多なまま扱わないでオブジェクトに落とし込んで扱うって事やろ？
雑多なまま扱った方が速くて解りやすければそうすればいい
それだけの話じゃないのか Boochの定義が広く一般に使われてるオブジェクト指向の定義
「OBJECT-ORIENTED ANALYSIS AND DESIGN」
Object-oriented programming is a method of implementation in which programs are organized
as cooperative collections of objects, each of which represents an instance of some class,
and whose classes are all members of a hierarchy of classes united via inheritance relationships. >>906
仕方がないですよ、あれは C からコールすることを前提に作られているのだから… >>918
プーチは後にSmalltalkを経験してメッセージング寄りに宗旨替えしている いい悪いは別にしてカプセル化、継承、ポリモーフィズムの3原則が広まったのもBoochの本によるもの
Boochの定義は「継承を使わずADTを使うだけではオブジェクト指向とは言わない」と明記してるところに価値がある
あとは英語版のWikipediaの定義は平易でいいと思う
(また英語で悪いが日本語版の記述は駄目なので)
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects",
which can contain data, in the form of fields (often known as attributes or properties),
and code, in the form of procedures (often known as methods).
A feature of objects is an object's procedures that can access and often modify the data fields of the object
with which they are associated (objects have a notion of "this" or "self").
In OOP, computer programs are designed by making them out of objects that interact with one another. >>923
継承は要らない子といわれて久しいと思うのですが…継承、要らないんじゃないですか？ >>923
プーチはもとも継承のないAdaを使っていたからね
ともあれ経験した言語で主張が変わる定義はダメだろ >>924
継承といっても
・型の継承
・実装の継承
・状態の継承
があってそれぞれ必要になることあるじゃんじゃあ残しましょうよ
むしろリスコフの置換原則がいらんのですよ 英語ばっかりだし
アメ公バカだから他人の商売邪魔しないじゃん（それが例え詐欺でも）
イスラム圏の方の意見とかも聞きたい >>925
オブジェクト指向プログラミングは、「オブジェクト」の概念に基づいたプログラミングパラダイムです。
オブジェクトにはデータを含めることができます。
オブジェクトにはコードを含めることができます。
オブジェクトの特徴は、オブジェクトのデータにアクセスするコードです。
OOPでは、プログラムは相互に作用するオブジェクトで設計されます。
言ってることはまとも 貧血ドメインがーとかクラス名は名詞がーとか
オブジェクトに知性をもたせるんだーとか俺のちんぽがーとか
そういう設計論が入り乱れてオブジェクト指向が闇鍋みたいになってる
オブジェクト指向自体はシンプルなんだよね >>927
やってみた結果ダメだった
経験から学んでいるんでいいんじゃないか? >>928
＞むしろリスコフの置換原則がいらんのですよ
驚きました、継承にするか移譲にするかの重要な判断基準そのものを否定するとは、私には暴挙にみえますね
＞継承といっても
＞・型の継承
haskell の型クラスを思い浮かべましたが、これにはリスコフが厳密に当てはまりますね、というかリスコフが当てはまらない型クラスなんて使えない…
＞・実装の継承
最近、簡単なお題で、移譲と実装継承の両方をやって比較してみましたが、継承による実装の継承では、基底クラスへのキャストという無様な記述が排除できないことがわかりました
これは継承より移譲の方が紛れが少ない、やっぱり継承は要らない子なのではないでしょうか？
https://mevius.5ch.net/test/read.cgi/tech/1573094136/943,960 https://ideone.com/y3ROXS
https://ideone.com/CeQlSq
＞・状態の継承
これはコードで記述するとなればどのようになりますか？ >>902
これだわ。
staticおじさんが叩かれた理由もそれに関係しそう。 否定する理由にオブジェクト指向でも避けられている
実装の継承、状態の継承をあげて叩きまくる記事を見ると
使いこなしているのかなと何とも言えない気持ちになる >>934
君は継承は要らないって立場なのだから継承か移譲かの判断をリスコフの置換原則で行っているとするならば
継承が要らないものならばその判断基準であるリスコフの置換原則も要らなくなると思うのだけれども
Javaで話をするけど
型の継承はインターフェースの実装が例
AbstractListがListインターフェースを実装してるような
実装の継承はArrayListがAbstractListを継承してるのが例
indexOfなどのコードを引き継いでる
状態の継承はHashMapがAbstractMapを継承してるのが例
keySetやvaluesといったデータを引き継いでる
継承の目的は型の継承を使うことでそれを使用するオブジェクトに
影響を与えないようにすることと、実装の継承を使って差分プログラミングで
コードを共通化して管理しやすくすることの2つに大別されると思ってて
リスコフの置換原則は型の継承では必要だろうけど差分プログラミングでは
必要ないと思うんだよね 僕はBtoBのWebアプリをいくつか作った経験がある
開発の規模は20人程度
プロプラなフレームワークを使って誰が担当してもある程度の
品質は担保されるようにはなってはいるのだけれども
プロジェクト固有のデータや共通の処理があって
そのために抽象クラスを作って各担当者に継承してもらうってことやった
修正があってもコードは集約されてるから修正しやすかった
リスコフの置換原則は意識してなくても継承が役に立つことは
あるんであまり原則とか気にするものじゃないと思った
状況に応じて良い悪いは変わってくるので
継承は良いものだ悪いものだって考え方ではなくて
どういう目的で継承を使うかってことを考える方が大事だと思う >>933
プーチ個人の成長としてはそれでいいけど
議論のベースにする定義には使えないだろうって話だよ
その後「結果ダメだった」って刷新されているんだから
（刷新後のものを使うならともかく） >>928
チンポは随意筋であり不随意筋であり、これはオブジェクトの多重継承だ。 >>941
オブジェクト指向は俺の股間に付いている！ >>934
素数のプログラム例について
Javaだとsuperというキーワードが使えますよ
https://paiza.io/projects/_vWOZhOW1Qsbn1-DTxVqfQ
この例だと僕も委譲を使いたいです
委譲なら間違って状態を破壊する恐れがありませんから
多態性が必要ならSieveのインターフェースを切ればいいだけですからね >>943
繋がっているけれども独立している、これがオブジェクト指向。 >>944
ありがとうございます。java コードをみました！C++ の知識だけでも十分に理解できます
C++ にはない super は便利ですね、ただ super は一行目／最初にしか書けないのは残念なところです
static class SieveExt extends Sieve {
private static int size(int n) {
for (var i = n; i > 0; i--) {
var r = index(i);
if (r != 0) {
return r;
略
これは、もとの C++ 関連スレへの質問と関連があります。
このプライベートメソッドは、私はメソッドとして書きたくない、という意向があり、C++11 では私はメソッドを立てずラムダ式で書いておきました
なぜならば、この部分は一箇所(SieveExtコンストラクタ）からしかコールされないから、その一箇所にまとめて書くべきだと思っているのです >>946
なるほど、Javaだとどうしようもないから
コンストラクタの代わりにstaticのファクトリメソッドを作るかな チンポは俺の体のコンポーネントであり、かつ独立している！ カプセル化というのはオブジェクトの独立性であり、チンポが勃起してシコシコするのは本人の意思ではない！ レス数が950を超えています。1000を超えると書き込みができなくなります。
