1002コメント398KB

オブジェクト指向って不自然な文法だよな [無断転載禁止]©5ch.io

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2017/03/08(水) 08:06:52.93ID:4wFxBa4i

忌み嫌ってるGotoとそう変わらない
やはり関数型が人間の思考ルーチンに合ってる

0232デフォルトの名無しさん

2017/03/18(土) 21:30:40.08ID:+lFcCe0u

おっと、比較演算子に = 使ってしまったよ。ミス

0233デフォルトの名無しさん

2017/03/18(土) 21:32:28.62ID:+lFcCe0u

しかも、文章読み間違えてた…

>逆に自然な文法ってなんだろう?

自然な方だったのか…

0234デフォルトの名無しさん

2017/03/19(日) 15:25:04.40ID:N+O/v//a

こいつの場合は天然だな

0235デフォルトの名無しさん

2017/03/19(日) 15:36:36.03ID:raX1f6fl

>>231
芸術的に汚いソースだな

0236デフォルトの名無しさん

2017/03/19(日) 15:41:17.57ID:raX1f6fl

処理のシーケンスとプロシージャ分けが未完
例外クラスがおなじなのに、外に分岐とかキャッチの後にフラグ変数メンバーを参照して分岐を容れるコードになるのが想像できる。

0237デフォルトの名無しさん

2017/03/19(日) 15:50:29.65ID:raX1f6fl

>>224
美術の実存と抽象画や、近代数学と現代数学と似た話じゃないかな
どちらがより価値があるか？という話。
前者は好みにより、後者は学術の目的と遂行合理性に価値がある、という考え方に落ち着く。

具象で語った方がわかりやすい。
抽象で語ると応用(具象化)しやすい。
そういう観点で、今の議論を語るときに、どちらがより合理的か？という思考が漏れているだけじゃないかな

0238デフォルトの名無しさん

2017/03/19(日) 17:25:11.95ID:cBsMWJ0a

全ての言語はマシン語の為のシンタックスシュガー

0239デフォルトの名無しさん

2017/03/19(日) 17:29:05.99ID:cZv/h/BX

可搬性とか型とかスコープの制限とか処理や変数の名前とかオブジェクトとか
断じてシンタックスシュガーではない
機能だ

0240デフォルトの名無しさん

2017/03/19(日) 17:31:17.62ID:cBsMWJ0a

でも最後にはマシン語におちるんだよね

0241デフォルトの名無しさん

2017/03/19(日) 18:25:06.46ID:cZv/h/BX

同じ記述が何通りかのマシン語に対応してたり、マシン語でエラーにならないところをエラーにしてくれるのは
シンタックスシュガーとはいわないだろおおお？！？

0242デフォルトの名無しさん

2017/03/19(日) 21:50:27.27ID:cBsMWJ0a

人間が判りやすいようにしてるだけだね

つまりわかりにくい言語は意味がない
パズルとしての目的以外

0243デフォルトの名無しさん

2017/03/19(日) 23:01:25.25ID:CwtOi7dG

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

0244デフォルトの名無しさん

2017/03/19(日) 23:53:17.26ID:T+JU6hX2

>>243
ソースコードをソースファイルのどこに記述するか?ということを決める技術なのでなんの生産性もない
別にどこだって動くし、大失敗してもかけた工数が無駄になるだけで
動かないわけじゃないというある意味優秀な初心者ホイホイ

0245デフォルトの名無しさん

2017/03/20(月) 03:34:58.33ID:5McFn4oo

「分かりやすい」と言うのが話をデタラメにするんだけど、プログラミング言語に求められるのは、抽象的なプログラマーの思考についてこれる言語。
人間の一時記憶は平均で7個とか言われるけど、これで複雑な処理を把握するために、どれだけ複雑な概念を名前を付けて扱えるかだ。
オブジェクト志向はまあまあだと思うけど、「デザインパターンはバッドノウハウ」と言われた時は衝撃的だった。
やりたい事がズバリできず、なんか色々クラスを作らされるのは確かにイライラする。

0246デフォルトの名無しさん

2017/03/20(月) 04:02:56.96ID:UB8UMXbl

わかりやすいかどうかではなく、不可能かどうかだよ
ある程度複雑なプロジェクトは構造化しなければ完成することが不可能
その構造化の一方法論がOOP

0247デフォルトの名無しさん

2017/03/20(月) 04:55:33.25ID:Kbki2X9l

オブジェクト指向ってのは構造化の方法論だろうけど最初に発明した奴らからすれば自然でピッタリくる書き方だったろうと思うのさ。
何かうまいやり方は無いかなって苦労して行き着いた“事案“はまさにオブジェクト指向にピッタリだったんだろう。
ところが、その後それに飛び付いた奴らは何でもオブジェクト指向になってしまった。
結果、無理して不自然なものとなってる気がする。

