カプセル化は愚かな考え
■ このスレッドは過去ログ倉庫に格納されています
■危険性
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。
大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) >>462
ずーっと昔はグローバル変数丸出しで
モジュール間の結合度が高すぎて、
既存コードの保守が難しくなった。
既存コードの保守をしやすくする為に、
モジュール間の結合度を下げよう、
カプセル化してモジュール間のインタフェイスを
最小限にしようという機運が高まった。
そこで出てきたのがオブジェクト指向。
計算機科学は発展途上だから完璧なものは未だ無いよ。
有るのは「よりマシなもの」だけ。
文句を言うのは自由だけど、賢い人はそれを
チャンスと捉える。 個人的には関数型に大いに興味があるし、勉強もしてみたいと思っているが、一般的には>>464とは逆の理解の方が一般的なのでは？
電子計算機であることと関数型のメリットがどう結び付くのかよくわからないが。 >>465
オブジェクト指向のビジネス的な成功理由は
メリットがないことで弱点がないってことかな
メリットがあればみんな当然そこを挫きに来るし
もっといいモノを見つけて来るだろう
メリットが無ければそのアプローチで挑むことはできない
そんなくだらないアプローチが通ってしまうほど技術者が劣化してしまっていたことも原因の一つだと思う
資本主義のセーフティが全く働いていない
より良いものを使用者が選択できる選択肢は無く
どこもかしこも全く余裕がなく世界中でMSの提供物を使うしかなかった
そこまで世界が劣化してしまった結果として生まれた悲劇だと思う
二十年？三十年近くプログラミング言語は何も進化しなかった
これは大き過ぎる失策だったと思う CでADT書いてみればオブジェクト指向の利便性がわかるよ
オブジェクトはADTの延長線にあるものだから
流行ったのはGUIを実現するにあたっての現実な解だったからだろうね >>459
オブジェクト指向の方が優れているよ
理由はいちいち説明しないよｗ >>462
お前がオブジェクト指向のメリットが理解できないだけじゃね？
お前自信に問題があるって自覚しよう 関数型言語の方が（ある点では）メリットが有るのは事実だが
オブジェクト指向にもメリットは有るわけで
それが理解できないのはセンスがない
オブジェクト指向にはメリットがあるが、関数型言語なら
それを上回るメリットが有るという言い方をするならわかるが
メリット自体がわからないんでしょう？ オブジェクト指向のメリットと謳われていたものはすべてデメリットだったんだよ。
暗殺組織が「両親を殺したのはあいつらだ」と言って子供に殺人させるが、本当は両親を殺したのは暗殺組織みたいな。
もっとも邪悪なのは階層化だろうな。 > オブジェクト指向のメリットと謳われていたものはすべてデメリットだったんだよ。
じゃあそのメリットというものをすべて言ってみてください
それがデメリットかどうか語るのはそれからですね Microsoftから関数型OSが出るかもしれんな。
出せなければMicrosoftは終わりだろ。 じゃあ俺はMicorosoftどころか、Apple、Googleも含めて
関数型OSなんてのは登場せず、終りもしない方に掛けるわｗ
少なくとも100年以上安泰だろうな
でお前はMicrosoftはいつまでに終わると思う？
終わると言っては見たものの、すぐには終わりそうもないから
100年後には終わってるはずだーとか言う？ｗ
なんかぐぐってみたらNixOSとかいうのが純関数型OSとか書いてあるの見つけて調べてみたら
たんにパッケージマネージャーが関数型（というより宣言的記述で使えるだけ？）みたいでワロタ
お前が言う関数型OSっていうのもこういう意味？ｗ
https://www.atmarkit.co.jp/news/200902/17/nixos.html
> もう1つ、最近私が気になっている実験的OSは“純関数型”を標榜する「NixOS」だ。
>これもLinux上に構築したシステムで、本来の意味でのOSとは違うのだが、
>ユーザーが利用するシステムが抱えている課題を解決しようとしているという意味では
>OSと呼んでもいいと思う。NixOSの公式ページには純関数型ディストリビューションと書いてある。 なんで「関数型」が「オブジェクト指向」の対義語になってるのか
「関数」なら分かるけど
「関数型」（宣言型）は「手続型」の対義語だよね（あまりにかけ離れてるので親階層で対義語）
「手続型」の「関数」は「関数指向」と言えばいいのかなｗ
・手続型（命令型）
・コマンド型
・関数指向
・オブジェクト指向
・メッセージ型 ←これも関数指向
・クラス型
・宣言型
・関数型
・構造型（SQL）
しかも「関数型」は反「カプセル化」でもないし
本来はループ処理しなきゃ実現できないものを、むしろ隠蔽しちゃうでしょ
SQLもそうだけど（SQLはループじゃなく並列処理だけど）
値１つ１つの変遷をステップ実行で確認できず、手続脳な人には意味が分かりにくい
「関数型」を希望した人はそれが邪魔だってわけだけど OSについては、SQLの発想はありだと思う
既にWMIで一部SQLのようなもので操作できるけど
フォルダやレジストリを全検索すると、物凄い時間かかるじゃん
DBなら一瞬なのに
なのでOS自体がDBでできてればなとは思う
縦横無尽に検索したり更新したりできる
メーカーの中の人も影響関係を瞬時に正確に把握でき、バグ率も下がると思う
システムログに物凄い書式のXML使ってるけど、無駄が多過ぎる
肝心な条件で絞れないし
DB形式の２次元では階層表現できないということなんだろうけど、
２次元でも複数のテーブルに分ければいくらでも多次元にできるし、
検索も速いし、分かりやすいし、二次加工しやすい
Webについては最近はJSONとか？
XMLよりはマシだけど、やはりDB形式より無駄が多い
「関数型OS」とかわけわからんけど、XMLと似た危険な香りがする
なぜ人はDB形式以外に挑戦するのか >>476
オブジェクト指向にとって関数型は対義語じゃないよ
だけど関数型にとってオブジェクト指向は対義語
なぜなら関数型は極めると純粋関数型言語に向かうから
オブジェクト指向にとって関数型は取り入れるもの。便利な部分をつまみ食い
だけど純粋関数型言語にとってオブジェクト指向は純粋関数型言語ではない >>477
> フォルダやレジストリを全検索すると、物凄い時間かかるじゃん
> DBなら一瞬なのに
インデックスが張られてないDBは検索がものすごく遅い
全件検索するから
つまり、速いか遅いかはインデックスがあるかどうかでしかない >>477
どうせあれの話をしてるんだろうけど、
Microsoftから学んだほうが良いよ
ファイル検索をSQLでできるようにしたと
大々的に発表したけど結局搭載するのをやめた
時間がなかったわけじゃない。だって随分と前の話で
本当にやる気があるなら、次期バージョンで搭載にしてたはず
つまりMicrosoftという技術力の高い会社が
「発想は面白かったが実際にやってみたら意味がなかった」
と判断したんだから >>479
インデックスなんて大したことないよ
（最近は結構差が出る場合があるけど、わざとじゃないかとｗ）
DBの速さはデータ形式の単純さ、全行並列処理、ハードディスクの自前管理 >>480
まあ一般ユーザーは使わんわな
じゃなくて、内部的な設計思想の話 Googleの検索がめちゃくちゃ速い理由
https://logmi.jp/business/articles/234684
Googleのコンピューターも膨大な時間と努力を投入して
インデックスを作っていますが、その努力の甲斐があるというものです。
インデックスによって劇的に検索スピードが上がり、毎秒、約40,000件もの検索にGoogleは答えているのです。 ここはオブジェクト指向すら理解できない老害の教育の場かな？ >>482
＞内部的な設計思想
それがWinFSだったんだけど
https://www.itmedia.co.jp/enterprise/articles/0607/18/news010.html
データは複数のデータベース(またはデータストア)に保存され、WinFSはこれらのストアとファイルシステム間でデータの同期を効率よく実行する。
また、連絡先や予定表アイテム、電子メールなど、一般的に使用される類のデータの標準のプロパティスキーマも提供する予定だった。
WinFSが実現されていれば、ファイルの検索や整理機能の向上、および特定の種類のデータ
(連絡先や予定表のイベントなど)の共有を共通スキーマにより簡素化する相互運用性の向上などが期待できた。 >>486
そして実験的に実装したけど、結局速い検索ならインデックス作るだけでよくね？となったんだよね 特定のプロパティで検索するのも、プロパティをインデックスすればいいだけだしね GUI用の概念を別用途に持ち込んだから今の混乱がある >>478
純粋関数型以外の関数型言語（関数型をベースにしつつオブジェクト指向の機能を付け加えた言語等）も人気があるから、「関数型は極めると純粋関数型に向かう」というのは語弊があるような。
結局今は、純粋なオブジェクト指向を出発点にするにせよ、純粋な関数型を出発点にするにせよ、他方の良い点ををうまく取り込み、バランスを取ることを目指すアプローチが多いんだろう。 結局、ドキュメント無くても把握できるにはどうすればいいか。あたりが一般的なメリットで、
それを推し進めると、制約や挙動が保証されるものになり
結果、オブジェクトの不完全さが目立って、
関数型がもてはやされるみたいな。
でも、できる人間なら言語の不完全さは乗り越えていくんだよな。 「純粋関数型に非ずんば関数型に非ず」という原理主義的な人は、決して多数派ではないと思うけどなぁ。
自分も関数型言語についての知識はあまりないが、たとえばF#（OCaml）は手続型ではなく、関数型言語として紹介されることの方が圧倒的に多いと思う。 >>493
ドキュメントなくても〜から関数型に全く話がつながってない
関数型ならドキュメントなくても〜とか言ってるやつは一人もいないだろ >>494
結局の所、みんな関数型には限界があるって知ってるんだよね
理論的な限界じゃなくて、理論的には可能なんだろうけど
手間が多くて面倒でとてもやってられなくなる場面が多い メッセージングとは、オブジェクト同士の二人称対話なのだ！
>>155
>オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1
>>922
＞ナンチャッテメッセージングスタイルになったのは
チンポ.オシッコを出す
チンポ.オシッコを止める
さっきトイレでやってきた。
929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1
>>915
＞単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを
＞ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。
×
俺.オシッコを止める 俺.オシッコを出す
○
俺.チンポに力を入れる 俺.チンポから力を抜く ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ ttps://video.twimg.com/ext_tw_video/1296548685300396032/pu/vid/960x720/Tt9Hj_acNH_uHS6Y.mp4?tag=10 >>483
そういうペテン師に合わせて最近のバージョンはたまにインデックスが効く罠が仕込んであるのかなｗ
あるバージョン以降は、妙に遅いことがあって、解析すると、ここにインデックスを貼れと
貼ると、従来の速さに近付く
速くなるわけじゃなく、元に戻るだけｗ
（バッファオーバーラン防止のためにタイプセーフ対応したとの情報もちらっと見た気がするので、そのせいかもしれない）
にしてもその差はそれほど大きくない
インデックスの威力がメインなら、BULK INSERTや一時テーブルの速さを説明できない
これを使って、１時間の取り込みを数秒に短縮とか、あちこちで改善してきたので
この差はインデックスの有無を遥かに超える差 >>486
＞既存のツールで有用な結果が得られるのに、わざわざ追加情報を設定して
＞ファイルにタグを付ける必要があるだろうかという疑問が生まれることになった。
ああ現実主義でいいんじゃないかな
「発想は面白かったが実際にやってみたら意味がなかった」
ではないよ
＞データベース内のテーブルとファイルシステム内のファイルを同期する機能は、SQL Serverの次期バージョンに組み込まれる予定だ。
＞汎用OSサービスとなるはずだったものがSQL Serverの1機能として提供されることになる
いきなりスクラッチビルドな高い理想を目指すのではなく、徐々にってことだ
ここでは直近の現実について話してるわけじゃないから
実際Win１０でも「Windows へようこそ」をオフにしても出てくるとかｗ
俺が言ってるのは検索だけじゃなくて、中の人のバグ率や、機能整理の意味もある >>502
> インデックスの威力がメインなら、BULK INSERTや一時テーブルの速さを説明できない
え？説明できないの？それお前が無知なだけじゃん。
1. インデックスは検索に使うものでインサート時には関係ない
むしろインデックス作成のために逆に時間がかかる
BULK INSERTでは一件ごとにインデックスを貼る処理を行うと時間がかかるので
インデックスは貼らずにデータを挿入し、あとからインデックスをつけるのは常識レベルのテクニック
2. 一時テーブルだからといって速いことにはならないが、それで速くなったとするなら
一時テーブルによってデータ量が減った。複雑なクエリーで無駄にデータを参照しているとそれが減ることがある
一時テーブルによってインデックスを（有効に）使える条件が揃った
などの理由だろう
アナライズとかしたことないだろ？そういう風にデータを参照しているかちゃんと調べろ
常識レベルのことを知らんとかアウトや
お前はなんかやったら速くなったといってるだけで、その理由を調べてもいない >>484
グーグルとローカルのDBシステムでは規模が違い過ぎるし、「インデックス」の意味もだいぶ違う
いろんな角度からの検索を想定したキーワードを事前に生成し、単純な比較でヒットするようにしてある
逆にそのロジックが邪魔で余計なものがヒットし過ぎるが
言葉を厳密にしても全然絞れない > グーグルとローカルのDBシステムでは規模が違い過ぎるし、「インデックス」の意味もだいぶ違う
その根拠は？（間違った）主張だけをしても支持は得られない >>504
＞これを使って、１時間の取り込みを数秒に短縮とか、あちこちで改善してきたので
これが見えんのかねｗ
誰に向かって言ってるのか
「あちこちで」だ
さらに言うと「確実に」だ
まぐれではない
１．そんなことは知ってるが、ゆえに、インデックスがDBエンジンの速さの理由かね？
（言っとくが、ファイルコピーより遥かに速い）
２．何を言ってるのか分からんｗ
ちなみに説明を省略したが、１時間もかかる要件なので、一時テーブルから本テーブルへの
INSERT SELECTは、腕の悪いSEには無理な複雑さになることもある
そのFROM句が一時テーブルなのに速いと言ってるんだよ
というかその他のストアドでも多用するが、速い
あるいは言い方を変えると、インデックスの効いてない状態での速さでも十分速いと言ってる
普通のシングルタスク処理や、OS関連に比べると、とてつもなく速い
という意味 >>506
根拠はその後段に書いてあるはずだがｗ
まあ昔の記憶なので、ソースはないよ
雑談なので気楽に > そのFROM句が一時テーブルなのに速いと言ってるんだよ
だからちゃんとアナライズしてどのようにデータを参照しているか調べましょうって
なにもしてないくせに、やってみたら速かったとか遅かったと素人かよｗ > （言っとくが、ファイルコピーより遥かに速い）
他人が検証できる方法とベンチマーク結果よろしく
主張だけしても説得力はない だいたいインデックスは検索にときに使われるといってるのに
ファイルコピーとか言ってる時点で頭悪いがｗ >>511
頭悪いな
取込処理がファイルコピーより遥かに速いんだよ
その理由は？
インデックスがないから？アホかｗ
インデックスがあるよりはない方が速いのは当たり前だが、ファイルコピーより速い理由は？ >>510
それを言うならこのアホにだろｗ
483 名前：デフォルトの名無しさん 投稿日：2020/08/25(火) 08:15:35.41 qpVxWgT6
>>481
検索はインデックスが全てです >>512
まずファイルコピーより速いという証拠をだせと
話はそれからだろ
ウソを検証せずに話をすすめることで
事実であるかのように誤認させるテクニックは俺には通じない ストアドよりインデックスのほうが速いよってスレが無かったでしょうかね。 ありがちなインデックス教を説得するのは本題ではない
イベントログを解析したことあるか？
特にファイル監査
なんだあの大量のゴミ
不信なアクセスにどうやって気付くんだ
物凄い工夫して視認できるバッチ作ったけど
あれを単純なCSVにするだけでも各方面生産性が随分高くなる >>515
やってみるから、お前がやったことをいえ、
1. RDBMS
2. OS、バージョン
3. ファイルサイズ
4. 挿入先テーブルのスキーマ
お前が何も言ってないんだから、出来るわけなねーだろ > イベントログを解析したことあるか？
> 特にファイル監査
データベースの話なののこれだからなぁ
素人じゃんｗ > そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ? >>519
ニワカか
「データベースの話」ではない>>477
勝手に変えるな
「関数型OS」とかいう話が多く出てたから、「DB型OSは？」という、OSの話 DB型OS？そんなことばどこから出てきたんだｗ
検索してもないな >>518
１．SQL Server
２．任意
３．数十MB
４．任意 >>522
>>477
> OSについては、SQLの発想はありだと思う
（中略）
> なのでOS自体がDBでできてればなとは思う イマジネーションの欠如が深刻なんですよ。
つまり、石頭です。
昔は頑固おやじに代表されるように、年よりが石頭だったんですが、最近は若者なんですよ。
頑固おやじというものは、経験に基づいて保守的になっていたものですが、若者の石頭は、イマジネーションの欠如によるものです。
教わったものしかわからない、新しいものを創造できない。 OSがデーターベースで出来てるって意味不明ｗ
プロセス管理はどうするんだ？
メモリ管理はどうするんだだ？ プログラマはよく「ggrks」と言いますが、ネットで検索して何がわかりますか？
私の職業では、ネットで検索してわかることなどありません。
出てくるのは宣伝文句だけです。
プログラマは検索してわかるほど簡単なお仕事ですか？
だとしたら、新しいものは生み出せません。
きっと中国人は、検索でわかることなどないと言うでしょう。
だから新しいものはすべて中国からやってくるのです。 最近はよく「エビデンスを示せ」なんて言いますよね。
彼らに示して理解できますか？
彼らが欲するのは文献ですが、文献の中身は一切理解できないでしょう。
違いますか？
それでも、文献を編纂する立場の者にでさえ、気軽にエビデンスを示せなどと言います。
あなたに示して何が変わると言うのでしょう？ 反論はありませんね。
DB型OSの良さが理解していただけたようで何よりです。 まだデータベースのほうが速いって証拠だせないの？
一体どの環境だったらそうなるのかサッサ言えよ
DB型OSの意味もいわないしｗ
ねぇねぇプロセス管理は？メモリ管理は？ >>155
>オブジェクト指向のコア概念メッセージングがなぜ提唱されたか察するに
オブジェクト同士は常に二人称で、「俺」←対話（メッセージング）→「チンポ」。
つまりチンポは独立し自ら考えて行動する別の生き物なのである。
この考え方に至ってからは、オブジェクト指向の理解もすんなり進みました。
上手くオブジェクトを定義して、上手く会話させてやるのがオブジェクト指向
での設計なんだなーと今でも思っています。
https://blog.mah-lab.com/2014/03/18/object-oriented/
チンコの随意筋と不随意筋
http://d.hatena.ne.jp/tottokotokoroten/20130516/1368716650
＜俺＞
「 部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
＜チンポ＞
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」
まさに独立した人格を有したチンポという、もう一人の俺がそこに現れるのである！
【藤子・F・不二雄】「みきおとミキオ」現在と未来、憧れの入れ替わり生活！
https://www.google.com/amp/s/middle-edge.jp/articles/0izbO.amp DB ベースOSは、BeOSなど失敗の歴史。Windowsでもその計画は頓挫してる。 ファイルシステムのデータ構造はB-Tree
B-TreeはDBのインデックスに使われるデータ構造
OSもDBも性能的には似たようなものじゃないかな
ファイル名にデータを格納するIsseiという伝説の検索システムを思い出した、DBより効率が良いとうたって叩かれていたなあ >>497
洋式トイレに座ってオシッコを出したり止めたりする時、チンポがどうなっているかを確かめる必要無い。
つまりカプセル化とはオブジェクトの独立性であり、チンポはそれ自体が独立した生き物なのであると。 オブジェクト指向とは、「繋がっているけれども独立している」という意味である！
オシッコを出したり止めたりする時のチンポは繋がっているが、勃起する時のチンポは独立している！
違うか？
>>18
>オブジェクト思考って何？
>誰か説明して
では「チンポがシコシコする」という日本語表現は、文法的に正しいのか？
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか？
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！ ちんぽがしこしこ、そんな言語表現あるのか？
クリントンの「不適切な関係」
https://eigo-kobako.blog.so-net.ne.jp/2008-06-21
不適切な関係、そんな言語表現あるのか？
クリントン大統領も、チンポがしこしこしてしまったのか？
ちんぽがしこしこしてしまったのが、不適切な関係なのか？ // おしっこルーチン
俺.パンツを脱ぐ()
while (俺.オシッコ残量 != 0) {
俺.オシッコ残量 -= 俺.チンポ.オシッコを出す()
}
do {
俺.チンポフリフリする()
} while(count < MAX && 俺.残尿感())
俺.パンツを履く() >>540
>俺.チンポフリフリする()
「フリフリ」しているのは、腰であってチンポでは無いぞ？
腰をフリフリすると、慣性の法則で腰とは逆方向にチンポが動くということ。違うか？ >>536
>ファイルシステムのデータ構造はB-Tree
その比較はDBのレコード数分だけ1ディレクトリ内にファイルを作成して
それぞれの性能を比較することが前提になるんだけど
意味のある性能比較じゃないよね データベースに1GBものISOや動画を入れるのは遅い
まあ普通馬鹿げていてやらんがね 「オブジェクト指向」について解説！
>>88
>こういう認識の齟齬を生みやすいこと自体が
>オブジェクト指向の欠陥
>まず分かりにくい思想があって
>その思想の解釈が人によってバラバラで
オブジェクト指向とは、繋がっているけれども独立しているということ。
例えばチンポは自分の体の一部であっても、チンポは自ら考え自分の意志で勃起してシコシコする。 >>491
>純粋関数型以外の関数型言語（関数型をベースにしつつオブジェクト指向の機能を付け加えた言語等）も人気
オシッコの時のチンポは関数型、勃起や射精のときのチンポはオブジェクト指向、違うか？ >>476
> ・オブジェクト指向
> ・メッセージ型 ←これも関数指向
オブジェクト指向のメッセージングは「関数指向」ということだが、オシッコはチンポの役割で、
オシッコを出したり止めたりするのはチンポ、チンポに力を入れたり力を抜いたりするのは俺。 >>105
>そもそもオブジェクト内に状態を持つこと、
チンポは随意筋であり不随意筋である！
>内部状態を操作すること自体がシステムがめんどくさくなったり
>不具合の原因なんだから、そんなこと自体極力やめた
>方がいい。という考え方。
ならばオシッコのチンポと勃起のチンポは別々に分けて考えることが大切だな！
511 デフォルトの名無しさん 2018/10/29(月) 23:32:40.68 ID:LL+W6ENh
随意筋←implements─チンポ─implements→不随意筋 40歳童貞「さーて今日も５ちゃんねるで、オシッコ！チンポ！しこしこ！書き込みっと」
こんな感じなんだろうなｗ 『シコシコ』という擬音はどうでもよい。問題は、
自我 チンポ
↑ ↑ チンポ＝自我
チンポ 自我
オブジェクト指向では、この三種類が考えられるということだ。
＞チンポ＝自我
散歩している時、自分もチンポも所在地は同一である。
https://i.imgur.com/j3uTk1K.jpg
夏目くんの場合は、チンポが自我を圧倒し、体が自然に滝川さんの股間に近づいていったのだ。
『笑ってごまかすな！！』
と言われても、夏目くんは何と言えば良かったのだろう？
チンポ≫自我
『チンポが自我を超えてしまった』を簡略化して、チンポがシコシコする！
チンポがシコシコしていると（チンポが自我を超越していると）、息もハァハァになる。
チンポがシコシコしている（チンポが自我を超越している）と、顔もアヘ顔になる。
つまりその顔は『チンポの一部』つまりチンポの皮と同じということ。
博士号の肩書きがあっても、STAP細胞のそれは間違いであり科学者として失格。
チンポと自我の関係について、それが間違いということなら、俺も科学者を自称するのを止めよう。
しかしながらあの夏目くんは、笑ってごまかす以外に何と申し上げたら良かったのか。 >>549
「オブジェクト指向」について、他にもっと解りやすい説明が有るというなら、ここに書いてくれよ！ >>551
俺が言ってるのは40にもなって
オシッコとかチンポとか、恥ずかしくないのかってことなんだがｗ >>543
そういうことなの？
僕はファイルシステム作ったことないし調べたことないから知らないけど
B-Treeはファイルシステムでファイル管理にだけ使われてるの？ ディレクトリの管理は別であるってわけ？
ディレクトリの検索はファイルの検索よりも遅いの？ どうなってるの？ >>552
>俺が言ってるのは40にもなって
>オシッコとかチンポとか、恥ずかしくないのかってことなんだがｗ
ならそういうあんたが、オブジェクト指向について解りやすく示せ！ カプセル化で困るときってトラブったときだよね
この内部のメソッド呼び出せたら調査やリカバリが簡単なのにって思うことはときどきある
副作用がないメソッドは原則公開でも良いかもわからんね
副作用がないようにメソッドを作る技術も大事 >>555
もう少し具体的な例を挙げられる（マジレスすると無理だと思ってるｗ）
内部のメソッドが呼び出せないことで調査ができない場合を聞いてます。
答えられますか？ いろんなことを思いつくことができる俺がないと言ってます。
反論があるなら受け付けますよ？ 副作用ないならそもそもインスタンス化可能なクラスにする必要もない（？）
必要あってクラス化してるなら副作用抑えるといっても限界があるんじゃね >>553
ディレクトリは直下のファイル名と内部IDとのマッピングリストをコンテンツに持つファイル
親ディレクトリから見れば他のファイルと同じ
NTFSだとMaster File Table(MFT)っていう固定長のデータ構造に
ファイル/ディレクトリごとに1レコードの情報が管理されていて
ファイルのレコードを見ればDiskのどこにアクセスすればのかがわかる
/foo/bar.txt にアクセスしたいなら
MFTのルートディレクトリのレコードにアクセスして
ルートディレクトリのインデックスからfooという名前のエントリを探してfooの内部IDを取得する
それを元にMFTのfooのレコードにアクセスしてそのインデックスからbar.txtの内部IDを取得
MFTのbar.txtのレコードにアクセスしてbar.txtの中身が保存されてるDiskの位置を把握して
そこからデータを読み込む
B-Treeはディレクトリの中に多くのファイルがあっても
O(log n)で検索(や追加や削除)ができるようにするため >>531
触ったこともないようだなｗ
ＤＢサーバーはサーバーゆえ、セッション管理は当たり前
メモリだけでなく一時テーブルも他セッションから見えない
アクセス権の設定もＯＳよりフレキシブルかつ堅牢
扱うものがファイルじゃなく重要な大量データなので、そこらへんはＯＳよりむしろ高性能 そもそも「オブジェクト指向」言いたがるのは開発系にはいない
使ってはいても
むしろ腕がいいほど言わない
言いたがるのは手配師やＰＭなどの「営業系」
または本格的に開発しない「保守系」 >>562
>そもそも「オブジェクト指向」言いたがるのは開発系にはいない
チンポは随意筋であると同時に不随意筋である！ アラン・ケイ？ SmallTalkってカプセル化てんこ盛りじゃなかったっけ？ 自己増殖していくんだから、カプセル化しなかったらまずいべ。 ■ このスレッドは過去ログ倉庫に格納されています