0248デフォルトの名無しさん

2017/03/20(月) 08:50:06.85ID:+yYy+wGo

オブジェクト指向とは何だったのか？
https://ubiteku.oinker.me/2016/05/09/what-is-oo-all-about/

オブジェクト指向はその出自から考えても分かるように、
より上流の考えを重視する目的指向のパラダイム

0249デフォルトの名無しさん

2017/03/20(月) 09:10:40.65ID:GWfrNwZR

>>246
オブジェクト指向じゃなきゃ作れないものなんて
この世にひとつもない

0250デフォルトの名無しさん

2017/03/20(月) 09:35:31.43ID:UB8UMXbl

>>249
だから構造化すなわち分割の一方法論だっつの

0251デフォルトの名無しさん

2017/03/20(月) 09:40:15.43ID:ub4me4bd

OOPたって構造化の延長線上に過ぎないよね
言語機能の支援を受けられるかどうかは全く別問題

0252デフォルトの名無しさん

2017/03/20(月) 09:49:55.73ID:LXO+ChBL

アプリケーションに依るんだろうね。
ちょっとしたデータ加工なら、関数型の方が小回りが利くし直観的で分かりやすい気がするけど、どうでしょう？関数でデータを加工していくって分かりやすい。
簡単な自然言語処理をスクラッチでHaskellでやったらやりやすかった。
でも、Winとかにある巨大アプリケーションは関数型じゃ無理だと、本格的なOOPはよく知らないが漠然と分かる。

0253デフォルトの名無しさん

2017/03/20(月) 09:52:16.44ID:LXO+ChBL

エンジニアが自分の仕事においてちゃちゃっとプログラミングの恩恵を受けるには、関数型をできた方がいい気がする。

0254デフォルトの名無しさん

2017/03/20(月) 10:15:06.98ID:hQstaLGU

基本的に「作る俺にとって」より楽な方法として各自プログラムをぶち上げていくのだから、結局マシン語に戻って何がどうしてこうなってるのかを知ってたほうがいい
つまりは歴史なのだけど、そこらへんのところ解説してる本を知らない

0255デフォルトの名無しさん

2017/03/20(月) 15:43:06.47ID:Dwi+wvJ0

>>248
Erlangこそメッセージングを体現していて、Smalltalkはニセモノのウンコってことか

0256デフォルトの名無しさん

2017/03/20(月) 16:04:38.37ID:EOJWC60m

この流れってなんかネットでデジャブあるなーと思ったら
総合格闘技とかいうスポーツの観るだけファンが
伝統格闘技に相手のスタイルも知らずに絡んでるアレだw

そもそもオブジェクト指向はもともとわりと巨大なスケールを想定していて
ぶっちゃけネットワークで接続されたコンピューターに処理を投げて動作するぐらいを考えて提唱されてるから
相手の処理終了も不明だし、いちいち処理待ちなんてしてたらネットワークが止まるから
『命令を投げたら単位が自律的に処理を行う"オブジェクト"を区切りにしよう』というものなのに
C++おじさんは思考がぜんぶ「シングルCPUで俺がすべてわかってるからいちいち命令とかいらねぇよ」って
自分の世界の話しかしない(できない)…w

0257デフォルトの名無しさん

2017/03/20(月) 16:21:55.31ID:trp03LGJ

でも実際現場でもっとも頼りになるオブジェクト指向の性質は隠蔽だし
メッセージ指向とかいってたらこんなに流行ってないよね

0258デフォルトの名無しさん

2017/03/20(月) 17:12:26.23ID:GbEM94zj

隠蔽なんてネームスペースやパッケージで実現できるよね

そのうえにクラスという概念をもってきたから、くそなんだよね

クラスっていうのはミニグローバル変数みたいなもんなんだよ
つまり普通のモジュールよりも正確にドキュメントを残す必要がある

結局内部状態を隠蔽するのはいいけど、正確にそれをドキュメントに記述する義務がないからオブジェクト指向はくそなんだよ

ドキュメントを書かないくせに、内部状態を隠蔽されたらそのライブラリをどうやってテストするんだよ

0259デフォルトの名無しさん

2017/03/20(月) 17:20:00.82ID:G9+XvfW+

>>258
>隠蔽なんてネームスペースやパッケージで実現できるよね

データと処理の結びつきの程度の違いなんだよ
オブジェクト指向で作るかどうかは用途に合わせた道具の選択の問題
Photoshopみたいなグラフィック系アプリのGUIを関数型で作ったりしないだろ？

0260デフォルトの名無しさん

2017/03/20(月) 17:30:51.74ID:GbEM94zj

オブジェクト指向の発明は、
昔write(console,"A")
とかいていたものを
console.write("A")と倒置して書くことにした
それ以上の理由はないし、これはむしろ退化なわけで

例えばwriteのシンタックスなら、第一引数にlistを指定してブロードキャストに拡張することは容易だろう
write([console,file,webstream],"a")

consoleを絶対的な主語としたことによってこれは自然な手続きではなくなった

まずlistをローカル変数として定義し、foreachでそれをまわすということになるだろう

つまりオブジェクト指向によってコレクションタイプに対する関数の拡張性が制限されるためにforeachが必要になるわけだ

0261デフォルトの名無しさん

2017/03/20(月) 17:38:42.83ID:GbEM94zj

>>259
それは正確じゃないよね
ハイパフォーマンスを要するGUIをJavaやC#みたいな言語で作らないよね
もちろんsun.misc.unsafeみたいなのを使うなら作れるだろうけど

関数型の前提と、directXのようなライブラリの前提を理解した方がいい、メモリに対する考え方が違うだけで、mutabilityとポインタアクセスを許す書き方をしていいな
ら関数型言語を使ってもかける

一般的なオブジェクト指向ってのは行数においても、パフォーマンスにおいてもメリットがないよ

0262デフォルトの名無しさん

2017/03/20(月) 18:07:38.45ID:G9+XvfW+

>>261
おまい文脈理解しろよ
データと処理の結びつきの程度の違いって言ってんだろ

0263デフォルトの名無しさん

2017/03/20(月) 18:32:40.96ID:GbEM94zj

型に対してメソッドが従属するのがいいのか、関数が型に対して分岐するのかの違いだろ

オブジェクト指向の本でこの極めて単純で自明なことをかいてある本なんてどこにもなかったよ

いまや沢山のオブジェクト指向の本があるけど、それが示していることは、オブジェクト指向は単純でもなければ、誤った公理から始まった仮構にすぎないということだ
スタートが誤っているからこそ議論がたえない

君はデータ型とメソッドの結び付きがどうだといっているが、君は当然SOLID原則が意味するところをしっているよね

それで例えるならクラスというのは、データであると同時にメソッドまでをパッケージングしている
つまりSRPにもSoCにも反するものだってことなんだよ

クラスの数だけ世界があり、クラスの数だけメソッドを実装しないといけない、それがどれだけ利用性に役に立つのか
javadocをみて山のように立ち並ぶクラス群をみて、うんざりしたことはないのか

windowsAPIが関数で構成されているということの意味をもう少し理解したらどうだ

オブジェクト指向に神秘性を感じている奴は、どのようにオブジェクト指向が実装されているのか理解したほうがいい、でないと議論する時間の無駄だから

0264デフォルトの名無しさん

2017/03/20(月) 18:33:19.29ID:GbEM94zj

コンテクストを理解させる前にオブジェクト指向の実装を理解しろ

0265デフォルトの名無しさん

2017/03/20(月) 19:59:52.99ID:KXLYvEOG

>>258
ライブラリをテストする人に対しては隠蔽しない
ライブラリを使う人には内部仕様は隠蔽する
これはオブジェクト指向とは関係ない話

0266デフォルトの名無しさん

2017/03/20(月) 20:29:21.80ID:W87CYmkA

>>254
プログラミング、および言語の歴史をちゃんと調べると
いろいろ腑に落ちるんだよな
いきなりOOPだけやっても狂信者とアンチを
生み出すだけなんだろう

0267デフォルトの名無しさん

2017/03/20(月) 20:31:50.45ID:G9+XvfW+

>>263
長文ご苦労さん
君がオブジェクト指向も関数型もどちらも理解してないことは良くわかったよ

0268デフォルトの名無しさん

2017/03/20(月) 23:16:21.60ID:EOJWC60m

釣りネタかと思いつつも皆でテキトー議論になればいいかなーと相手するけど
「SFってUFOが出てくる奴だろ！？」ぐらいのレベルを長文連投してくると
さすがに何も理解できない素であたまわるいひとなのだな…と認定せざるおえないw

0269デフォルトの名無しさん

2017/03/20(月) 23:22:53.30ID:UB8UMXbl

>>260
＞オブジェクト指向の発明は、
＞昔write(console,"A")
＞とかいていたものを
＞console.write("A")と倒置して書くことにした

>>44,45

0270デフォルトの名無しさん

2017/03/20(月) 23:51:03.70ID:GWfrNwZR

>それで例えるならクラスというのは、データであると同時にメソッドまでをパッケージングしている
>つまりSRPにもSoCにも反するものだってことなんだよ

>windowsAPIが関数で構成されているということの意味をもう少し理解したらどうだ

自分であんまりわかってないから、結論を自分の口ではっきり言わない人いるよね

つまり何が問題なのか、WindowsAPIが関数であることでどんなメリットがあるのか
おせーて

0271デフォルトの名無しさん

2017/03/20(月) 23:54:24.79ID:ub4me4bd

win32もGUI周りとかがっつりオブジェクトじゃね

0272デフォルトの名無しさん

2017/03/21(火) 00:10:03.52ID:RJ2XVIqX

それは構造体とクラスの区別がついてない人が言うことだよ

0273デフォルトの名無しさん

2017/03/21(火) 01:30:07.94ID:jV0Y+t/Y

構造体に対してオブジェクトという言葉を使わない言語もあるけど使う言語もあるんだよ

0274デフォルトの名無しさん

2017/03/21(火) 01:48:03.35ID:UqOt5XZ1

>>265
オブジェクト指向言語にそんな仕組みはないよね?

0275デフォルトの名無しさん

2017/03/21(火) 02:32:28.81ID:u6uP4x23

OOP論とOOPL論がごっちゃになるのは>>1のせいだな

0276デフォルトの名無しさん

2017/03/21(火) 03:40:12.12ID:kYeHwX6T

窓APIはC++が主流とは言えん時代に書かれたものを引き継いでるわけで、互換性の問題で
Windows3.1とかさ

一時期のVC++ 6.0なんぞ、C++の仕様に従ってない例外の投げ方してたし(VC++の構造化例外が足を引っ張った）

COMなんぞ、Callerの指定に応じてカーネルが介入して適切なバージョンのDLL読んでインスタンス作って投げるという
エクストリームでDll Hellにもなり得るなんかだったが
バイナリ互換性って意味ではなんとかなったものだし（ユーザーにDLLインストしてもらえばなんとかなる）

なんて歴史もイロイロあろうが、割と泥臭い話ばっかりッスわね

0277デフォルトの名無しさん

2017/03/21(火) 03:42:53.33ID:kYeHwX6T

>>263
今だったらmix-in/trait/AOPだぁね
特定のクラスにメソッドだけ植え込む奴

0278デフォルトの名無しさん

2017/03/21(火) 03:47:06.63ID:kYeHwX6T

>>270
たぶん「複数のクラスに同じメソッドを二重に書くとかありえんわ」の話でそ

mix-in系の機能があるならやるだけ
ないならヘルパークラスをメンバフィールドに持たす程度

0279デフォルトの名無しさん

2017/03/21(火) 07:10:22.43ID:bH1u/9cj

>WindowsAPIが関数であることでどんなメリットがあるのか
>おせーて
Cでも書ける
あとからでもC++でクラスに出来る

0280デフォルトの名無しさん

2017/03/21(火) 21:30:13.50ID:rKUIj2Ew

>>274
オブジェクト指向とは関係ないって言ってるだろ

0281デフォルトの名無しさん

2017/03/21(火) 21:31:25.48ID:6SfdpXKy

>>274
あほか

0282デフォルトの名無しさん

2017/03/21(火) 22:22:55.65ID:RJ2XVIqX

え?
君達は本来privateであるべきクラスフィールドや、メソッド群をどうやってテストしてるの

オブジェクト指向やってる以上カプセル化は重要なわけでね

君達も本来privateであるべきものをpublicにしたりして、デバッグした経験あるんじゃないの?

実際にはdev段階においては、リフレクションを使って、privateな対象をpublicにする黒魔術的なテストライブラリはあるけどね

君達はこの問題にどう対処してるか非常に興味があるんだけど、教えてくれないかな

0283デフォルトの名無しさん

2017/03/21(火) 22:55:23.66ID:KGQ11aI9

privateなものをテストしたいと思ったら
設計が間違っている。

役割ごとにクラスに分けるなどきちんと設計すれば
privateなものをテストしたいってことにはならない

0284デフォルトの名無しさん

2017/03/21(火) 23:02:59.62ID:UqOt5XZ1

>>280
でもできないじゃん

0285デフォルトの名無しさん

2017/03/21(火) 23:26:33.63ID:RJ2XVIqX

>>283
何言ってるのかわかんないね

オブジェクトデバッグにおいてもっとも重要なのは、内部状態でしょ

内部状態をもつからこそ、staticクラスじゃなくてインスタンスクラスとして定義してるんじゃないの

もしオブジェクトデバッグするとなったら、ダイレクトにアクセスできたほうがいいよね

例えば君が単純なカウンタを実装したとき、long型の限界付近でこのカウンタはどのような挙動を示すか興味があったとする

public methodはincrementとresetしかない、極めて初歩的かつ一般的なカウンタの実装だ

このとき君はどうするの?
本来の設計意図を無視して勝手にコンストラクタを増やす?セッタを勝手に増やす？それともカウンターを再設計するの

0286デフォルトの名無しさん

2017/03/21(火) 23:29:43.92ID:rKUIj2Ew

>>284
ライブラリの内部仕様はユーザーに隠蔽するのだから、どんな言語でも知る事は出来ない
こっそりソースを覗き見たところで非公開なのだから次の日には変わってても仕方ない
オブジェクト指向かどうかは関係ない
privateもpublicも関係ない

0287デフォルトの名無しさん

2017/03/21(火) 23:57:02.87ID:RJ2XVIqX

君はライブラリを作ったことがないんだね
正確にいえばライブラリを使ったこともないよね

オープンソースのライブラリみてソース読んで、ライブラリの挙動を調べるときに内部状態見るのが理解にとって一番手っ取り早いのは当たり前だよね

このときゲッタすら実装されてなかったら(それは極めて実直なオブジェクト指向にありがちだが)そのライブラリをテストすることに辟易とする

ただ単にライブラリをテストするにもリフレクション使えってこと?

断言するけど、アクセス修飾子はテスタビリティをそこねているし君達が黒魔術に手を出さないといけない理由も思想的な誤りによるものだ

0288デフォルトの名無しさん

2017/03/22(水) 00:05:05.30ID:ZXxN+M5f

>>285
もし君がlong型の限界値付近の挙動を気にするべきカウンタを作ったとしたら、それは初歩的でも単純でもないカウンタだったという事だ。
巨大な値を扱う可能性があり、その品質を保証するためには、単純なpublicメソッドでは不足だったという事。
つまりカウンタの再設計が必要だ。

0289デフォルトの名無しさん

2017/03/22(水) 00:11:44.46ID:+9rAaXcc

privateなメンバを外部からテストする意味が不明
privateなメンバはpublicなメンバを通してテストし問題なければそれ以上でもそれ以下でもないと思うんだが

0290デフォルトの名無しさん

2017/03/22(水) 00:16:27.40ID:ZXxN+M5f

>>287
ライブラリが君の興味に対してアクセスを許してなかったら、それは君に見て欲しくないし、知って欲しくないし、触って欲しくないってことを表明してるんだよ
それを自分の都合で無理やり、見て、触って、知りたいというなら自己責任でお好きにどうぞ。
そこまでする必要を感じないというならそのライブラリを使わなければならない決まりはない。
もっと君の好みにあった都合が良い子を探すか自分で作れば良い。

0291デフォルトの名無しさん

2017/03/22(水) 00:17:33.79ID:MyrW3Mfd

>>287
あほか

0292デフォルトの名無しさん

2017/03/22(水) 00:18:40.07ID:+9rAaXcc

>>285
内部状態というのをどういう意味で言ってるのか知らないけど
staticメンバもクラスオブジェクトの内部状態なんだけどね...

0293デフォルトの名無しさん

2017/03/22(水) 00:21:31.43ID:Ac91TQ9I

Java作った人たちはきっと
普通をprivateじゃなくてアクセス修飾子つけずにinternalにしてほしかったんだ
そしたら別のフォルダ切って同じパッケージから内部状態のテストできる

でもクラスの外から「絶対に」アクセスできないprivateのほうがはるかに安心感があり使い勝手がよかった
誤りなどではない
メリットがデメリットを上回ったんだ

0294デフォルトの名無しさん

2017/03/22(水) 00:33:22.43ID:0HwU5Emk

>>285
> オブジェクトデバッグにおいてもっとも重要なのは、内部状態でしょ
何を言ってるのかわからないのはこっちだ
今はテストの話をしている

内部状態はテストとは無関係だ。
内部の実装がどうなっているかは
テストとは無関係

0295デフォルトの名無しさん

2017/03/22(水) 00:39:08.92ID:+9rAaXcc

どーでもいいけどstaticクラスとかインスタンスクラスって何ですかね>>285

0296デフォルトの名無しさん

2017/03/22(水) 00:44:09.42ID:hKnvzbpj

謎の定義が生まれまくっていてカンブリアンエグスプロージョン

0297デフォルトの名無しさん

2017/03/22(水) 01:00:09.04ID:+9rAaXcc

privateなメンバの検証を行うのは、そのprivateメンバをもつクラスを設計した人である
そして、そのクラスの設計者はprivateメンバを内部的に利用するpublicメンバに対して
外部から発生し得るアクセス方法や値を使って網羅的に検証を行い問題のないことを
確認すればよい
privateメンバに対してそれ単体として取りうるすべての値や処理についてまで網羅的に
検証する必要性はない
なぜならprivateメンバは外部から直接アクセスされることはないからである

0298デフォルトの名無しさん

2017/03/22(水) 01:21:57.10ID:gvAZwZV8

>>293リフレクション使えばアクセスできるけど、安全?

0299デフォルトの名無しさん

2017/03/22(水) 01:29:40.10ID:hKnvzbpj

>>298
言うと思った

0300デフォルトの名無しさん

2017/03/22(水) 01:29:53.18ID:+9rAaXcc

privateメソッド名を知っていることが前提となるけど、自分としては
そもそも>>297の認識なので、リフレクションつかってsetAccessible(true)
してまでprivateメソッド単体のテストをする理由が思いつかない...

0301デフォルトの名無しさん

2017/03/22(水) 01:30:33.09ID:VqeOZxmB

>>293
Javaは修飾子を付けないデフォルトはPackage-Privateだろ
これは同一パッケージ内ではPublicと同じ

0302デフォルトの名無しさん

2017/03/22(水) 01:31:10.22ID:axBWr/Dz

隠蔽とか誰から何を隠蔽するのか全くわからない
隠蔽してあるならテストしなくていいの?
ってわけにもいかないし
そもそもクラスの使用側作成側っていう明確な切り分けがプロジェクトでなされていない
誰かのこさえたクラスが自分にとって都合の悪い作りになってたら
簡単に変更できちゃう環境なわけで
インターフェースクラスなんか見つけたら邪魔なので問答無用で削除

0303デフォルトの名無しさん

2017/03/22(水) 01:31:40.10ID:gvAZwZV8

例えば先ほどのカウンターの例のように、ライブラリのテストを行うときに、君はカウンターをmaxlong回まわすのかというわけなんだよ
気の利いたカウンターだとセッタが公開されてたりするけど、カウントの途中でセッタ使って変更したらカプセル化の観点からするとアウトだよな

これはプリミティブなlong型だから、まだ挙動は予測できるけど、実際のライブラリはオブジェクトを引数にオブジェクトが呼び出され別オブジェクトがってなってるわけで、内部状態を把握するのは当たり前だよな

たぶんeffectiveJavaにもこうかいてあったでしょ
toStringをオーバーライドしろと
そしてJ2SEは内部状態を示すようにオーバーライドされていることが多い

問題なのはこれが言語標準じゃないってことだ、良識がないライブラリだとこれすらされてないわけでね
さらにいえば、セッタは以前として公開されていないわけで

0304デフォルトの名無しさん

2017/03/22(水) 01:32:22.90ID:MyrW3Mfd

>>302
インターフェイス使えないやつｗｗｗ

0305デフォルトの名無しさん

2017/03/22(水) 01:34:03.18ID:+9rAaXcc

インターフェースクラスとは一体...

0306デフォルトの名無しさん

2017/03/22(水) 01:35:22.01ID:MyrW3Mfd

>>303
たとえばどのライブラリ？オープンソースのライブラリなんて腐るほどあるから、具体例で示して

0307デフォルトの名無しさん

2017/03/22(水) 01:35:46.32ID:+9rAaXcc

>>302
決してprivateメンバのテストをしなくていいというわけではなく、
privateメンバに対して直接単体テストをする必要性はないと思う
ってことなんだけどね
そもそも隠蔽の目的ってそういうことだし

0308デフォルトの名無しさん

2017/03/22(水) 01:43:11.26ID:gvAZwZV8

>>306
オープンソースじゃないし、.netだけどfiddlercoreね
メッセージキューがどうなってるか

定期的にキューが削除されているのか、キューはoutofmemoryをはくまで肥大化しつづけるのか

もしそうだとしたら、キューを初期化できないのか

内部状態にアクセスできれば一発でコントロールできたことなのにね、アクセス修飾しってのは再利用性も阻害するってこった

0309デフォルトの名無しさん

2017/03/22(水) 01:47:05.68ID:vhfzvoEm

staticおじさん来てるの？

0310デフォルトの名無しさん

2017/03/22(水) 01:48:08.38ID:+9rAaXcc

人様が作ったクラスを使わせていただく以上、そのクラスを作った人の
ポリシーに従う他ない
それがいやなら自前でクラスをこしらえるのみ

0311デフォルトの名無しさん

2017/03/22(水) 01:49:04.66ID:gvAZwZV8

要はね、ライブラリがprivateフィールドをテストしてるのはわかってるんだよ

でもprivateフィールドがどのように実装されているかって結局パフォーマンス特性そのものを示すものなんだよね

それ隠蔽されたら、正直使い物にならないよね
容量が決まっているバッファなのか、全てのログにアクセスできるlistなのか、それすらも隠蔽されたらね

どちらの選択も合理性があるんだよ、これはテストの問題ではなく設計思想の問題なんだよ

これにアクセスできれば、自分好みのパフォーマンス特性がえられるのにって経験がないならそれまでなんだよね

それは再利用性がないってことを言ってるのとほぼ同じなんだけどね

0312デフォルトの名無しさん

2017/03/22(水) 01:49:52.24ID:gvAZwZV8

オブジェクト指向ライブラリは再利用性がない

0313デフォルトの名無しさん

2017/03/22(水) 01:51:16.25ID:axBWr/Dz

>>310
プロジェクトにとって邪魔なんだから削除するだろ
なんでこんな仕様にしたのか軍法会議にかけるところだ
汎用性を重視した割に次の改修でかすりもしねーカスは銃殺

0314デフォルトの名無しさん

2017/03/22(水) 01:54:59.18ID:+9rAaXcc

>>313
社内で作られたクラスの問題なら大いに議論して変えていけばいい
社外で作られたクラスの問題なら諦めて自前で用意するしかないだろう

0315デフォルトの名無しさん

2017/03/22(水) 01:56:02.90ID:+9rAaXcc

当然、社外で作られたクラスでも交渉の余地があるならやればいい
それはあなた次第

0316デフォルトの名無しさん

2017/03/22(水) 01:57:32.65ID:gvAZwZV8

ライブラリが期待通りに動いてくれるって何のファンタジーなんだよ
君達マジでテストコード書かないでサードパーティライブラリをプロダクションコードにぶちこむんか?

お前が設計したわけでもなく、お前の期待通りに動いてくれるかなんてわからんのに?

たかがlongmaxに+1しただけでも
1.longminになる
2.exceptionをはく
3.bigintegerに切り替わる

ライブラリによっては
この3つの挙動が考えられるのに?
ライブラリによってはJNIつかってネイティブ叩いてたりするわけでその制約をライブラリつかってりゃ受けないとでも思ってんだろうか

0317デフォルトの名無しさん

2017/03/22(水) 02:00:24.54ID:axBWr/Dz

仕様書にそんな仕様ねーのに何枚でもタブを増やせる仕組みを入れてくれたA君

でもお客さんはタブなんかいらないからスクロールできるようにして上から順番に表示して欲しいってさ

オブジェクト指向オブジェクト指向叫ぶアホの仕事ってプログラミング
云々以前にこんなことやってるアホばっか

0318デフォルトの名無しさん

2017/03/22(水) 02:03:38.09ID:+9rAaXcc

>>316
根本的な考え方が私とは違うようだ
例えば使いたいライブラリを開発してもらう段階から話に入れていたのなら
自分が期待する動作になるようにライブラリを作ってもらうことはできるだろうし
あなたのコードのためのライブラリを作ってもらっているなら大いに要望を
出していいだろう

でもあなたの場合は違うんでしょ？
すでに完成しているありもののライブラリを使って何とか自分の期待通りの
動作をするコードを書き上げたい
でも上手くいかない
で、このライブラリはクソだと大声で叫ぶ

それって話の論理としてどうなのかなと思うわ

0319デフォルトの名無しさん

2017/03/22(水) 02:13:06.37ID:gvAZwZV8

>>318
それはライブラリの再利用性が低いってことに同意してくれたってことだよね

要はライブラリ実装にユーザーが左右されるから、ライブラリ使うならライブラリ実装段階からコントロールしないといけないと

その認識だとモジュールプログラミングの基礎であるレイヤー分離もできていないってことなんだけど大丈夫なんですかね

0320デフォルトの名無しさん

2017/03/22(水) 02:27:49.38ID:+9rAaXcc

>>319
ライブラリの再利用性が低いのは、そのライブラリの設計の善し悪しの問題かと
レイヤー分離がされた汎用性の高いライブラリを設計するにはそれ相応の考慮とスキルが必要

一般に、再利用性を高めるために汎用的な仕様にするわけだが、これは裏を返せば
ある特定の用途では全く使い物にならない可能性も高めることになり、そういった用途で
使おうとしたあなたのような人の視点で見れば再利用性が低いと評価されることもあるだろう

その場合、プロジェクトを始める前にそう言ったリスクを想定し、ライブラリの開発や再設計も
視野に入れてスタートするべきだろう

現実はライブラリの実装段階からのコントロールとか新規開発とか、そんなことやってる
時間も金もないんだよというのが正直な所なんだろうが、どうにもならないことは
どうにもならないわけで、そこは仕事を断る判断含め大人の対応が必要なんでしょう社会人として

0321デフォルトの名無しさん

2017/03/22(水) 02:42:57.73ID:gvAZwZV8

>>30で文法的におかしいことはすでに述べた、英語的にも不自然だ
そして汎化の仕方としてもやはり不自然なんだよなあ

>>320
つまりオブジェクト指向ライブラリは、部分的な切りだしもできなうということも認めるわけだ
それは改めて再利用性がないと指摘しているにすぎない

データと関数が分離されていれば、データをすり替え、使えない関数を書き換えるだけで済む話なのに、データと振るまいが結び付いていると両方一緒にぽしゃるってことなんだよね

30みればわかるとおり、関数主体ならばデータ型が気に食わなければすり替えられるわけだ

でもオブジェクト指向はそうじゃない、データが主部である以上それを省略することもできないし、入れ替えるってことはクラスそのものを書き換えることになる

関数が気に食わないときは結構手を加えなければならないが、シグニチャが同じであればそれは容易に内部構造をすり替えられる

君の意見だとオープンソースライブラリは一つも採用できないよね
設計の問題ではなく言語的欠陥なんだよ

まずsunやmicrosoftが20年ぐらい前に出していた、オブジェクト指向は再利用に有効であるってのが営業上のセールストークに過ぎないってことまず認めような

0322デフォルトの名無しさん

2017/03/22(水) 02:50:56.36ID:gvAZwZV8

確かに、汎用性のあるライブラリ設計は大変だ
しかし、オブジェクト指向はその設計の手助けをするどころか、設計者の背中をぶった切り、返す刀でユーザーの肩もぶったぎってるよな

君達もライブラリを使おうとする時、また勉強すんの、まーたjavadoc巡りかよって思ってるだろ

設計者もどうやって設計しようかっていっつも悩んでいる
でもっていっつも失敗して>>317みたいな奴に叱られると

プログラムを設計するのに新規クラスを作る必要は実際のところないってことがわかんないんだろうな

0323デフォルトの名無しさん

2017/03/22(水) 02:52:07.81ID:zM0bMLWs

長文はキチガイ

0324デフォルトの名無しさん

2017/03/22(水) 03:12:25.11ID:0HwU5Emk

>>316
> ライブラリが期待通りに動いてくれるって何のファンタジーなんだよ
> 君達マジでテストコード書かないでサードパーティライブラリをプロダクションコードにぶちこむんか?

俺はライブラリだけじゃなくて、OSがちゃんと動くか、
CPUがちゃんと動くか、半導体がちゃんと動くかまでちゃんとテストしてる。
この間は電圧が100Vかどうかのテストを書いたよ
今度はニュートン力学が正しいかどうかのテストが必要

0325デフォルトの名無しさん

2017/03/22(水) 05:52:21.48ID:gTzPAvUY

俺は自分の正気が信じられないから脳に電極刺してテストしてる
これぐらいやらないといけないから俺の脳の構造は間違ってる。

とか言ってる基地外とかレスのしようがないわな。

0326デフォルトの名無しさん

2017/03/22(水) 06:15:25.21ID:qEl3ed9E

クラス作る必要がないと感じるなら、関数だけで一からアプリ作ってみりゃいいんだよ

普段の仕事でオブジェクト指向がそぐわないと感じるのは、
フレームワーク作る人たちががんばって
もうパンピーがクラスの構成考える必要がないぐらい、枠組みをきっちりクラス化しちゃってるせいだ。

インターフェースがあり、画面オブジェクトがあり、コントローラーがあり、DAOがあり
ほかに何がいるってんだ

0327デフォルトの名無しさん

2017/03/22(水) 06:45:15.48ID:qEl3ed9E

>データと関数が分離されていれば、データをすり替え、使えない関数を書き換えるだけで済む話なのに、

結局両方変えてんじゃねーか
気づけよ

0328デフォルトの名無しさん

2017/03/22(水) 07:05:50.09ID:2wDJFxh2

組込ならともかく協業全員がコードの全てを把握するなんて不可能じゃないの
色んな意味で責任範囲を明確にするのが構造化の役割だと思うけれど

0329デフォルトの名無しさん

2017/03/22(水) 07:14:19.84ID:ZXxN+M5f

自分の気に入らない子にオブジェクト指向のレッテルを貼ってるだけ
そもそもオブジェクト指向かどうかと関係ない話

0330デフォルトの名無しさん

2017/03/22(水) 08:03:23.54ID:gvAZwZV8

オブジェクト指向って不自然な文法だよな

0331デフォルトの名無しさん

2017/03/22(水) 08:12:45.22ID:KD82SvgF

>>329
実はおれもそれ思ってたんだが
オブジェクト指向と関係ないんだよね

■ このスレッドは過去ログ倉庫に格納されています