オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/
探検
オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/
http://www.sage-p.com/process/cool.htm
http://ascii.asciimw.jp/books/books/detail/978-4-04-891309-6.shtml
統合開発環境、デザインパターン、エクストリーム・プログラミング、
テスト駆動開発、リファクタリング、継続的インテグレーションの活用
第3章 C言語とオブジェクト指向
3.1 概要
3.2 Cのモジュール化とオブジェクト指向
3.3 まとめ
第4章 C言語とデザインパターン
4.1 ステートパターン（State）
4.2 テンプレートメソッドパターン（Template）
4.3 オブザーバパターン（Observer）
4.4 チェインオブレスポンシビリティパターン（Chain of responsibility）
4.5 ビジターパターン（Visitor）
4.6 まとめ
第5章 C言語とリファクタリング
5.1 概要
5.2 テスト駆動開発
5.3 TDD入門編
5.4 リファクタリング
5.5 TDD実践編
5.6 まとめ
第6章 継続的インテグレーションとデプロイ
6.1 概要
6.2 継続的インテグレーションの前提
6.3 CIサーバの導入
6.4 CI入門編
6.5 メモリ破壊のバグと戦う
6.6 CI実践編
6.7 まとめ
以前、Linuxのカーネルを読んだ時、オブジェクト指向的なプログラムされているなと思ったことが有ります。
データと関数ポインタをセットにしているイメージですね。（仮想関数的なテクニックだったように思います。）
https://books.google.co.jp/books?isbn=4873113628
> Linux のすべてのフアイルシステムの基本となる共通フアイルモデル
> 〈 c 。 mm 。 n 血 em 。 de ー)を導入し、抽象化を図っています。共通ファイルモデルでは、
> 関数ポインタやオブジェクト指向的な考え方†を採用したフレームワークを提供し、フアイル
http://echo.2ch.net/test/read.cgi/tech/1488928012/422-423
http://echo.2ch.net/test/read.cgi/tech/1488928012/577-578
１ 下記機能をオプションとして持つドアを設計せよ
(a)ドアストッパー
(b)ドアクローザー
(c)ドアの向こう側を目視できるガラス
(d)内部から外部の一方通行のみ目視できるのぞき穴
2. 1.で行ったクラス設計を破壊せずに下記性質を追加せよ
(e)異なる耐火性
(f)異なる開閉重量
(g)鍵がついており、サムターンか電子錠である
(h)異なる遮音性
(i)開き方は右開き左開き、内開き外開きスライドのいずれもありえる
(j)ドアノブはついていることもついてないこともある
3. 2.で行ったクラス設計を破壊せずに下記性質を追加せよ
(k)犬猫はドアノブを回転させることはできない
(l)犬猫はプッシュで動くドアなら、ある一定の重量以下で押すことができる
(m)数匹の犬猫が同時にドアを押すと合計重量で押すことができる
http://ideone.com/or6JyE
ドアをどういうソフトウェアの中でどう使うのかを説明しろよ
それなしに”設計せよ”とか意味不明だぞ
そこに書いてるのはドアの属性だけだから単なるデータ
クラスとかオブジェクト指向とか全く関係ない
こんなんで意味不明とか言ってたらついていけんぞ
このドアに猫を通すにはどうするとか言ってたんだから
〇〇がどう使われるかは全くわかりません
〇〇にはこれこれこういう属性(性質)がありえます
〇〇を設計せよ
ふぁい！？
モジュール分解とか全く関係ない
ドアクローザーは、半開状態時にゆるやかに閉状態へと変化する機構
犬猫が突進すればドアタイプと重量によっては開き、場合によっては開かない
ドアメーカーが生産管理のために使うためのドアのモデル
住宅メーカーが受注管理のために使うドアのモデル
ドア開け系のスマホゲームで使うためのドアのモデル
これらが同じになるわけがないんだから
どういう目的でどういう風にソフトウェア上で使われるのか
それがわからないものを設計しようとするのは時間の無駄
よくよく考えてみるととても難しいが完全不可能ではないしょ、具体的にこんなドアと呼んでないからこそ
どんな状況とパターンでもドアをドアと呼ぶに相応しい共通項を見つけるゲームや
投げる物ではないし食べる物でもないしまぁある程度までは
http://news.mynavi.jp/news/2017/03/30/133/
http://n.mynv.jp/news/2017/03/30/133/images/001l.jpg
Visual Basic 6
VBA
CoffeeScript
VB.NET
Matlab
Objective-C
Assembly
Perl
Lua
Hack
Groovy
Common Lisp
Dart
Erland
PHP
C
Ruby
R
Java
Julia
C++
SQL
Haskell
F#
JavaScript
他のせんたくしが
他の選択肢を比較的簡単に選べるものが上位になってる気がする。
つまりdisりやすいっていう
糞みたいなテンプル貼るのやめろ
名前さえ上がらないCobol
最後にレスした奴が勝者だからな
変なこと言い出したり話がそれたりで、俺がレスしなくなるか
俺が相手をやりこめて、相手がレスしなくなるかだ
そこが決まってないからこそ
物事の捉えかたが人によって違うのがいいんだろ
最初から無駄なのはわかりきってるんだから無駄とかいうな
どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるのは
ソフトウェアの設計やプログラミングの話ではなく言語学や哲学における分節化の話
なので板違い
どういうシステムでどういう使われ方をするドアを想定した結果なのかを示せば
少しはマシだったろうけどそれをやったやつ前スレで1人でもいたか？
コンテキスト無しで現実をモデリングしようとしても設計力は高まるどころか低下するだけ
オブジェクト指向かどうかとか関係ない
無駄
つまりオブジェクト指向は哲学と言うことだな。納得出来る
> どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるのは
取っ手のないドアがあるから、取っ手は共通項には含まれない
鍵のないドアもある。
材質も関係ない。
オブジェクト指向を「現実世界を構成しているクラスを見つけ出す作業」と
捉えるからややこしいことになるんだ。
手続き型でも関数型言語でも、現実世界を表現する関数を見つけ出す作業
なんて考えるやつはいない。
見つけ出す作業ではなくて、作り出す作業なんだ。
現実世界ではなくターゲットとする要件を実現する
クラスや関数を自分たちで作り出す作業。
だから最初に要件が決まらないとクラスも関数も作れない
あたり前のことだが、混ぜっ返すやつは
「そのクラス・関数では世界のすべてを表現できない」と言ってるわけだな。
そういう思考になるのかしらん？
ドアという言葉を定義づけるのと同じこと
言葉を定義づけるには「ドアと窓は何が違うのか？」とか
「ふすまや障子はドアなのか？」みたいに隣接する概念と比較する以外有効な方法はない
で「ドアと窓は何が違うか？」みたいな問いを考えるゲームがしたけりゃ
どっか他でやりなよ
ここは板違い
クラスに落とし込む作業なのだ。
決しての中にあるドアがどういうクラスかを
解析する仕事ではないのだ。
解析する仕事ではないのだ。
同じドアを扱っているにもかかわらず
最初は小売りか設計かと思わせておいて
いきなり「猫に押される」っていうコンテキストも抽象度も異なるものが割り込んでくるのが
問題の肝
多少視点をゆさぶられても大丈夫なのを設計しろってことだろ
そこで状況がわかんないとか言ってたら降参してるようなもんじゃん
迷宮を進むゲームでドアとして表現されたドアがあったとして、そのモデリングの良し悪しを
・家の内装をVR体験させるソフトでも使えるか
・大型家電通販でドア付きの部屋に搬入できるかをチェックするプログラムでも使えるか
・エアコンの空調のシミュレーションでも使えるか
で判断したことがあるのかな。そうだったら何も言えない。
「具体性を持たせることで取り回しが楽になった」に対して
「これには対応できるのか！」「こういう例外はどうだ！」って難癖てるだけだから
「で、おまえの棲んでるとこの方は取り回しどうなの？」って
隠れ家に光浴びせると黙って棲んでる泥に潜っていくというね…
問題の肝でもなんでもないわｗ
そういうふうに設計が変わった時に
安全な方法で設計を変更するのが
リファクタリングだよ。
どっかのバカ共は、汚いコードを修正するものだと
勘違いしているようだがね。
オブジェクト指向に限らず、変更はあるのだから
その変化についていく技術が重要
Swiftが入ってない
やり直し
難癖野郎の要望にも応えられる
C#最高なだけじゃねえか
↓
嫌われている
さすがマイナビ
堂々とすり替えｗ
アンチパターンらしいですけど
世間ではどうやって操作をまとめてるんですか?
まず、アンチパターンだと言ってる人に聞いてみてください。
プログラミングを自動化＝部品化してくれるものというイメージしかない。
プログラマはプラモデルを組み立てているような感覚。
レコードセットとかフィールドとかトランザクションを抽象化することの話？
これがオブジェクト指向の一つの存在パターンやしな
スマホアプリとかの画面パーツはこれで配布してるし
何かの読み物で読みました
名詞じゃないクラスは
オブジェクト指向が出来ていないと
疑えと
じゃあデータベースなら良いのかなと
思いましたが、屁理屈かなとも思い
Commandパターンとかなら理解できるが
データベース操作用にそういうクラスは普通作らないわな
その抽象化がDAOやろ？
お前らの話聞いてたらデータベースにつなぐのに何年かかんだよ
説明だけなら数分もあれば終わるだろうから
それ聞いて接続できるまでの時間はお前次第だと思う。
リポジトリ
名前の通りdbから変数やデータ取り出して入れる専用クラスって意味でいいんだよな？
オブジェクトで使い易いんじゃないのか？？
絶対に数分じゃ説明できない
途中で猫の生態みたいな解説をいれるのがオブジェクト指向だから
SQL叩きますの他の言語とは一味違う
猫の生態とは例えばどんなことを
お前は説明するの？
田舎の中学生が「ぼくのかんがえたアメリカ人」の作り話を大人にしてるみたいになっとるな。
ちゃう。抽象化を間違っちゃったのが、DAO
どう間違ってるの？
【が】が多い
存在が間違ってる奴本人が自己紹介
>>73
DAO 想像力が足りない 辺りでググれば出たくるんじゃなかったかな
あの記事はPHPerのものにしてはとても良く書けているから必読だ。
近くにActiveRecordとDataMapperの実装解説もあるから、まだDAOとか言うゴミを使ってるバカは是非読んだ方がいい。
最終的な実装はあれでもダメダメだけどな。
自分はHogeDTOとか付けてるけど
我流なんで自信が無いです
HogeQueryとかHogeCommandとかHogeJsonみたいなもう少し意味のある名前がいい
お前の個人的なやる気なんか知らないが、
何でもかんでもDTO作りまくる設計は、確かにアホ
最近の連中は技術が無くてストアド書けないと嘆いていたのですが
ストアドでオブジェクト指向は出来るんですか？
C#+EFでほとんどSQLを書いたことが無いので
データベース事情に明るくないもので
一応Ora限定で出来たと思うけど、Web方面だと
エッジサーバ側であれこれするからストアドいらん気もするよ
業務系だとストアド一本で職になるようだが
全てのクラスについて
ヘキサゴナルなんだと、それが……
某大手ITが作ったくっそ高いシステムみたいに
オブジェクト指向も拗らせ過ぎるとこうなるって典型例
最終的な正解が書いてあるサイトはどこですか
その話のどこにオブジェクト指向が関係するのか？
https://togetter.com/li/1097950
オブジェクト指向と言わず
共通の開発手法があるのかなと
モデリングがそれに当たるのかな
I'll tell you nothing.
The answer is where it's present will not be indicate even by Google.
That must find out by an effort and a deliberation of yourself own.
Oh, dont say that!Dont say that.Im a stupid man.You should be kind to me!
ね ぼ け る な！
気持ちの伝わるいい返しだな
ストアドは基本SQLだからDB設計出来る程度のリレーショナルモデルの知識あれば十分
技術うんぬん言うほと難しい話じゃない DBが違えば中身はいろいろと違ってくるけどね
ストアドで条件分岐やループやカーソルを多用してる場合
本当にDBレイヤーでやるべき仕事なのか考えたほうがいいと思う
ビジネスロジックのあるべき場所や柔軟性と最適化のバランス次第
伝わるか！ ボケナス！
オブジェクト指向のために
クラス設計すると、エンティティの
抽出とか同じ事をしている気に
なってくるんですが
モデリングは実はクラス設計だけで
OKとかありますか?
そのためにO/Rマッパーがある。
O/Rマッパーを使うとデータベースのモデリングを
クラスで表現できるから、そのまま移植すれば良い
意識して減らそうとしないと無理かな
ストアドは、テーブルや索引、マテリアらいずビューとかの整理に使う物かな
要は、あるタイミングでデータベースを単一の主体が加工する場合に使うと便利
複数クライアントが平行して操作するときに共通化を求めてやるもんじゃない。
それは、ビューなりストアドトリガーや制約で共通化するべきもの。
条件分岐があるなら、BLに溶け込ませろってのはそういう意味かと
なんかの結果を通信用に設けたテーブルに書いて、そのテーブルを別の主体が参照して連動させるとかオーバヘッドが多く、排他が冗長になり、パフォーマンスがでない。
気持ちのわるいいい返しだな
と読んでしまった
基本的に何言ってるかよくわからない。
例えば集約関数実装することを考えれば、元となるデータの通信を行わなくて良い分、
ストアドの方が速い可能性が高い。
また、複雑なデータ処理や文字列操作が多くてストアド自身のコードの実行が遅い場合もあるが、
ストアドに別言語を使えるRDBMSもある。
さらに言えば、ストアドがimmutableであるなどの宣言ができるRDBMSがあり、その場合は
実行結果をキャッシュしてくれたりする（同じ引数の場合はコードを実行しない）。
ビジネスロジックをRDBMS内部におくべきかどうかというのは、また別の話。
カージナリティーとかに抜けが発生するからね
それからモデル層の設計すればいい
http://ideone.com/lcnAEj
集約関数、つまりある複雑な条件、複数のテーブルを結合せずに参照し、なんらかの判定を行う。
これは一般的なバッチ処理と言われるもので、データベースインスタンスに閉じて実行すればよい。
何らかのパラメータが伴い、レコードのサブセットのみを対象にする場合、ストアドにしても処理遂行を基準に、倉実行してもパフォーマンスは劇的には変わらない。
データベースは、純粋に取り扱うレコード数に比してパフォーマンスが確定する。
あと、結合できるなら、ストアドはいらない。
ビューなりマテリアルズどビューのがまし
やはりキャットドア問題を解決することなく次にはいけんな
集約関数もバッチ処理も理解できないやつは
いちからやり直すかプログラミングから足を洗うかしてくれ
あんただけだよいつまでもキャットドア問題とか言ってんの
……いやなのは「もうOracleにカネ献上するのは嫌なんや！」って奴
既存のストアド見て置き換えなきゃいかんでしょ
最高にクソだったのは1関数5000行if12段のストアド
あれはサジ投げてとりあえずおっつけの改修だけやることにした
設計書なかったんだ、ははワロス
設計書がどうこうとかじゃなくて、「おにぎりスタッバー」程度余裕で超えるド畜生
丸尾末広とか風船クラブ級の理解不能レベル
だから俺のところに来たんだろうが、さすがに当座のおっつけ以上の対応はムリだったな
最低でも2048くらい分岐が発生する
平均的な人間は7くらいしかわからん（Code Completeを参照のこと）
まぁそのくらいあればシノギはできるようだがね
WAISでググるこたぁなかろうし、ググったらヘイトするんだろうけどな
その場その場に応じた最適解を選べばいいだけ
if(a){ if(b){ if(c){ if(d){ if(e){ if(f){ if(g){ if(h){ if(i){ if(j){ if(k){ if(l){
....x;
} else {
....y;
}}}}}}}}}}}}
if(a && b && c && d && e && f && g && h && i && j && k && l) {
....x;
} else {
....y;
}
ここから言いたいことがわかるかね？
先に言えハゲ
ハゲろ
うるせー、ハゲ
ちょっとはまともな文章書けないのかね。
12段ifというのが12個のifということなら、分岐回数は最大で12回。
ネストしない12個のifなら、分岐の組み合わせは2^12=4096個。
>>127のように完全にネストした12個のifなら、分岐の組み合わせは13個。
Code Completeに何が書かれてるのかしらんが、正しく読み取れてないのでは？
あーうん、そんなもんだねぇ2048じゃなかったな
キャンパスノートを2冊くらい使ってメモしつつ
デバッグしてもどこでバグってるのかわからんのよ、あれは参った
とりあえず動くようにはしたがエラー系がすげぇ怖いね
後日何も連絡来ないから気にしなくていいんだろうけど
>>134
変数や関数などは、平均的な人間は7個までしか覚えられないから気をつけろよ、
という心理学の知見が公表されているページがあるんよ
一応クラスだしなぁと
悩んでます
流石に論理じゃ不要と思いますが
年月を問い合わせたら
その年月時点での所属を返すように
したいのですが、どちらのクラスに問い合わせるのが正しいと思いますか
と言うか、所属はクラスである必要すら感じない。
構造体でよく無いか？
とりあえず社員クラスと所属クラスと年月の関係を書くように
部署クラスとかが普通だと思うな
部の下にグループがあるので部署という名前は避けたのですが
部署クラスがグループ教えてくれるのはなんら問題ないことに気付いたので部署クラスに改名しました
社員クラスのフィールドには
·社員番号
·氏名
部署クラスのフィールドには
·部署
·部署配下のグループ
としているのですが
所属部署を知りたい時に、社員に今の所属を聞くべきか、部署に社員の所属を教えて貰うのか、どちらが好ましいのかなとお聞きしたくて書きました
社員がわかっているときは、社員に聞けばいいし、
部署がわかっている場合は、部署に聞けばいい。
どちららでもOKだし、ちゃんと作るならば
どちらからでもできるようにする
これは分かってない人意外と多いんじゃないかと思うけど、
データベース（RDBMSを使わないにしろ）っていうのは、
単体のテーブルの集まりではなくて、全体で一つのデータベースなんだよ
クラスに置き換えていうならば、クラス一つ一つが単独で存在しているのではなくて
クラスとクラス、そしてその関係を定義して、複数のクラスで一つのデータベースを表現する
（ただし設定テーブルのような、他の完全に独立しているテーブルのような例外はある）
だから社員クラスのフィールドには、所属部署というフィールドを持っているだろうし
部署クラスには、所属社員を取得するメソッドが存在している
どっちでもええ、ダメだったら直すまでだ
JavaのAPIというか一回書いたら半永久的に治せないインターフェースを書いてるわけでもないだろ
あるいは大企業の連中が使ってるイミフなフレームワークか
そんなん言っても満足されないならこのくらい
・社員が子会社に転籍とかフツーにあり得るなら「社員」に持たす、全グループ間で同一のアプリ使ってる前提だが
部署だと会社跨いだら引けなくなる設計になってる可能性もあるんでな
・一社だけなら部署でも社員でもノリで決めていい（多分直せるはずだ）
社員に持たすだろうかな
個人のトラッキングが目的なら個人を扱うクラスが責任取るべき
部署に持たすってなら「今日の部署の人員配置状況がわかること」が目的ってことになるんで
Java関係ないやん
interfaceがうるさい連中の筆頭はJavaっ子なんでなあ
パっと思いついたのがアレだった
ンなんだったらJSRにvar変数提案しろよとも思うのだが（あるいはScalaっぽくするか）
Java8のlambdaなんとかならんもんかねぇ
スレッドのラッパーってのは期待してなかった（高階関数と、関数テーブル用途が使えん）
ドロイド君のイベントに差し込むのには使えようが
モデリング的に部署に聞くのはあり得ないとか言われると思ったのですが
ただ、社員にも部署にも問い合わせ可能なのが好ましいというのは驚きでした 冗長と言われそうで考えになかったもので 参考になります
はい？
JavaをオワコンにしようとしてるやつはJavaの何が気に入らんのだ
それでいいよ
でも分岐数4Kって訳でもないんだろ？
それ2048の関数があるのと変わらない
Javaはもともと組み込み言語だったんで、真剣にやると
他言語ではできることがJavaではできないってことがよくある
手数かけりゃそりゃいくらでもできるが、要求が出たら今日リリースできて当然の
職場だと厳しいよ
お客さんからハナシ聞いて1〜2週間後に納品、みたいなのが許されるならJavaでも構わないと思う
まあアレだ「エラーが絶対に出ないこと」ならJavaのほうが有利なのは認めるんで
エラーが多少出てもいいから最速で「だいたい」動くものが必要だって働き方だとJavaキツい
組み込み言語だったことが理由で
他の言語で出来てJavaで出来ないことって何？
エラーが多少出てもいいの
「多少」ってどのくらい？
lispあるいはrubyのlambaか、groovyかscalaのクロージャ
pythonのは不完全だ
mixinとかについてはもうどうでもいいや
>>169
時間的な意味で言うと、半年〜1年くらいでバグレポが電話で届くくらい
社内におったてたReadmineに「今日なんか動きません >_<」って事務員のおぜうさまからご連絡があるとか、その辺
C++メインでオブジェクト指向できるという人は構造化プログラマが多い気がするから業務システムでの採用は避けたい
C#は隠れVB野郎が擬態してる可能性が高いから根本的に避けたい
Rubyは俺が知らないw
構造化プログラムしてるのが5割で、残りは非構造化プログラムってイメージ
C#erがVB程度しか使いこなせて無いかどうかは、Linq使いこなせるかどうかで大体判別可能。
人間にとっては、そのツールの恩恵を受けられる事に多大なメリットがあるけど、言語自体に直接的なメリットを感じないわ。
レッテルでdisってるだけという
泥のアプリに感覚が近い。
フレームワークなんだろうが、あれなしでC#を使うとは思えず、凝ったことはAPIやCOMを自分で使わないといけないような。
だから、業務系システムでC#はわかる。
はい？
コーヒーを飲む人？
コーヒーが飲ませる機能を持っている？
コーヒーを飲む人でないメイドさんか誰かが飲ませてくれる？
今主流のオブジェクト志向はクソ
> コーヒーを飲むって動作は誰にさせると上手くいきますか？
メソッド＝動詞を実行できる人
>>182
2つの物体の相互作用は、それぞれの物体の作用に分解できる
それを設計するとナメるという行為と石原さとみのおっぱいのたゆみ、それによるコーヒーの流れ、流れに応じた舌の移動、さらに石原さとみの悶えという不確定要素など複数のオブジェクト間のフィードバックループを形成しないといけない
現実をプログラムにするというのは非常に難しいものだ
でもたまに、処理を移譲するよなときは主語になる
一定してないから混乱の原因
自信ついたあたりで現実のモデリングをしようとすると面食らう
「コーヒー」クラスが「ドリンク」メソッドで「プログラマー」に代入されてるジョークTシャツ持ってきて
「だからオブジェクト指向は〜」ってやってたのの本人による再放送でしょ。
キャットドア誰も相手してくれなくなったから。
そんなことはないよ。
VB9.0を選択しちゃうウチの職場は
未だにオブジェクト指向を導入していません
そろそろオブジェクト指向開発を調査した方がいいでしょうか
これでスッキリ
これやらないからカスなんだよ
オブジェクト指向以外に解決策を求めてる時点で草ｗｗｗｗｗｗ
person.drink(cofee)
なんでリセットされてるんだよ
悪魔の証明と化してる
朗報だ
キャットドア問題をオブジェクト指向で完全に解決した
https://paiza.io/projects/9D_RVq0fdaUXDugXFTpp2g
カプセル化しないの？
n種類の操作主体がいて、m種類の操作対象があるとき、DoorOpener的なクラスをm個作り、それぞれにnこのメソッドを作るのか？
操作主体が一つ増えると、既存のm個のクラスにそれぞれ一つのメソッドを追加する必要がある
また、操作対象が一つ増えると、あらたにn個のメソッドを作成する必要がある
ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな
カプセル化は頭空っぽの木偶の坊のためにある
オブジェクト指向の本質とは程遠い
クラスを作る、つまり型を定義する事こそがオブジェクト指向
対象と主体の操作は抽象化オブジェクトに対して行うようにしておけば、対象や主体が増えたとしても抽象化オブジェクトへの変換だけ実装すればよい
具象オブジェクトが追加されたときはトランスフォーマとプロセッサを変える必要がある
見通しはいいかもわからんね、抽象化オブジェクトの関係は一箇所に集約されるから
木偶の坊が何か実装するときに何も考えさせないためにカプセル化するんだと思ってたわ
> ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな
まあ、あのコードが最小限だとして、その範囲ですらOCPに違反してるんじゃないですかねって指摘なんだが。
ocpは耄碌したメイヤおじさんの考えだろ
オブジェクト指向がブラッシュアップされる前の
無駄の塊だった頃の話だ
最新のオブジェクト指向では継承もカプセル化も
害悪でしかないことがわかってる
オブジェクト指向が浸透するまでは有益だったかもしれないが、今や誰もがオブジェクト指向を熟知し使いこなす時代、カプセル化はロジックを不鮮明にするノイズでしかない
バージョン管理ソフト使えよと
不鮮明となるのであればそれは用件が曖昧であるためカプセル化できてないと俺は考える
エンジンの仕組みを知らなくてもアクセルを踏めば車は動くようにわざわざ考える必要もない事は隠蔽しちゃおうぜ！ってのがカプセル化だと思ってる
まぁ解釈はそれぞれだから合わせてもらわなくていいけどね
これを違うものとして組めないコードは問題
結局、キャットドアなんだよ
それもそうだな
ドアクラスの変数名をふすまにすればいと思うの
難しく考えずにシンプルな解決策を探そうよ
寝言にもほどがある
中が丸見えで依存しまくってたら
何かするたびに処理の全体追わなきゃいけなくなるだろうが
フスマと回転扉で同じキャットドアが使えると思ってらっしゃる?
ほんとこれ
カプセル化のおかげでどこにバグがあるかもはっきりする
はい
依存しないように実装すれば良いが
んなアホな、それは言い過ぎだわ
話盛ってるわ
間違ってしちゃうかもしれないし、どっかで誰かがしちゃってるかもしれんだろ
Cに++なんてついてなかった時代
配列を関数に渡すとき一緒に配列の長さを引数で渡してた
地獄のような時代があったんだぞ…
言い過ぎじゃない
カプセル化の意図は隠蔽と独立
ガス欠で動かなくなった車に対してタイヤ交換はしなくていい
問題を切り分けて問題解決の速度を向上させるためにカプセル化はとても有効
ちょっと絵に描いてみなよ
ってのが始まりだしね。
ある意味「企業向けオーダーメードプログラムを手作業で人月かけてやるのが
職業プログラマって仕事なんだよっ！！」って請負業者がプログラマ名乗って
コンシュマーに売る工業製品としてのアプリケーションプログラム販売が傍流みたいになってる日本じゃ
「動きゃいい」が蔓延するのもしかたがないこと
UMLでこの図なんていうんだっけ、名前は忘れたけどきちんと設計できる
https://www.fastpic.jp/images.php?file=0258982613.png
それただのたとえ話じゃん
バグが寸分の狂いもなく立ちどころにわかるってのは言い過ぎだよ
構造体に配列の長さと配列をセットで持たせればいいのに
それは設計不足
カプセル化に夢見すぎだよ
バグってる場所が3秒でわかるとか大嘘もいいところだよ
絶対嘘だね、どんなバグかもわかんないしさ
誰が三秒って言ったのよ
速度向上と言ったまでさ
繰り返しになるけど所詮価値観の違いなので合わせてもらわなくていい
速度向上ならわかるけど
純粋関数ってメソッドの中でも再代入を許さないんだっけ？
それって遅くない？ モナド使わないと現実的に厳しくない？
すべてがモナドになればよくない？ そうしてできたのがC言語です
そして構造化プログラミング、モジュールプログラミング、オブジェクト指向のカプセル化と来て
関数型に戻るわけですな
極端なところに正解はないと思うんだよ
バランスが取れているのが現実的に最も優れている
カプセル化してないオブジェクト指向が最高ってことになるのかな？とどのつまり
読みにくいグローバル変数みたいなもんじゃない？
聞く、どうぞお話どうぞ
グローバル変数とは全然違う
フィールドはオブジェクトに属しています
オブジェクトがなければありません
オブジェクトを作って初めて使うことができます
オブジェクトのライフサイクルと運命をともにするからこそ
オブジェクト指向なんです
finalをつけるのがデフォ
極端だろうが何だろうが正解なんかないさ
おまえはおまえの思いでやればいい
すべてを同じ枠に押し込めようとして八方塞がりにならないよう気をつけなよ
俺が俺の思いでやるのは当たり前のことだと思うんだよ
雨が降ったら傘をさせばいいと言ってるようなもの
当たり前じゃん？いう意味なくない？
プールで泳ぐときは服を脱げばいいみたいな
出かけるときは靴を履けばいいみたいな
価値観の違いにこだわってるのはそっちのほうなんじゃないかなって思いました
>>252と俺の共通認識としてあるわけだから、その上で思いを語っていただけたら
俺はカプセル化推奨だぞ
フィールドが全部finalだったらprivateなんて必要ないだろ？
つまり、カプセル化って必要なくない？
カプセル化って無駄を省いてわかりやすいものにして再利用しやすいよう作ることと思ってるからね
そもそもカプセル化はフィールドだけじゃない
インターフェースを用いて処理を委譲させるように設計してしまえばデータだけじゃなく処理を丸ごと隠蔽できるしオブジェクト間の依存関係も稀薄にできる
なるほどね、それはあるね
まぁ俺はまだまだ勉強中だからうらやましいよ
通りすがりだが、年齢フィールドとか一定の幅に制限したい時に勝手に300歳とか設定されたら困るだろう。
だからprivateにしてメソッドやプロパティで0-120なりの範囲に制限するようにするんじゃないの？
入力チェックをデータがやっていいものか
これは議論が別れるところですよ
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？
代数的データ型とはなんぞや？
「300歳なんて異常な数字を送らないように送り手が責任を持つべきだ」
「300歳が送られてきても"数字がおかしい"って返事するようにすれば良くね」
どれがいいと思うかで、その人のそもそものスタンスとセンスがわかるな。
俺ならチェックせずに文字列のフィールドにそのままセットしちゃうね、純粋オブジェクト指向
みたいな？
大きな仕様変更に強いゆるさがあると思うけど
カチカチが好きなタイプのプログラマーは"ゆるさ"の部分が
許せないのだろうな。
え、でもそうでもなきゃ、データの外部でデータチェックとかは関数型言語や構造化プログラミング的な発想だけど。
副作用あるのに、その発想は危険過ぎない？
他の誰かがその外部のチェック用クラスを使ってくれる保証は無いよ？
必要なら必要になったとき必要な人が自分で作れば良いじゃん、自由と自己責任の精神だよ、ルールで縛られたガチガチのオブジェクトじゃままならぬ事もあるでしょう！
オブジェクトが各々責任を持つとするなら、それぞれのクラスでデータチェック(ダブルチェック)が正解なんだろうね。
じゃないと、その二つのクラスは二つで一つになる。
依存関係が出来てしまう。
違うクラスでも、年齢に関するデータなら受け取れるようにした方がいいんじゃ無いかな。
実際には依存関係呑み込んでどっちかしかチェックしないってのが多そうだが。
それを明確にできてればそこを修正すればいいけれど
「私は知らない」「私は受け付けない」「私の責任ではない」って
例外の責任が見えないと責任者探しから始めなくちゃいけなくて
後から来たプログラマが死ぬ。
そうだよ僕たちには結合テストがあるじゃないか
責務の分離だよ
自分の意見を押し通したいのはわからんでもないがな
継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向
265 デフォルトの名無しさん[sage] 2017/04/19(水) 23:10:42.57 ID:2dTlCsss
>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？
266 デフォルトの名無しさん[sage] 2017/04/19(水) 23:12:01.85 ID:qOdNs+TP
>>265
代数的データ型とはなんぞや？
269 デフォルトの名無しさん[sage] 2017/04/19(水) 23:19:37.80 ID:qOdNs+TP
type c = a or b
みたいな？
270 デフォルトの名無しさん[sage] 2017/04/19(水) 23:20:37.20 ID:qOdNs+TP
これもオブジェクト指向と言ってもいいでしょう！
こんなん草生える
> ocpは耄碌したメイヤおじさんの考えだろ
> オブジェクト指向がブラッシュアップされる前の
> 無駄の塊だった頃の話だ
そうでもないけどね。
https://ja.wikipedia.org/wiki/%E9%96%8B%E6%94%BE/%E9%96%89%E9%8E%96%E5%8E%9F%E5%89%87
今でも、OOPの五大原則のひとつとしてあげられるのが普通。
> 最新のオブジェクト指向では継承もカプセル化も
> 害悪でしかないことがわかってる
そうなんだ、それは知らなかったよ。
カプセル化はむしろ危険な直接アクセスを防ぐ意味で常識になってる気が。
でもカプセル化って汎用性悪いじゃん
変数１つアクセスできないだけで実現したいことできなくなっちゃうかもよ?
これ経験則な
> 最新のオブジェクト指向では継承もカプセル化も
> 害悪でしかないことがわかってる
まーたくだらない嘘をつく
すぐにバレるのわかってるだろｗ
害悪でしかないならば、lintなどのツールで使うなって警告が出るはずだ。
そういったlintツールがない（継承やカプセル化を使った時にエラーにする方法がない）
もとから、害悪でしかないっていうのは完全に間違いだ。
反論があるならどうぞ
それ汎用性ちゃうで。
そんな内部実装の細かいとこ勝手に使われたら、バグ修正すらなんの影響があるか怖くてできんくなる。
結局特定用途にしか使えなくなる。
この変数は外部から直接触ることを想定していません。
決められた値以外を入れた時の保証はしませんし、
将来の変更で互換性がない形に変更する必要がありますので
参照しないでください
とコメントで書くわかりに、コンピュータでも理解できる
言語で書くってだけの話なんだよね。
コメントで長々書いても読まないし、
ソースを見ないかもしれない。
そういう時にコンピュータでも理解できる言語で書いていれば
コンパイル時にしっかりチェックしてくれる。間違いがない。
クラスなんて使わなければいいのでは?
帰納的な推理は往々にして間違うものなんだよ
ちょっと邪魔しないで、
反論が出てくるかどうか待っている所だからｗ
反論がでない＝正当性が証明された
などと言うつもりかい？
クラスわ使わないでどうやってデータを管理する？
配列か？
lintで警告が出ないからという権威主義的な根拠はどうなのか
構造体を使うとしてその構造体に連関する関数をどうやって整理する？
構造体ごとにファイルを分けるのは面倒だし、認知行動学的に考えて厳しくない？
整理することこそプログラミング、そのコストが低い言語が良い言語だと思うんだよね
せやな。
必要性がないと判断したんなら使わなければいいんじゃないか？
間違ってないと思うで。
ただまあ、構造体が必要になる所では、ほぼ間違いなくクラス化した方が使い方の見通しが良くなるで。
他人の定めたルールが正当である
それが目に見える形とならねば虚構である
むなしいね
それで何か問題あるの？
だから俺様以外が決めたルールであるかどうかを確認している。
さて反論は？
おまえが満足するならそれでかまわないよ
別に誰かに認められるために学んでるわけじゃないし
もっとも残念ながら俺はカプセル化については推奨派なので反論とかするまでもなくどーだっていい
ただおまえの発想はかわいそうだと思うだけ
そういうことは最初から言わないか？
なんで俺に「反論がでない＝正当性が証明されたなどと言うつもりかい？」と聞いた？
最初から「反論が言えなくても、正当かもしれないだろ！」と言えばいいじゃないか？
それがお前が本当に言いたいことだろ？
それならそれで俺は最初からこう答えるよ。
だから、お前が言っていることを正当だと他人に認めてもらうために、
お前は反論（信頼性があるソース）を出せって。
はい、で、信頼性があるソースは？
lintはろくでも無いクラス設計がまかり通っていたときの負の遺産だ、javabeansやcomが盛んに作られた時代の名残だ、隠蔽して守られるより公開して守られるクラス設計を目指すべき
ソースは俺
正しいという信頼性がある（俺様が決めたルールではないとう）ソースを出せ。
という話ね
よろしくお願いします
見識が狭すぎるのは大変だよって言いたいだけさ
繰り返しになるけど俺はカプセル化について推奨派なので反論するつもりは全くない
おまえの論調は嫌いだがな
それを言うなら相手が違うだろ。
見識が広いやつに対して、
お前の広さを（証拠を出すことで）示してやれ！と言うべきだ。
それが俺も言っていることなんだけどなｗ
で、信頼性があるソースはよ
俺の経験上はだけど、それオブジェクト志向じゃない方がむしろやりやすいで
有無以外のレスを繰り返す相手を
それ以上いじめてはいけない
それと全く同じことでいくらプライベートにしようがリフレクション使いまくる現代のプログラミングでは役に立たない、パブリックにしても問題ないように作るのが真のオブジェクト指向
ソースは今お前の目の前に居る
さあ
そうかい
ならば俺にソースを求めることが見当違いだということにも気づいてくれ
どうやるん？ クラス作らないとできなくない？
その理屈を使いたいならば、ロジックは公開すべきある。
共通鍵暗号方式でも公開鍵暗号方式でも、秘密鍵（データ）は隠すことで安全性を保っている。
そのことから・・・と話をするべきだ。
カプセル化が必要ないことを説明しろよ
だからカプセル化について推奨派って言ってんじゃねーか
推奨派が必要ないと考えるわけねーだろーが
少しは考えて発言しな
秘密鍵はパスワードとかそういう類の物だからそもそもプログラム内に持たないんだよ
プライベート変数は、ファイルに保存しろって言いたいわけ？
秘密鍵はプログラムに書くものじゃないと言いたいのさ
だから秘密にしたいデータ（他のクラスから参照されたくないデータ）は
プログラムに入れずにファイルにしておけってことだろ？
派閥でどうこう言うんじゃなくていち個人として良心から発言していただきたい、カプセル化が必要ないんだという思いと向き合うべきだと言ってるんだよ
違う違う秘密鍵はプログラムに書くものじゃないと言ってるんだよ
秘密鍵はプログラムに書くものじゃない
じゃあ他のクラスから秘密にしたいデータは？
公開しなさい
> 昔は暗号化のロジックも隠すことで安全性を担保しようとしていたけど、駄目だったんだよ、現代ではロジックを公開できる暗号化こそが真に安全性を備えていることがわかっている
違う違う。それは「暗号化ロジック」は公開しろって話なんだよ。
リピートアフタミー「暗号化ロジック」は公開しろ。
それ以外の話は公開しろって意味じゃない。
なんで？
秘密にしたいデータは、暗号化ロジックじゃないよね？
公開する理由がない。
暗号化ロジックは式という形式のデータです
暗号化ロジック = 式という形式のデータ
故に
式という形式のデータ = 暗号化ロジック
と言ってる？
それは明らかに間違いだよ。
そこにはいろんなロジックがある。
その沢山の種類のロジックの中で
暗号化ロジックだけは公開しろ
べき論はよくわからんが、そこまで言うなら個人として伝える
カプセル化は絶対必要である
なんならオブジェクト指向のキモだとも考える
目的に特化させ再利用できるようにデザインすること
きちんとネーミングすること
多様性を持たせるならばインターフェースを用いて処理を実装し移譲すればよい
以上
昨日はシラフで今日は酔っ払っているのかな?
冗談じゃなくそういうのあるらしいね
awsのなんかあれ
カプセル化は単に便利だよね
スコープ的な意味で
最初はクラスの下にでも書いたらいいよ
少なくとも中に書くよりは読みやすいし
後は必要に応じて慣れやね
継承自体はクラス目線でモジュール化を進めた結果で得られる構造なだけであって、
インターフェースのように型を意識させることはない。
結果的にはインターフェース+基底クラスパターンが最強だと思うわ
デバッグや保守の時はカプセル化されたオブジェクトの方が楽。
これはmutableとimmutableにも同じことが言える。
カプセル化しないmutableオブジェクトの方が考えやすいなら
プロトタイプ開発ではそうすればよい。
設計が決まったらできるだけカプセル化したimmutableオブジェクトに変えよう。
関数の名前に構造体の名前を入れるん？ 面倒じゃない？
不変のものをカプセル化する意味あるのか？
フルオープンでよくね？
不変だからこそカプセル化するんだよ
初期状態から変わらないってだけで、
初期状態というものは存在する。
当然それを隠したい場合も存在する。
そうか？ 俺は元々Lisperだし、全く面倒とは思わん
でももし面倒と思うんなら、特にC++とかならオーバーロードがあるんだから構造体名入れなくてもなんとかなるでしょ
この先UFCSも導入される予定みたいだし
ホリデープログラマーが語りだすとこうなる
どうして不変だからカプセル化するんだよ？
なぜ隠すのか？
なぜ？ どうして？
LisperにとってJavaのクラスはどう？
個人的には作業効率が落ちる感じがして好きじゃない
でも低産階級労働者を縛る鎖としてはいいんじゃない？
説明できないのな、じゃあいいわ
バイアスがすごいな
Lisperはやっぱ屑だな
聞く耳持たないヤツに対して説明できるほど理解は深くないんでね
何度も同じことを繰り返しても仕方ない
もしかして低産階級労働者だった？ これは申し訳ないことを書いた。失礼
ホントだよ！失礼極まりないよ！
みんなで考えてみよう
クラスを使わないという発想で作られたから
別にいい悪いじゃなくて、ただ単にモットーの問題
でもクラスは便利ですよ
カプセル化の恩恵そのものがあんまり無い希ガス。
なんだよカプセル化って
ガキの使いでソースに手を入れようとしてるキチガイでもサポートしたいの?
ほらほらボクチンここprivateだから他のクラスから触れないからね!
チンカス過ぎる
SRP原則に則るならカプセル化のほうがいいに決まってる
関数型言語の場合は必ず変数の書き換え(と言うか再生産だが)を行うには関数を経由する。
変数を隠蔽したい場合は、パッケージで変数や関数単位で公開非公開を指定する。
誰から何を隠蔽するためのものなのか明確になってないんだよ
使用者はライブラリ側のソースを一切触ることがなく
提供者は使用者側からの問い合わせや変更依頼を断れない
ここまで立場が明確なときに隠蔽は意味を持つが
すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない
と俺は思う
それだと参照するだけならいいってことになっちゃうよ？
隠蔽するなら不用意な参照もダメだよね。
隠蔽はその変数の操作をそのクラス内に限定するためにある
プロパティを介してprivate変数に代入や参照ができるようにしてるのもそのため
変数の書換禁止ならそれこそfinalつければ済む
>>382
>すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない
誰がいじろうとも修正箇所をクラス内に限定する意味はあるだろ
だからそんなものはアプリケーションの仕様の前には意味を成さないんだよ
それぞれクラスを持ってる方が良いでしょうか
マルチスレッドでも言われるが、参照だけなら基本問題無い。
上でも書かれている通り、隠蔽したければカプセル化じゃ無くても方法はある。
カプセル化と言うか、クラスと言う型に関数(メソッド)や変数(フィールド)を押し込めるのと、関数プログラミング的な考えはメリット/デメリットがそれぞれある。
クラスは依存関係が出来やすいが、GUIなどの多くの状態を保持するのに向く。
一方の関数プログラミングはデータと関数が分かれるので依存関係を少なく出来るが、状態を関数の引数として引き回すのでGUIに向かない。
関数型言語ではa = 1はそのプログラムではずっと1で、2が欲しければinc a とか、succ aとか関数の結果として2を受け取る。
納品したら終わりってアプリを組むときにはカプセル化なんて確かに無用だけど
そもそもカプセル化とかその先のデータ抽象（抽象データ型）とかは、アプリが動いたり大規模化したあと
それをメンテしつつ運用（ちょっとしたバグ修正だけでなく、拡張や機能改変を含め）し続けるときに
それをやりやすくする技術だからなぁ…
個人開発ならばまぁわからんでもないが発想が危険すぎる
頼むからめんどくさいバグを作り込む前にプログラムから手を引いてくれ
何を言ってるんだよ
誰から何を隠蔽するのか明確にしろよ
お前のソースって読み手が完全な傍観者である場合は意味があるけど
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいんだろ
privateにした変数がクラス内グローバル変数みたいな動作してる典型だよね
だからいくつかある方法のひとつがカプセル化なんだよね？
>>390実装依存しようとしている人間から実装を隠蔽するんじゃね？
全然意味がわからない
対象のクラスに手を入れようとしてる人間に対して隠蔽したいの?
これ以上どう簡単に言えるのか？
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいだろ
publicにした変数がクラス外にも波及するグローバル変数みたいな動作してる典型だよね
どこまで影響すると思ってるんだ
調査、設計、対応、試験にかかる工数がとんでもない数値になる
全く意味がわからない
外部設計書とか内部設計書とか
以外の仕様書があってそれに基づいて作成してるの?
ところで全然わかってない自覚があるのになぜ不要と言い張れるの？
不要である理由を明確にしろよ
ソースに記述した定数で処理するも仕様書次第じゃないの?
実装依存が何を指して実装依存って言ってるのかわからない
どのレスの不要?
引用して欲しい
カプセル化不要についてだよ
まさかひとつひとつ違うことに対して不要だと言いまくってたの？
極論すればアセンブルでも作れる。
カプセル化の不要についてだね
おｋ
まず処理の動作は設計書に書くものだろう
ソースでprivateやpublicになってるからどうだってんだよ
ここで反論ある?
だからprivateにして実装を隠蔽する。
これのどこに分かりにくい点があるというのか？
設計書とか仕様書とか関係なかろう
ある
利用者は仕様書を確認することなく意図しない方法で利用する
他は？
と言うか一度に全部言ってくれ
利用者って誰?
ソースを改変するソイツ（?）は設計書を記述せずに対象のクラスを変更しようとしてる?
ソイツのことを利用者と呼んでいてお前の環境では存在しうるの?
テンプレートか抽象タイプと多重ディスパッチあれば継承もいらんしミックスインもいらん
実装する人が複数いる時、自分が作ったクラスのメンバ変数やメンバ関数を利用して
その人の担当クラスを実装する他人が自分のクラスの利用者だろう。
自分が作ったクラスも他人が作ったクラスも変更するのは作った人だけだ。
実装を一人で行える規模ではカプセル化の必要を感じないという話なら分かる。
でも前提なしでカプセル化は不要と主張したら大規模ソフトウェアも含まれる。
もしかして大規模ソフトウェアで必要かどうか全然考えてなかったの?
担当のチェンジは無しなの？
話が止まるからまずは全量を語ってくれ
仮にメンバ変数の実装の詳細を変更することになっても、アクセサを変更しない限り、ユーザコードは変更する必要はない。
間接層の導入による変更の局所化やね。
メリットと煩わしさの比較は人により異なりうるが、少なくとも必要なケースは少なからずあると思うが。
変数を廃止したり形式の変更をしたりしにくくなる。
じゃあ利用者ってのはクラス使用者（そのクラスには絶対に手を加えない）のことでいいの?
そうだよ
javaで言うならStringクラスの利用者はStringクラスの内容を変更しないだろ
いちいち立ち止まらずまずは全量を語ってくれ
ありがとう
ほうほう
だったら仮にそのクラス自体に手を入れることになった場合は
隠蔽対象者ではないということでおｋ?
うだうだ言ってねーで早く語れ
ID:YTf7CJ3Gが楽しんでやっているならとめないけど
いつ何度でも話していいことだと思うが
会話ってそういうものだと思う
人の色恋沙汰なんて4000年前に語りつくされているが
今なお人の心をとらえて離さないだろ
オブジェクト指向にとってカプセル化とは
それくらいの魅力があるものだってこと
会話っていうのは昔々誰々がすでにいったことだから
言っちゃいけない、話しちゃいけないなんてもんじゃない
会話に入りたいって素直に言うべき、カプセル化やめるべきって
ちゃんというべき
ありがとう
うんこタイムの暇潰しなので大丈夫だよ
>>423
べき論はよくわからん
そんなことよりも不要である理由を早く『明確』にしてくれ
仕事の話ではなくオブジェクト指向の話だろ？
おれは１人で好きに作ってるからカプセル化なんていらねー！といわれても会話にならないよ
それはそうだが、誰とどういうレベルで会話するのかってことだろう。
その前にホリデープログラマがどうたらってレスあるから。
お前が明確にするんだよ、カプセル化やめるべきだって言うんだよ
お前の仕事だよ
サンデープログラマを馬鹿にしちゃいけない
俺は必要だと思ってるから無理だな
不要である理由を明確にするのはおまえだ
c言語のFILE構造体の中身を参照する事はないでしょ。stdio.hに定義されていても
それは暗黙的な決まりごとだからだし、それをアクセス修飾子で明示したのがカプセル化って言葉なだけで昔からの決まりごととしては変わらない
どうして必要だと思ってるのか全量を言えよ、じゃないと理解できない
その決まりが要らないものだったんじゃないかっていうのが
カプセル化害悪論の骨子なんだよ
暗黙的なものは暗黙的なままでよかったんじゃないか？
なぜ明示する必要があったのか、それによってプログラムが
複雑になることを受け入れるのか、プログラムがブラックボックス化することに
歯止めをかけてクリーンなオブジェクト指向を取り戻そうというのが
カプセル化害悪論のモチベーション
聞いてるのはこっちだ
はぐらかすな
聞き返したのは俺だ、ちゃんと全量を示せ、逃げるな
捨て台詞まで吐いて逃げるのな？
見栄を張って問い詰められたら逃げるだけの俄かなんだよな
カプセル化害悪論ってのは一理あるし正しいと思うけどね
性善説と性悪説みたいなところだから正解はでないと思うし
ただ、このスレのカプセル化反対の意見はそんなレベルの話じゃない、そもそも議題のカプセル化の認識ズレの話なんじゃないのかな
それは説明したじゃん
402がすべてだよ
カプセル化反対の二人はカプセル化の利害を全然理解していないよね。
害があるからいらないではなく、わからないからいらないと言っている。
んでメリットの説明ってあったっけ?
明確になってねーよ
仮にアレで全てだというなら『まず』とか『ここまで』などと言うな
死亡
例えば>>403がそうだ。
自分だけが使い仕様変更があったら変更するつもりのメンバ変数やメンバ関数は
勝手に他人に参照されたり呼びだされると変更できなくなって困る。
どちらでも無いと思うよ。少なくともどちらかへの「べき」ではない。
隠したいものは隠せばいいし、機械へのポカヨケを埋め込むのも今もうすでに実行不可なメモリみたいなどこのハーバードアーキテクチャだよみたいなの再発明してんじゃん。
>>216はごっちゃにしているね。
実装継承は20年前に「継承より委譲」と言われていた。
その後のEJB2の複雑さの反動でPOJOブームが起きた。
でもカプセル化害悪論なんて聞いたことがない。
おめーのコード出してもらおうか
俺はそれを複雑すぎるとさんざんにこき下ろすから
他人のコードにいちゃもんつけて自分のコードは出しませんなんて
そんなのありえないだろ、ベッドで女のパンツ脱がして
自分はスリーピースをぴっちり着込んでるようなもの
どちらが変態化は言うまでもないよね？
やはりな、継承はオブジェクト指向に必要ないよな
POJOはたしかに話題にはなったが、まだJavaBeansの呪縛から
脱しきれてない過剰カプセル化によって逆に脆くなった
設計ばかりが出回った
いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
聞いたことがあるというべきだし、すぐれた設計だと
後世に伝えていくべき
おまえはおまえのコード以外を認めないんだから黙ってろ
……
別に俺が出すまでもなく、世の中にはそこそこSOLIDを目指したなかなかのコードが死ぬほど公開されてるんだが
> 俺はそれを複雑すぎるとさんざんにこき下ろすから
それらが読めないとしたら、それは複雑すぎる場合もあるだろうが、大抵は君のスキル不足だろうね
試しにgitfubから有名どころの1万行以上のプロダクトを選択してこきおろしてみたら？
>いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
>聞いたことがあるというべきだし、すぐれた設計だと
>後世に伝えていくべき
一切論じられてないよ
悪いんだけどどこらで論じてたのか教えてくれる？
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ
選ぶの面倒とかいいそうだから、俺が選んでやろう
Javaで実装された超有名プロダクト
https://github.com/kohsuke/jenkins
ほら、駄目だししてみ？
>>322 この辺とかすごくいい議論ができてるしとても有益でためになると思う
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ
他人のふんどしで相撲取ろうとするな卑怯者
カプセル化を導入してたらできてなかったと思う
俺は歴史の生き証人
俺には難しすぎて読めませんって白状しろよ
権威や数の力は不要だ、オブジェクト指向をわかっているなら
自力で解決できるはずだ
悪いんだけど根拠のない言い合いに意味はないよ
根拠を示してくれる？
そもそも、キャットドア問題とか知らんし
他人のコード書いてほしけりゃ、仕様示せ
で、キャットドア問題を解決するオブジェクト指向のお前が書いたコードは？
俺は書いたよ、お前にいちゃもんつけられたけど
だから、俺はお前が書いたコードをボコボコに貶してやる所存だけど
お前はその覚悟もできてるし受けて立つ実力もあるんだよな
じゃあコードを書いてもらおうか
このスレにいて知らないはありえない
すれを検索すればすぐにでてくる >>6
>>199程度のコードなら、誰がどう書いても複雑にはならんだろ
俺の>>199の批判ポイントはSOLIDだ
OCPはダメダメらしいが、S,L,I,Dも駄目なら批判しなよ
>>199は俺のコードだからパクっちゃだめだぞ、カンニングは卑怯な行為だからな
あくまで仕様を読んで作るんだぞ
なんだ、>>199と全然違うじゃんか
俺は>>199の範囲で>>199のコードが糞だと断言するわwww
結局自分のコード書けないパターンをちゃくちゃくと歩んでるようだけど大丈夫なのかな
逃げ出しそうだぞ、大丈夫なのかな
カプセル化害悪論の根拠を示してくれるかな？
……
あ、根拠ないんだね
了解
それで了解とか自己完結しすぎだと思う、病んでるよ彼は病んでるよ
じゃあ黙り続けろよ
……
黙ってねーじゃねーか
クソレスすんなハゲ
ごめんね
ハゲでごめんね^^
書けるんだったらオブジェクト指向でキャットドア問題に調整してほしい
オブジェクト指向で、ってそういう事か、なるほど。
ナンセンスだな。
何を以ってドアと成立するか定義できてるようで出来てない。
定義1を死守したければ、俺なら定義1は定義0の子クラスにして、定義2は定義1を継承せずに定義0から作るわ。
定義0は最終的にObjectに収斂する。
クラス設計を破壊せずに性質を追加ってのが矛盾してる。
ワイン樽と泥水の問題。
コードから逃げる人間は飽きるほど見てきた
オブジェクト指向のコードをかける人間はいないのか
俺どっかで書いたぞ
それどこよ？ どれよ？ どこなのよ？ どこーーー！！
860 あ sage 2017/04/14(金) 08:00:23.71 ID:6kAIEFCu
ゴルーチンでドアとノブとストッパーとオートクローザーと個々に置いて、Channelで疎通させたらgoっぽい現実解になった。
ドアノブがあるとは限らんし、ドアノブとは別に鍵があるかもしれんし、とか思うと埋め込みではうまくいかんな。
この辺は機械と同じでコンポーネントにしとかないと後でわけわからん便利ボタン作られたときに面倒くさいと構えてしまったわ。
ラダーのほうがわかりやすいのかけるかも。
しかしideoneすげえな。
866 あ sage 2017/04/14(金) 10:26:30.48 ID:6kAIEFCu
>>862
http://ideone.com/yvttId
クロージャがカプセル化じゃないとしたら
カプセル化害悪論には賛成していただけるよね？
クロージャはカプセル化で、カプセル化害悪論には大反対だ。
カプセル化されてるから、ドアは責任を持ってイベントに対して好きなことを好きなだけできるし、他人はそれに関与せずにイベントの投げ合いで済む。
鍵のないドアだってあるんだから。
見て不快なものが目に入らないようにするためにも使えるんだよ。
NHKの入らないテレビみたいなもんだ。
具体的に誰に対してやってるの?
カプセル化害悪論に反対しているとのことだけれども
もしクロージャがカプセル化ではないと仮定したら
カプセル化害悪論に反対する理由もなくなると思うんだよ
クロージャってどちらかというとローカル変数じゃない？
クロージャオブジェクトを使うところって関数内に限られると思うんだよ
そう考えるなら結局クロージャってローカル変数ってことになるわけじゃん？
だからクロージャを使ってもカプセル化害悪論には反しないんだよ
自分かも知れないし、他人かもしれないけど、それを考えたくない場面でそれが目に入らないようにしてる。
その関数以外書いてるときに、その関数なんて考えたくないじゃん。
>>501
だからクロージャは一つのカプセル化だって言ってるんよ。
ローカル変数って言葉が良くないが、ローカル変数には違いない。ただ、お前が思ってるローカル変数よりも限定的で、そして並行的だよ。
関数内に限られるわけではない。mallocして何かに帰そうが勝手だよ。
クロージャの中でいくつかのコールバックに渡したりするならなおさら。
つまるところ、オブジェクト指向のインスタンスのメンバ変数とあまり変わらん。
はぁ?
ちゃんと設計書は書いてる前提でいいんだよね?
うん。書いてるから何？
書いてるから触ってはいけないとわかるはずだ、なら、無意味かつ実務知らなすぎだな。
書いてて触ってはいけないならば、触れることができてはいけないんだよ。本来は。
AppleのMacOSのUIのデザイン規約くらいの時代から書いてた話。
感電するよって書いてたら覆いをしなくたって良いなんて機械はありえないのと同じ。
じゃ、君の想定してる環境って
本来なら設計書を記述してから修正すべきなのに
それがやりにくい現場ってことでいいのかな?
カプセル化は設計書を記述する手順を踏んだとき役に立たない?
本来なら設計書を記述するどころか設計変更申請出して承認を経て設計書と設計変更書を出して、実装を変更して設計変更書から起こされた上がってきたテスト仕様書でテストして完了するけど、何もやりにくくないでしょ。
カプセル化は役に立つよ。担保となる元の設計書で使ってる部品の設計書を出来る限り見ずに済むし、
なんなら部品ごと新しく変えてもIFさえあってれば良い証左になるんだから。
>>507
プレーキとやらの定義が、踏めば進むというものであるならそう治すべく修理なり改修なりするわな。
このパンチメタルで穴が空いてる部品は共有部品で、AT車ならフットレスト、MT車ならクラッチペダルにつける部品の首がよく腐るから設計変更するなら、
押してクラッチが切れるかもしれない部品であり、押しても何も起こらない部品を同時に設計変更してる事になるが。
お前らのドアってこのパンチメタルの板くらいフワフワした定義。
設計書書いてるんだよね?
だったら今回の開発でそのメソッドを呼び出す奴は決まってる
今後増える予定を想定することの記述も設計書にはないでしょ?
この状態でprivateとpublicになんの意味があるの?
全面的に同意
ふわっふわしまくってるせいでカプセル化が害だとか言うバカみたいな考えなしの意見が出てくるんだと思う
呼び出すやつは決まってる、今後呼び出し方が変わる予定も無い。
ならばそいつはそれがインターフェイスで良いと思うけど、インターフェイスが無いわけではない。そいつがそのものであるだけで。
その上で、疎通にはこれを使おうね、これは使ってくれるなよ、と言う設計は無為味だし、むしろそうならばモジュラーにせずにそれごと機械に埋めてしまえとなる。
そうでは無くて、壊れたらこれだけ変えられるようにしとこう、とか、これだけを改良できるようにしよう、とか、
不具合が出たときに特定しやくすしとこうとなると、ある意味不自由を強制する形で決まった形で疎通させるのは当然でしょ。
お前のパソコンがノートパソコンならタッチパッドは前者、USBマウスは後者だよ。
何?次の開発を想定してるの?
よくわからないんだけど?
問題があったら設計書を修正してレビューしてソース修正する流れでいいんだよね?
カプセル化がどうの
その是非がどうのとはさんざん繰り返されがちだが
アクセッサ自体が意外と臭いよねって観点まで到達できる人は少ない
また、そこから先の議論についてもあまり見かけない
そもそもアクセサなんてものはモダン言語では自動生成なので論外
いつもよくわかってないな
アクセッサなんか書きにくいほうが健全
きみにはまだ伝わらないと思うし
これ以上言葉費やす予定もない
一般的に開発ってこんなもんだろ。
物理的な製造業から何まで、本来は。
問題があったら、設計変更の起案からだよ。
設計変更より作り直したほうが安くつくとか考えないといかんだろ。
ソース修正した後に、何を担保にしてその修正が妥当か、どういうテストが妥当かを定義するときに、組み合わせ爆発が起こらんようにIF定義するんじゃん。
>>514
アクセサのあるprivateなメンバなんか、ちょっと運が良ければチェックロジックなんか入ってるかも？運が悪ければ違う値まで変わっちゃうかも？みたいな、余計に面倒くさい奴だしな。
修正した設計書通りでしょ?
これがすべてに優先されるんでいいんだよね?っていうかそうじゃなかったらびっくりだわ
前のソースは関係ないよ
privateやpublicに意味なんかないよ
修正した仕様書の妥当性はどう計測して、修正したソースの妥当性はどう計測するの？
インアウトが確実に2つずつなら、ステートマシンでも組み合わせ数は知れてるだろうが、
インアウトの数が担保できなければそんなもの検証しようがない。
だから、組み合わせを減らしたい。
いーやわかってないのはおまえ
アクセサの必要性が低いなんてことは歴史的背景ふまえググれば中学生でもわかること
ではなぜ事実上、必須になっているか
そこまで考えてはじめて俺と同じ土俵に立てる
出直せ
アクセサは自動生成されるべきじゃないし、される言語も少なくないか？アクセサ作ったらメンバが生えるのはあるだろうけと。
つまりいずれにしろアクセッサ相当のものを使っているわけで、
問題はアクセッサがいるかどうか？ではなく、
制限をかける必要があるかどうか？
で考えたほうが良い。
意味わからん文になってた。証明するためには全パターンを網羅する必要がある、だな。
されるべきなんだよ
何故なら90%のメンバ変数はアクセサなんて必要としないから
残り10%のために手書きなんてバカらしいだろう
設計書通りに動くことを確認するよ
これができなくなっちゃうって言ってる?
メンバ変数を見ればいいなら、メンバ変数見れば良くない？
アクセサがない限り、見れない書けない方が健全だとは思うが。
>>527
似てるようで違う。
設計書が正しいかが組み合わせ全てを用いないと証明できないし、設計書通りかどうかも同様に証明できない。
インが4本なら16通りだけど、10本だと1024通りだよ。
つまり、設計書のテスト仕様書が必要だ。
そしてそのテスト仕様書通りに設計書が
正しいかをテストする人間も必要になる。
そこで重用なのは、テストの手法である。
設計書が正しいことをどうやってテストするか？
つまり設計書を書いた人間への聞き取り作業である。
設計書に書き漏れがないか？設計書に書かれた言葉に矛盾がないか？
テスト仕様書に従って設計書を見ながら設計者を問い詰める。
これが設計書に対する優れたテスト方法である
それはヒアリングやら検証実験やら、承認者の首やら、人の手で担保するもの
大規模開発した事ないのかな。
アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要
だからモダン言語にはプロパティというものがある
プロパティに出来てpublic変数に出来ないことを考えればおのずとプロパティでいいよねという結論にたどり着くと思うがね
ぶっちゃけそれとカプセル化との関連が不明
もはや何を主張したいのか滅茶苦茶な気がするんだけど
意味わからん。
設計書をテストするものは、設計書のテスト仕様書だ。
つまりその設計には、○○の場合の処理は抜けていないか？
○○の場合に不整合は起きないか？
などというものが書かれいいるもので無ければ、
設計書のテスト仕様書とはよべない。
> アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要
アクセッサはアクセス制限ではなく、アクセスした後に入れようとした値が
正常値かどうかを判断するもの。
型だけでは表現できない特殊なルールを記述する所
アクセス修飾子は単にアクセスできるかどうかしか記述できない。
それは俺にレスするな
>>528の疑問に答えただけだから>>528にいえよ
俺の主張はgetter、setterの是非なんてものは時代遅れもいいところでその解がプロパティだろってことだけだ
プロパティはメンバ関数だよ。
C#ならIL見ればわかるけど、確かアンスコついた変数出来てる。
プロパティ自体もフツーに関数。
何で見えない変数が必要なのか、ってのは、副作用があるプロパティを書くことが出来る限り不必要にならない。
Queueみたいなもののgetのアクセサが、デキューして返すみたいなコードだと、デキューせずに先頭を見る方法が無くなる。
>>534
段取りがおかしい。「設計書のテストの仕様書」が成立するためには、「設計書の設計書」が必要。
なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。
「xxの処理は漏れていないか」は「xxの処理が必要だと定義されている」から書ける。
そのための要件は、すり合わせと設計変更申請のレビューと相手方、担当者の連名の捺印で担保する。
>>535
あるよ。
組み合わせが妥当な手段ではこれ以上ないと言う事が、数が少なくなればなるほど簡単になる。
> なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。
設計書を書く → その設計書のテストを書く
何の問題もないじゃないか
getter,setterとプロパティってシンタックスシュガー以上の違いある？Kotlinとか、getterとsetterを暗黙のプロパティに変換してくれるが。
おまえふざけんなよw
確認作業だろ？
そもそも似たようなことは検収作業でやってるだろ
カプセル化は必要でおｋ
んなことはわかってるっつーの
だからなんだよ
getter setterなんていらねーよという話から始まってる議論になんの関係がある
じゃあどうして>>506からの流れでカプセル化必要派は壊れてしまうん?
そうか
理解できないから壊れた判定して逃げるんだな
すでに酒飲んでこれ書いてるから、異論の必要は無い
public string Name {get; set;} // C#
public string Name {private get; set;} // 多少制限
public string Name {get; private set;} // 多少制限
attr_accessor :name # Ruby
attr_reader :name # 多少制限
attr_reader :name # 多少制限
public int getName() {return name;} // Java
public please forgive me int getName() {return name;} // 仮想OOPL-A
puloccinaucinihilipilification int getName() {return name;} // 仮想OOPL-B
// ↑インテリセンス的なものも当然禁止、emacsのabbrevもなぜか効かない設定
ぜひ収拾つけてくれ
俺にはどーもできん
swiftが全ての正解
#ifdefのくせになまいきな
じゃあ、設計書をかく前提の開発でカプセル化が必要な理由を説明してよ
設計書ベースだと、オブジェクト使うときは
規約をしっかり読んで、それに抵触しないよう用心してコーディングし、
変なことが起こった時
設計書の記述みて、コード上でオブジェクトの使用箇所全部洗って、
操作の規約が守られてるかどうか逐一人間がチェックして、
それではじめてprivateの一言と同じ成果となるのだ
やってられんしそもそも間違えるし
たとえば、インスタンス変数aに依存＆結構コストのかかる計算で決まる値bがあったとき
bをインスタンス変数bにキャッシュしておくほうが得だよね？
publicにしたaの変更をどうやってフックするの？
バカなんだね
君はもうレスしなくていいよ
普通の人間には無理w
ID:rPWpf+kQは頭の出来が異次元すぎるwww
機械語とバイナリエディタでOS作れてもおかしくない
ほんとに信じて言ってるのかと思ってた
そーだよなぁ
ただ喚くだけだしね
dllやクラスファイルの形で、コードの無いクラスもあるんやで？
クラスやメソッドは紙やWebのみってのが。
それとカプセル化になんの関係があるの?
よく考えて発言してねバカなんだから
ずれたコメントさせてもらうが、俺ならそのbを計算した都度出力して、自らはキャッシュしない方策を考えるな。
よく考えて発言してね
まぁ自分がバカと認識してるだけマシだけど
dllで提供されたものが他のものに依存してて単体で動かないとか、動くけど他のdllで得るはずの値を利用すること前提だとしたらその前提を知らない奴はうまく使えない
内部の処理を隠蔽し独立した動きを提供すればいいだけなんだよ
カプセル化でprivateしてないと勝手にフィールド書き込んでしまう恐れがある。
コード無いからprivateにする意味ある。
そんな例。
あ、publicなフィールドを紙やWebに書かなければいいと言うのはなしね。
ツールが抽出するんで。
手書きじゃ無いんで。
設計で呼び出し元に制限を規定するのであれば、試験仕様書には制限外の呼び出しはNGの試験が用意される
上記を満たす実装はカプセル化と呼ばれるのでは？
呼ばない
なんかわからんけど、このバカも睡眠という概念がなさそうだな。
ずれるにしてもほどがある
うーん、ノセられてしもたわ。そもそも論で焼け野原にするのは好ましくはないな。
気をつけよう
そろそろ自分が動的言語童貞だと熱弁していることに早く気がついたほうがいい
動的言語が得意な人は、オブジェクト指向にとって大事なことは何だと思うの？
分けたとしてもどのクラスにどうデータ持たせて
クラス間の受け渡しとかどうすんだよ全部ゲットセットでpublicにしてええんか
データホルダー
計算役
データ管理役
UI仲介役
抽象的だがこんな分け方だろう
ゲットもセットも要らない
全部パブリックフィールドでダイジョブです
カプセル化はオブジェクト指向に不要な概念と言っていいでしょう
クラス分けで悩むならグローバル変数なくしてやりすぎなくらいメソッドを細分化してみたらいいよ
なるほど
世の中の仕組みと一緒だ。
社長が部下に指示を出す。
部下は結果を返す。
社長は、別の会社と連携してサービスを広げていく。
全ては機能を有していて、機能同士が連携してより大きな機能を作っていくだけだ。
日本語的な表現でクラス分けをやるとしたら
「いくつも仕事をしていないこと」というのが目安だろうか
例： 「入力値のバリデーションやる」「設定ファイル読んでパラメータ保持」
怪しい例： 「ユーザー設定をDBから読んでパラメータに基づきUIをイジくって表示する」
数値的な目安が欲しいなら、パブリックメソッドが7以上あったら
そのクラスは複数の仕事を抱えている可能性があるんで、分割を検討する
まあ共通で使うクラスが太ってしまうことはよくあるけど
7ってのは平均的な人間がチラ見でパっと暗記できる事柄のリミット値
MVCモデルとかアーキテクチャで調べる
依存性の注入で調べる
完全コンストラクタで調べる
この辺り守ってれば自ずと決まる
文法が全て同じになって処理のパターンみたいなのが
すべて「名前」で隠蔽されて見えてこない。
処理の委託元のコード追ってもたらい回しにされてる感じで
「実際の処理」がどこにあるのか埋もれてしまってる状態になる。
ライブラリ作成側になると学びは多いよ
スタックトレースを見るんだ
たらい回しというか参照辿って芋づるで引っ張れる設計じゃないし、むしろそこがオブジェクト指向のキモだからな
設計が既に破綻してるって話だわな
ちゃんと結果報告が上がってくれば作業手順は他の人間に影響を与えてなければ関係無い。
図面的な意味で設計どうこうじゃなくて「なんかバグ出てるのはわかるんだけど
誰が調べても原因がわからん」系の状況じゃね？
継承四連打キメてて3段目で特定のタイミングのみ変数上書きワロスみたいな……
無茶いうな
597じゃないけどそういうのは設計が破綻していると言うと思う
図面の設計て意味じゃなくて作成者のプログラミング設計って意味で
つまり仕組みが糞
結局、オブジェクト指向ってただ作るだけなら得意なんだけど
正しく作っているか確認することは苦手なんだよね
そりゃあ設計はあるだろうし、設計通りに作られていれば問題ない。
でも設計通りに作られているのかの検証は、より困難になっている。
延々「経理部が不正やってないとも限らないよね！検証できないよね！」って
無根拠にただ喚いてる奴がいるみたいになってて相手のしようがないんだが、おまえ。
アホ
カプセル化が一番重要と思ってたんですが違うんですか?
カプセル化が修正の閉鎖をもたらし
インターフェースが拡張の開放をもたらす
両方いる
ゲッタセッタが生えてるプライベートフィールドはパブリックと変わらないってことだろう
要するにそれはカプセル化とは言わない
それやるぐらいならむしろパブリックの方がゲッタセッタの裏で余計なことしてない保証になる
俺も重要だと思ってるけどその話題は荒れるので出さないようにしてる
どっちかってと「継承」とか「クラス図」とか「デザパタ」の文脈で話す場合が多いかも
ただ、まあ面倒い
C#の新しいプロパティ構文がJavaでも使えればいいのにな
データの整形はいずれにしても必要なわけで問題はどこで整形するか
クラス外で何カ所も整形の処理書くよりプロパティ内に書いた方がいいよね
ゲッタセッタで公開されたプライベートフィールドと、書式化された文字列を返すプロパティって全然別物じゃんアホなの
SetterGetterの殻に閉じこもってプログラミングする安心感は異常
そんな保障してなんの役に立つ
どのみちオブジェクトを関数の引数にしたら、どこで何されるかわかったもんじゃない
publicにしたら処理をフックすることもできない
へんな値が設定されたときに例外をだすこともできないし
Audio.volumeでボリューム設定なんてこともできないだろう
無条件にやるのはただのバカ。フックいれることが予想される場合にするのはいい
Yes
> getter,setterを通じて変数に触れるのであればそれはもはやprivateとは言えないと思ってる
言いたいことはわからなくもないが、クライアントコードとそのクラスの接点がsetter/getterであると
保証されていれば、内部構造の変更は自由になるというのが異なる。
言ってることはよくわかる
だとしてもsetterは用途が限られるように感じてる
それならインスタンス生成時に必要な情報を全部ぶち込んじゃえばいいんじゃね？と最近考えてる
{
public int setInt;
public string setStr;
}
class2
{
public int setInt { set; get; }
public string setStr { set; get; }
}
この2つの違い教えて
外のクラスから参照・変更するだけなら同じ扱い？
後でconfigの類を入れるとか、setLoggerだとかで
必要になる場面がたまにあるかも
なおPythonでそれやろうとしてプロパティデコレータ使おうとしたら「setだけのデコレータはない」というので
またPythonの俺様仕様か……って閉口した
obj.x = 1 #=> これは出来る
obj.x #=> 例外
になって欲しいってことか？イラネ
obj.config = user_config
みたいなのだ
setconfig(user_config)でもよろしかろうが、readwriteとreadは機能としてあるけどwriteはない
なんて片手落ちはあんまり想像してなかった
「正しいやり方はwriteイラね」とかマニュアルに書けってよ
直接さわることとは別物だよ
それはみんな分かってるんじゃないかな
>>583あたりからの流れで、全部のフィールドにゲットセット持たせることの是非を言ってるんだと思う。
フィールド（メンバ変数）が複数あったとして、ゲットセットする需要というか意味があるのは
ごく一部なんじゃないか。
setterで引数のチェック、getterでoutはコレであってるかのチェックはもれなくやるべし
現実： やらなくてもだいたい例外が飛ぶか動かないかするからわかる
こんなつまらん事でわざわざバカにエサを与える必要はない
柔軟に拡張できると受け取れば良しとなるし、不要な可能性を残すと受け取れば悪しとなる
個人的には単純にゲッタセッタで命名しといてくれるとインテリセンスでプロパティ探す時楽だからあった方がいい
ただゲッタセッタで命名しときながら裏で全然関係なかったり重い処理してる糞コード書く奴が一定数いるのも現実
cはある程度書ける
うまいやつに自分が作ったモデル添削してもらえ
一瞬で上級者になるぞ
本はしらん本よみまくったけど結局それだけだとだめだった
ダイクストラ知らないとかゆとりかよ
変な意見だけどHaskellを勉強する。
割とマジで。
互いに疎とか、モナドとか高階関数は依存関係解消のヒントになる。
自分の言葉で説明して欲しいです。
Wikipediaとか読んで自分でそれをできるようになったがいんじゃない？
関数、if、whileを使ってプログラムを書くこと
誤解を恐れず言うならswitch、forは邪道です
次はお前の番だよ
wiki読んだけど、それぐらいの意図しか汲み取れなかった。
オブジェクト指向では、ポリモーフィズムとか使えるけど、それも結局はクラスでifしてるだけであって、たいして変わらないじゃんと思った。
ここを見てるとどれだけ自分の頭が固いかよくわかっておもしろい
自分で自分が書いたスパゲッティをメンテするところからやらせねぇと
なんで生まれてどんなメリットを目指したかわかんねぇんじゃねぇの
ゆとりには
こんなものまで擬人化しないと気がすまんのかお前らｗ
キモいにも程があるｗｗｗ
同等じゃないよ
ポリモーフィズムはそもそも参照先が違う
演算によって処理を分けるif文とは全く違う
呼び出す側が適宜、相手のインスタンスに「こういう動作して」って派生クラスぶっこむ場合が多いな
まぁ派生元 - 派生先でifしてるって捉え方もできようが
if - elseが下に7コ8コ並んで見難いのよりはマシだろう
Objectの言葉の意味の通りじゃん
http://www.sikaku.gr.jp/js/jv/img/sample/1/jv1.pdf
過去に構造化プログラムとかクソ味噌言われていたので、オブジェクト指向に造詣の深い皆さんに評価して頂きたいです
やめとけ
稼いだ金額が理解度
実務でやるなら、4番のシーケンス図よろしく「N」なんて打ち込ませねぇ
そもそもあんなクソみたいな手数を踏ませるはイカれてるっていうか、ユーザーは怠惰なんス
一手で済ます
たぶんログイン画面でセッション（あるいは何らかの認証情報）を持たすのが前提だあな
っていうか「Fuckyou」とか「let me die」って打ち込んだ時どうすんだね
この図だと未定義だから何してもいいよね、俺だったら「Fuckyou」ってタイプされたら水龍敬ランド出すし
「let me die」ってタイプされたらガルパンのまほお姉さまのエロ同人誌でも表示してやるわさ
……冗談やで？
というくらいなんかアレかも
まあいいや、見直すとして……ああうんお呼びでないか
シーケンス図を（マジメに）見る限り
・初めに二回ポップアップ出す（or二発画面遷移をせよってこと、メソッドが二発あるので）
・ユーザーがNっていれたら、初めに出たのとの同じポップアップを2発やる（displayFirstMess/displayPromptMessをもう一度ぶっぱしてるから）
・imputMessageでユーザーが入力をいれたら
まずユーザー一覧を表示するのか、「検索方法を指定してください」と出すのかして（displayFirstMessはどうもでっかく二分岐してるのかもしれん、あるいはまた「検索方法を指定してください。」と出すのか）
そのあとでallDisplayでドカっと下に長い表示を出すのか
この辺要確認、たぶん書き手はそんなの想像してないと思う
たぶんGoogle検索のようなのを想定してるはずなので
・ユーザーは表示された従業員名とID突き合わせて入力欄にID打ち込んでEってタイプする
ここも確認が必要、クリックじゃねぇの？
ああうんこれメインフレーム時代のやり方やで
俺以外望んでないけど未定義だからいいよね（実務じゃしないよ、冗談だから）
squeak/PharoみたいなGUIなsmalltalkじゃない事でシステムブラウザ(動的クラスリファレンス？)無しじゃ相当厳しい。
Ubuntu Linuxでsudo apt install gnu-smalltalkしただけじゃgst-browser起動しなかったから、
tar玉落としてコンパイル段階から環境構築してやっと動いた。
んで思ったんだが、やっぱオブジェクト指向ってクラス覚えないと何も出来ないんじゃね？
中途半端なオブジェクト指向言語って構造化プログラミングの文法に助けられてて、
その辺誤魔化せてるだけのような気がして来た。
システムブラウザまで使うならなぜGNU Smalltalkみたいな変わり種Smalltalkにこだわるのかわからんけど（何かPharoやSqueakじゃ駄目な事情が？）
クラス（というか組み込みのオブジェクト）の使い方を覚えないと何も出来ないというのはかなり正しい
ただそんなこともあってSmalltalk環境は相当早い段階から組み込みの（クラスを含む）オブジェクトに対する問い合わせ
つまりイントロスペクション機能やそれをサポートする（人間の短期記憶に負担をかけないようにする）
マルチウインドウシステムが発達したわけ
だから、繰り返すけどそれらの機構を大胆に削ったのウリのGNU Smalltalkで
「Smalltalk（やそれが体現するOO）が何か」を論ずるのはちょっと違うかもと老婆心ながら
アランケイにも捨てられたゴミ
> 何かPharoやSqueakじゃ駄目な事情が？
すみません。ちゃんと理由が書いてありましたね。^^;
>>670
> コマンド作るべく
ただ最終的にGNU Smalltalkを使うにしても、まずはSqueakやPharoから入るのがいいかとは思います
>672
> アランケイにも捨てられたゴミ
アラン・ケイが Smalltalk を見捨てた発言をするのは宮崎駿の引退宣言みたいなもので
最初は1976年ごろからはじまって、10年ぶり5度目とかの恒例です
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
IDEを使うためにはヘンテコなOSモドキの使用を強制され、
それを我慢して使っても他の言語より書きやすいわけでもなく
マイナー言語なのでライブラリも少ない
まさにゴミ
まあそう言わんと
ただヘンテコなゴミだと簡単に切り捨てるより、いろいろ調べて学びを得た方が面白いですよ
同時期に登場したStar、Cedar、Interlisp-D等、同様のOSモドキはいくつか生み出されましたが、
結局生き残って今も使われ続けているのはSmalltalkだけです
たまたま選ばれたということ（ジョブズやゲイツがそのルック＆フィールを模倣して広めてくれたということも含め）
もあるかもしれませんが、ホストOSに寄生する“異物”という宿命を背負いながらも変化を続け
趣味はあってもスタートアップで言語として選択される程度に有用であることは
ケイらの遅延結合性の徹底というコンセプトの有効性を示すよい例かとも
Smalltalkの底を流れる設計思想 - ダン・インガルス
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#
「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html
いあ、昔squeakやってたし、当時はクラスブラウザと自由自在Squeakあれば十分なくらい独学しやすい言語だと思ってた。
当時はJavaのクラスリファレンス(とら本)も分厚いのを上下巻2冊で売ってたし、クラスたくさん覚えて行くのが当たり前と思ってたからね。
HaskellもLispも、関数覚えておけば便利だけど、覚えてない知らない場合も自分で自作しやすい。
そう言う意味じゃCとかの構造化プログラミングも関数やクラスを基本にするんじゃなくて、Goto使わなくて済む構文によってスパゲティコードを無くすっていう自作し易さを目指す進化だったんよね。
Squeakは経験済みでしたかそれは失礼いたしました
ただSqueak等でちょっと調べてみれば分かりますが、他の言語やそのIDEのやり方とは違いSmalltalk環境のGUIツールは基本
クラスを含むオブジェクトの持つイントロスペクション機能にちょっとしたGUIのガワをかぶせただけシンプルなしくみで動いています
それはつまりGNU Smalltalkでも、Squeak等が“GUIのガワ”が中でやっていることを式で書いてやればそれなりのことは事足りるということです
たとえば Integer >> #factorial というメソッドのソースが読みたければそれに methodSourceString というメッセージを送る
(Integer >> #factorial) methodSourceString
といった調子で、そしてこれがSmalltalkのシステムブラウザがやっていることのほぼ全てです
じゃあ、factorial や Integer はともかく、>> だの methodSourceString だのはどうやって分かるかというと
もちろん GNU Smalltalk のリファレンスをググるのも手ではありますが
#>> implementors で実装クラスを一覧したり、
#>> implementors anyOne methodSourceString で定義を見たりするのがSmalltalkでのやり方になります
覚えておくよりはその都度オブジェクトたちに尋ねるという彼らとの対話の妙をぜひお試しあれかし
> オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化
出来合いの（組み込みの）機能といっても、元は自作なんですよ（少なくともSmalltalkにおいては）
それらを簡単に実装できるという精神はHaskell、ひいてはFPに通じるところはあると思いますよ
それにHaskellにしてもパターンマッチや型クラスを含む型システムなどの便利な組み込みの機能の助けなしに、あるいは
リストなどのモナドの拡充なしに自作のしやすさの加速ができるわけでもないような気がしますが…違いますかね
オブジェクト指向は、複雑さ、巨大さとどう戦うかというのが進化の方向
HaskellやLispでデカくて複雑なプログラム書いてみたら、オブジェクト指向にも有用な部分があることを理解できるんじゃない？
ちょっとしたコードの書きやすさだけで言語の良し悪しは決まらないよ
基本的にあの辺りはインターネットみたいな動作しっぱなしの世界で
クラスってノードを動作中に抜き差しするみたいな感覚を指向してるからなぁ。
その都度オブジェクトたちに尋ねるのが、まさにsmalltalkがオブジェクト指向の最たるものの所以で、当時も今もそこについては変わらないんですけどね。
さすがにgnu-smalltalkでは一覧性に難ありな所が＾＾；
逆です。
その便利な機能のみで、入出力とかはともかく、自分がこう動いて欲しいと望む機能を実現できる。
そこに関してsmalltalkとFPに通じる所があるのも同意します。
ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。
smalltalkって制御構造もメッセージで実現してるけど、Haskellと同じで構造化プログラミングを模倣してるだけで、やや普通のオブジェクト指向言語より構造化プログラミングから逸脱してる気もしますし、確かに生産性は高いんですけど。
ただ、既存の関数やメソッドを一切使わず新しい機能を実現する手間は、その基本的な便利機能の充実度から、Haskellのが生産性は高いかと。
探すより作った方が早い場面もありますし。
(いあ、smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが)
昔はGUI部分も同じ言語で書いてたからオブジェクト指向が有用だったですが、今はGUI部分はHTMLなりXAMLで書くことも増えて来ましたし、複雑な部分はDSLに任せて分担作業が、複雑巨大なプログラムに対する解の様に思います。
> さすがにgnu-smalltalkでは一覧性に難ありな所が＾＾；
> ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。
具体的にはどういったところがでしょうか？ 後学のため教えていたければ幸いです
> smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが
SmalltalkがOSモドキと忌み嫌われつつもイメージベースで居続けるのはこの利便性を捨てないためです
ユーザー定義のものも組み込みのものも区別せずにオブジェクトストアに保持し、OODBのように探せます
実行時についてはそうなのですが、それを設計や運用時にも徹底する（それをサポートできるシステムであること）がミソです
決定をできるだけ先送りにして固定化しない、ぎりぎり直前でも（場合によっては事後でも）差し替え可能に保ちます
基本的な考え方はこちらに書かれていますのでよかったら読んでみてください
「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html
アラン・ケイもよく言っていますが、これができるのはおそらくLISPとSmalltalkくらいかと
あれ。
Squeakの時に低レベルのもの書く時って、それ用のsmalltalk無かったでしたっけ？
名前忘れたけど。。。
gnu-smalltalkみたいなのが主流にならないと、結局OSモドキに引き篭もって外とやり取りなんですよね。。。
例えば鯖のログを必要な箇所だけ見れる様に加工したいって時でシェルやLLが使われますが、smalltalkはその代替えにならない。
その為だけにOSモドキを立ち上げる手間が壁になる。
まあ、それはHaskellも微妙な立場なんですが、シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。
ただ、コンパイルが遅いので、LLとどっちが便利かが微妙になるだけで。。。
smalltalkはOSモドキと一体の生産性ですが、現実問題、言語は問題解決の手段であって、手段を使用する事自体に手間が掛かってしまっては元も子もないと考えます。
。。。Haskellもその点で微妙ですけどね。
(runghcでLLとして実行しても型検査はするから起動がLLより遅い)
Haskellのパターンマッチや遅延評価やモナドは作り手の知識が少なくても「作りやすい」仕組みだと感じます。
一方のsmalltalkは知識が少なくても「探しやすい」仕組み。
そう感じました。
LLはどっちも80点だけど、総合点で上回る的な。
でも規模が大きくなると型付言語が欲しくなる。。。
> シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、
> Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。
つまりHaskellでは組み込みの関数をいっさい知らなくとも（使わなくても）ログの整形作業が自作できるのですか？
それは驚きですね（反語的に）
結局ライブラリ使った方が早いんですが、学習しながら作ると言う意味では即戦力です。
だからなんだと言われればそれまでですが、GUIとかのライブラリがポトペタで作れたりしないので開発環境としてはまだまだですが、言語としての学習コストは低いと思ってます。
そんなことが可能な言語がこの世に存在するとはにわかには信じられません
実際に動作するコードを見せてもらうことは出来ますか？
でも、その中間の整形処理は一切組み込み関数知らなくても作れますし、その行為自体もそんなに手間じゃ無いです。
Cとかでもある意味整形処理は全部自作出来るわけですが、手間が全然違います。
smalltalkもそう言う意味では少ない知識で自前で作れると思いますが、ロジック部分に関してだけは、Haskellのがより少ない知識で済んでると思います。
GUIまで含めるとライブラリの塊と言うかライブラリそのものなsmalltalkのが生産性は高いんですが。。。
それこそsmalltalkそのものがOSとして普及しないとあんまり意味がないと言うか。。。
もう出勤1時間前なので流石に今日は作れませんが、何かコードを提示して、組み込み関数を自作して行きましょうか。
上でも書いたですが、制御構造と最低限の入出力関数があれば作れはします。
手間の問題というだけです。
> 今日は作れませんが、何かコードを提示して、組み込み関数を自作して行きましょうか。
おもしろそうですねぜひお願いします
> それこそsmalltalkそのものがOSとして普及しないとあんまり意味がないと言うか。。。
Dockerとかありますし、ホストOS内でOSモドキを動かすことにマシンパワーや心理的障壁は下がってきていると思いますので
「意味がない」と言うことはないと思いますよ
実現するための手段が
オブジェクト指向じゃないの？
そういう意味ではオブジェクト指向が
なくてもプログラミング出来る。
しかし重複部分を無くすには
オブジェクト指向しかないでしょ？
たしかに、昔に比べれば仮想化が当たり前になりましたしそうかも知れませんね。
急ごしらえですが、昼間寝てしまったので３時から急ごしらえで作りました。
使い勝手悪いので、行番号振ったりと改良の余地ありです。
import System.Environment
import Data.List
filterOfLine word = unlines.(filter (isInfixOf word)).lines
main = getArgs >>= \(file:word:_) -> readFile file >>= putStrLn.filterOfLine word
IOな関数は全部mainの方にあるので、自作するのはfilterOfLineのunlines,filter,isInfixOf,linesの４つということになりますね。
unlines [] = []
unlines (xs:xss) = xs ++ "\n" ++ unlines xss
ちなみに、++も自作出来ます。
（全ての中沖演算子はカッコで囲めば２引数の関数になります）
(++) xs [] = xs
(++) [] ys = ys
(++) (x:xs) ys = x:(++) xs ys
filter _ [] = []
filter f (x:xs) | f x == True = x:filter f xs
filter f (x:xs) | f x == False = filter f xs
isInfixOf _ [] = False
isInfixOf xs ys | take (length xs) ys == xs = True
isInfixOf xs (y:ys) = isInfixOf xs ys
もちろんtake,lengthも自作可能。
take _ [] = []
take 0 _ = []
take n (x:xs) = x:take (n - 1) xs
length [] = 0
length (_:xs) = 1 + length xs
lengthはリストｰ>値なので末尾再起にしないとスタック消費するので、
末尾再起な補助関数使って作ったほうが良いですが。
length xs = length' 0 xs
......................where
.........................length' n [] = n
.........................length' n (_:ns) = length' (n + 1) ns
変なところでハマってました・・・。
lines ns = lines' [] ns
...................where
......................lines' [] [] = []
......................lines' ys [] = ys:lines' [] []
......................lines' ys ('\n':xs) = ys:lines' [] xs
......................lines' ys (x:xs) = lines' (ys ++ [x]) xs
かわいそうに
ありがとございます
リストとパターンマッチのコンビは強力ですね
お礼がてら GNU Smalltalk でも書いてみました
普通に手続き的に書くとこんな感じです（インデントの全角スペースは適宜置き換えてください）
#!/path/to/gst -f
argv := Smalltalk arguments.
file := argv first.
word := argv second.
stream := FileStream open: file mode: FileStream read.
[stream atEnd] whileFalse: [
| line |
line := stream nextLine.
(line indexOfSubCollection: word) > 0 ifTrue: [line displayNl]].
stream close
少しだけ関数型的なものを意識するとこんな感じになりますか
#!/path/to/gst -f
argv := Smalltalk arguments.
file := argv first.
word := argv second.
lines := file asFile contents lines.
filtered := lines select: [:str | (str indexOfSubCollection: word) > 0].
joined := String join: filtered separatedBy: Character nl asString.
joined displayNl
結局メソッド頼りですね。。。
いあ、全てがオブジェクト故のメソッド依存ですね。
Cとかなら、むしろ長くはなりますがロジック部分の関数は自作出来ますもんね。
Haskellの例はよく車輪の再発明と馬鹿にされますが、車輪の再発明しやすいと言うことは、少ない知識で基本的な関数から応用的な関数まで作れると言うことだと思います。
>>697を複数ファイルで串刺し検索と行番号表示に対応させてみました。
(myfunc.hs + searchword.hs)
使用例:
>searchword numbering myfunc.hs number.hs
行番号表示機能のみのコードを以前作ってて、それを改良した形です。
(myfunc.hs + number.hs)
ファイルにmyfunc.hs + OOとなってる通り、共通だったり今後も関数として使いそうなものはライブラリとして括り出してみました。
module Myfunc where
import Data.List
import Text.Printf
consNum::(Int,String) -> String
consNum (i,xs) = printf "%4d:%s" i xs
numbering = unlines.(map consNum).(zip [1..]).lines
searchWord w = unlines.(filter (isInfixOf w)).lines
putFileContent (f,cs) = printf "%s\n%s" f cs
number.hs
import System.Environment
import Myfunc
zipFileContent fs = return.(zip fs).map numbering
main = getArgs >>= \files -> mapM readFile files >>=
............zipFileContent files >>= mapM_ putFileContent
import System.Environment
import Myfunc
zipFileContent w fs = return.(zip fs).
...................................map ((searchWord w).numbering)
main = getArgs >>=
............\(word:files) -> mapM readFile files >>=
............zipFileContent word files >>= mapM_ putFileContent
> Cとかなら、むしろ長くはなりますがロジック部分の関数は自作出来ますもんね。
いや、メソッドでもロジックは記述できますよ→http://ideone.com/xiEftE
逆にできないと考える理屈がちょっとわかりかねます
> 少ない知識で基本的な関数から応用的な関数まで作れると言うこと
言語それ自体の学習には向いていますね
SmalltalkはライブラリはもちろんIDEを含む処理系それ自体もSmalltalkで組まれているので
普段自分が使っている機能がどのように実現されているかを調べる過程で学習ができます
GNU Smalltalkはそこらへんがちょっと弱いのが難点ですね
無用かとは思いましたが、通常の方法で記述したナンバリング＋複数ファイル対応版も
#!/usr/bin/gst -f
(argv := Smalltalk arguments) isEmpty ifFalse: [
word := argv first.
files := argv allButFirst.
files do: [:file |
| count |
file displayNl.
stream := FileStream open: file mode: FileStream read.
count := 0.
[stream atEnd] whileFalse: [
| line |
count := count + 1.
line := (count printPaddedWith: Character space to: 4), ':', stream nextLine.
(line indexOfSubCollection: word) > 0 ifTrue: [line displayNl]].
stream close]
]
ちゃうちゃう。
関数やメソッド抜きと言うか、知識がない場合でもって意味。
確かにsmalltalkの場合はガンガン調べられるのが強みですが。
うーん。。。調べる能力と作る能力の違いと言うのでしょうかね。。。
実際問題、smalltalk程の検索性は無いものの、haskellの関数もhoogleで大体ソース見れるんですが、今回敢えて見ませんでした。
(実はlinesだけ見たけど、逆に複雑過ぎて訳わかめでした)
実際のソースは効率とか可搬性も考慮されたソースですから、私ごときのソースと同じと言うことはないですが、表面上の動きだけは真似られます。
私の中では分岐さえ言語でサポートしてくれれば、ロジック部の自作はどんな言語でも可能で(チューリング同等)、haskellは分岐でifとかの余計な文字入れなくて済むのが楽だなぁとか、リストが基本だからアルゴリズムと相性良いなぁとかですかね。
配列だとリストが基本のアルゴリズムから、配列だったらどう実現する？って考えますから。
多分、最前線でプログラマしてる人はそう言うのを自然としてるんでしょうけど、私みたいなヘッポコは一旦haskellでワンクッション置くと普通の言語でもコード書ける様になりますね。
(少なくとも私は)
> 分岐さえ言語でサポートしてくれれば、ロジック部の自作はどんな言語でも可能で(チューリング同等)
仰りたいことは分かるのですが、マシン語やラムダ式ましてチューリングマシンで何かを記述するのは
知的愉しみや学術・学習目的でならともかく、通常のプログラミングにおいては苦痛しかもたらしません
生産性を考えるなら、言語の機能や特性は
車輪の再発明のしやすさより、あるレベルまでのレイヤーの適切な抽象化に費やされるべきです
そういう切り口でメッセージングというパラダイムはいろいろなレベルの抽象化されたレイヤーに乗っけて
便利に使えるので私は気に入っています
みたいな典型的な文法使ってくれる文には問題ないが、
関数内や引数のカッコ内で new したり、
コンストラクタ内でさらに new したり、
Person(new Car() ) みたいにコンストラクタの引数内でnewしてたり、
オブジェクト名のはずが array['taro'] みたいにクォートで囲まれて
'文字列' として連想配列のキーに指定されたりすると、
俺の中での「オブジェクト」のイメージが色々と崩壊する。
これどう解釈すりゃいいの？ってなる。
お前のオブジェクトのイメージがおかしいんじゃね？
コードのわかりやすさ優先だけど
関数言語は「?って書いたらPRINTのことに決まってるだろ」って
『略語でタイプが減ってサイコー』厨が推進してる臭くて
どうにも胡乱(うろん:確かでなく、怪しいこと。うさんくさいこと)なものを感じる。
オブジェクト指向言語はクラスリファレンスがすべて
それって結局ライブラリが揃っていて、探しやすければオブジェクト指向とか構造化プログラミングとか関数型とかのパラダイムはどうでも良いって言ってる様なものだなと。
そして、実際その通りなんですが、全てのプログラムのパターンを網羅するライブラリは事実上不可能です。
Delphiのコンポーネントでpascalインタプリタがあってポトペタで一行のコードも書かずにpascal処理系を作れたとしても。
結局どの言語もライブラリの関数なりクラスなりを組み合わせます。
smalltalkは検索しやすい方向へ進化し、Haskellは自作しやすい方向に進化したんじゃ無いかと。
そのsmalltalkコードは出力に依存してますが、私もRubyやPythonでよく書きます。
Haskellの場合は強制的に出力に依存しないコードになるので、number.hsのコードの最後の行を
mapM_ (putFileContent.(\(f, c) -> (f, searchWord word c)))
の様にputFileContentの受け取る値を横取りしてsearchwordコマンドを作っても良いです。
型さえ考慮すればnumbering以降から出力直前まで、好きな段階でsearchWord関数を使えます。
numberingとsearchWordそれぞれlines/unlines使ってるので汎用性高い代わりに無駄な処理も多いと言うなら、汎用性を犠牲にしてsearchWordにnumberingの中身を入れてしまえば良いです。
この様に特異な発想？にも柔軟に答えてくれます。
> 全てのプログラムのパターンを網羅するライブラリは事実上不可能
ライブラリで、将来起きうるすべてのパターンを網羅しろというのは極論では？
学習目的でないなら車輪の再発明は避けるべきだし
よく使うパターンならライブラリ化（抽象化）されるべきだろうという主張に対し
件のご指摘は本末を転倒しています
> そのsmalltalkコードは出力に依存してます
「出力に依存する」ということの意味がわかりにくいのですが
抽出結果を各行逐次出力しているのが気にくわないのでしょうか？
それならそうでない処理の流れにすれば済む話で実際にも容易に書けます
（>>706 の２番目や >>706 の http://ideone.com/xiEftE 、http://ideone.com/RUJP49 ）
当初要求された仕様がどうなっていたか、何を重視するかといった方針の齟齬に過ぎないと思います
逆にたとえばご呈示のHsakellのコードで
メモリに一気には読み込めない巨大なファイルを扱わなければならないとしたら
今の枠組みのまま対応することはできないでしょう？それと同じ話です
遅延評価なのでどんなに巨大なファイルを一気に読む様なコードに見えても、実際には表示するぶんずつしか読み込まれませんが。。。
何の話かよくわからんが、遅延評価と遅延読み込みは違う。
遅延読み込みと非同期読み込みも違う。
何か勘違いしてないか？
同じライブラリ化されるべきなら、より簡単にライブラリが作れた方が良いんじゃないか？と考えます。
また、ライブラリやクラスを使う際にはオブジェクト指向も関数型も差はないでしょうが、ライブラリを作る側だとクラスは使う時より楽じゃないと感じます。
普通の言語のreadLine的なのが遅延読み込みですよね？
Haskellは表示しない値は無いのと同じ、表示して再度使う予定もないなら用済み。
(その証拠に、読み込んで複雑な処理させるけど表示しないコードは、何が書かれていようとそもそも何もしない。無限リストを表示させるとかも良い例)
一見全部読む混んで全部表示するコード書いても、表示に必要な分だけ読み込んで、表示が終わったら破棄されていきます。
普通の言語の遅延読み込みに相当するものも、遅延評価が勝手に似た様な働きをしてくれます。
違うのは、行毎とは限らない事くらいです。
失念していました。であれば別の例を考えないといけないですね^^;
要は「部分読み込み→処理→出力」というスキームで進めなければならないシチュエーションでは
今のコードの枠組みは変えざるを得ないということが言いたかっただけです
ところでHaskellのreadFileというのは賢そいのですね
たとえば一番最後の行から逆順に出力するような場合
getArgs >>= \(file:_) -> readFile file >>= putStrLn . unlines . reverse . lines
でもファイル全体を読み込まずに済ませられる（つまり読み込むポジションのみ覚えていて適宜移動して読み込める）程度に賢いのですか？
そこは痛い所ですね。。。
賢くないはずです。
Haskell.orgも、その弱点を知ってるので良い加減克服されててもおかしくないですが。。。
少なくとも不思議の国のアリスやこころのテキストをwebからコピペして読ませてますが、reverseしないのと体感速度に差が無いですね。
(一文字ずつreverseさせれば流石に体感速度下がりましたが、行毎は感じませんでした)
今時はメモリもGBが当たり前なので余程じゃないと体感出来ないのかも。。。
まあ、すでに(ターミナル次第ですが)Python/Rubyより遅かったりしますけどね。。。
(全面ByteString使用する様に書き換えれば同程度には高速化するでしょうが)
書き捨てコード同士では負けますが、ライブラリ化したらPython/Rubyの書き捨てコードより短くなります。
読み込んだファイルに上書きできる？
いやあ、同名のファイルに直で保存しようとするとロックされるの失念してた。
そう言えばtempファイルがどうとかどっかで読んだなぁとかRWH読んでたけど見つけられなくて、
でも一旦別名で書き込めばtempファイルにこだわる必要無いじゃんって事で元のファイル名の頭にoutって付けて一旦保存して、
それを開き、内容をそのまま元のファイルに書き込んだった。
これこそ発想の転換w
まともなシステムなんて書けないと思わない？
書けたけど？
正攻法じゃなかったのはおいらの知識不足が問題であって、言語の問題じゃ無いよ？
それに発想の転換と言うか、知恵と工夫で解決するのは、どんな言語使ってても必要な事。
だからっておいらがプログラマに向いてるわけじゃ無いのは理解してるが。
ちょっとググればやり方わかるのにそれすら調べもせずに幼稚で姑息な思いつきをしたり顔で「発想の転換」とか草
結局、readFileのブラックボックス化をよしとしてるからそういうことになるじゃないの
自慢の車輪の再発明のしやすさとやらは何処へ？
車輪の再発明しやすいのも、その一環。
その宣伝のためにも敢えてあまりググらない。
ググって見つからないぐらいで作りたいものを作れなくなる様な言語じゃ困る。
おいらは実際頭悪いし。
オブジェクト指向をやりやすくするための
言語仕様を備えてるだけなんだから
何も？ 何もいらないのか？ それでほんとにオブジェクト指向？ なんか怪しいな
これがオブジェクト指向の本質
モジュール公開側も公開したいものだけ指定出来るし、importする側も、さらに細かくこの関数だけ読み込むとか、この関数以外を読み込むとか、細かく指定出来る。
オブジェクト指向もメソッドチェーンで宣言的プログラミングを目指したけど、何年経っても手続き的な側面を脱却出来ない時点で失敗作。
一緒にすんな。
モナドで手続き書くとマジ終わってるレベルで読みにくくて冗長
かと言ってHaskellでも性能出そうと思うと手続きを書かざるを得ない
つまりウンコ言語
実際には遅くて冗長
それがウンコ言語Haskell
ネットに踊らされてないで自分でやってみなさい
やってみた？
カプセル化が必要だとするならそれは設計が間違っているというのがhaskellの議論で明らかになったわけです
手続き型つまり構造化プログラミング
オブジェクト指向は構造化プログラミングの
延長線上にあるものだから手続き型は友達です
仲良くしましょう
つまり手続き型は数学的モデルのあるちゃんとした方法なんです
それを駄目だと思うのは慣れすぎてマンネリ化してるからなんです
c言語からやり直そう
linuxはc言語で書かれていますが
完全にオブジェクト指向です
前どこかのスレにコマンド引数の偶数番目と奇数番目を分けてリストに入れて、後から1、2番目を一つの組み。3、4番目を2つ目の組み。。。
みたいにして表示するコードをHaskellとPythonとRubyで書いたが、皮肉にもグローバル変数があっても良いはずのHaskellだけがグローバル変数作らないで済んで、
PythonとRubyはグローバル変数作らないとダメだった。
Pythonは書き様によってはグローバル変数無くせそうだったし、Rubyのsliceヒントに別の書き方のが全言語でグローバル変数要らなくなったし、シンプルになったけど。
doの書き方は手続き型言語でも宣言的と呼ばれる関数(メソッド)呼び出しの羅列の再現。
ループとかの手続き丸出しなのの再現はあくまで再帰。
だが再現はループの代わりにもなるが、あくまで値を返す関数。
メソッドチェーンと同じで返ってくる値の型を意識する。
o再帰はループの
http://qiita.com/tutinoco/items/6952b01e5fc38914ec4e
> PythonとRubyはグローバル変数作らないとダメだった。
これ↓のどこでグローバル変数を作る必要があると？
print(list(zip(*[iter(sys.argv[1:])]*2)))
p ARGV[0...ARGV.size/2*2].each_slice(2).to_a
お、そう書けるのね。
おいらPythonやRubyは(Haskellもそこまでじゃないけど)初心者程度だから。
そもそも重要なのは手続き型言語はグローバル変数がバグの温床になるのに、Python、Rubyじゃいとも簡単に作れちゃうって事ね。
Haskellみたいなグローバル変数がバグの温床になるわけじゃない言語でさえもパッケージ単位でカプセル化考慮されてるのに、初心者程グローバル変数宣言しちゃうし、出来ちゃうのは問題だよ。
って、よく見たらsliceの方のアルゴリズムだし。。。
上でも、そっちはグローバル変数使わなかったって書いてるだろ。
コマンド引数の配列なりリストなりを
args!!i -- Haskell の場合
args[i] #Ruby、Pythonの場合
このインデックスのiを奇数か偶数か判定して、それぞれのリスト(配列)を作ってzipするアルゴリズムではグローバル変数使った。
おいらの力量のせいだったのかもしれんが、そう言う書き方に自然となったのが問題って話。
オイラー と被せてるの？
ふつうに書けばシンプルに書けるものをなんでわざわざ複雑にせなあかんのかがわからん
p ARGV[0...ARGV.size/2*2].select.with_index{ |_,i| i.even? }.zip(ARGV.select.with_index{ |_,i| i.odd? })
処理
})();
JavaScript でも、グローバルスコープにしないため、ファイル全体を無名関数で囲む。
Rubyでも、囲めばよい
結局、囲むという事は、クラスと同じ。
関数・クロージャ・ブロック・ラムダ式など、どういう表現をしようが、
スコープがあるという事は、クラスと同じ
その発想は無かった。
>>766
実はHaskellも最初リスト内包表記でグローバル変数作ってたんだけどね。
結局判定する関数のevenとoddしか違いが無かったからmakeList関数作って纏めただけなんだが、同じリスト内包表記あるPythonで同じ様にしようとしたらi % 2 == 0とか書かないといけなかったのね。
んで、まあ良いや。0か1かで奇数偶数分けられるから関数作っちゃえって思ったらエラー出た。
定数じゃないとダメっぽくて諦めたけど、リスト内包表記に拘らなければ関数に出来たと思う。
(もしくは将来的にリスト内包表記のif式に外部から変数渡せる様になったら作れる)
処理全体を関数にしちゃうってのは確かにグローバル変数を無くす有効な手段だが、初心者ほどそんな事しない。
ファイル名とファイルの内容をzipするコード書いた後の実験的なコードだったんで、そう言う発想になった。
後でsliceなコードのが単純だし、グローバル変数使わないって気付いたけど。
ここではどうしても使わざるを得ない場面が出て来たってのを言いたかっただけ。
古き良きパールのようじゃ
＞ここではどうしても使わざるを得ない場面が出て来たってのを言いたかっただけ。
それが間違いなんだって言ってんだろ
どうしようもないアホだな
その規模じゃグローバル変数でも問題ないわ
間違いというか効率悪い方の例をわざわざあげてる意味わかってる？
この例に限らず、グローバル変数がバグの温床になるって分かってるのに、
どうしてもグローバル変数使わないと書けない場面があるから黙認されてるっていうのが、
もうオブジェクト指向はグローバル変数に対して根本的な解決策を持たない不完全なパラダイムだって証左だよ。
Haskellだってどーしよーもないコード書くやついくらでもいるわ
お前はそのどーしよーもないコードの書き方すら知らない存外の低脳ってだけの話
置換可能を実現できるということは、サブクラスはスーパークラスそのものってことになるような気がして
LSPの概念は、どう便利なのでしょうか
グローバルスコープのシングルトンオブジェクトでいい
必要ならね
>サブクラスがスーパークラスそのもの
受けとる側の視点ではそれでいいんだよ
違いを意識する／したいのは渡す側
なるほど、なんとなく解った気がします
あとは、どういうシュチュエーションで便利かモデリングの数をこなして覚えたいと思います
まあ、低次元なことを言うと、
「いろいろサブクラスを作ったけど、受ける側の関数は全く変更せずに済んだ！わーい！」
てのがメリットの一例。
というBlogをみて「ああそれだよそれ、そういうのでいいんだよ」（孤独のグルメ風表現）になった
なのに、変な原理原則マンに限ってそこがスッポリ抜けてたりするからな
そもそもOOは原理といえるほど理屈がしっかりしてないだろ
複数のオブジェクトにまたがるメソッドをどこに実装しようかっていう初歩のレベルで
すっきりしないというのに
むろんマルチメソッドという考え方もあるけど、ほとんどのOOPには実装されてないしな
だから複数の色んなことを同時に考慮して、うまい具合にしなきゃならないっつーのに
原理原則とかでは無いわ
我々は空間と時間を両方扱っているわけで、片方だけに着目すりゃよいってものでもないわ
潜在的に、そうとうオツムが弱いよな
世の中の理屈とかけ離れすぎているというか、単純化しすぎ
> 複数のオブジェクトにまたがるメソッドをどこに実装しようかっていう初歩のレベルで
オブジェクト指向は、現実世界で実現しているオブジェクトに
ソフトウェアの設計を合わせようとするものだが、
現実世界のオブジェクトでは、
「複数のオブジェクトにまたがるメソッド」は
どこに実装されているんですか？
複数のオブジェクトにまたがるメソッドというものが
そもそも不自然なメソッドですよね？
＞現実世界のオブジェクトでは、
＞「複数のオブジェクトにまたがるメソッド」は
＞どこに実装されているんですか？
物理法則に実装されてる
もうこの時点でアホっぽいってわかるでしょ
ありえないぐらいで、釣りじゃないかと疑うぐらい
アホらしいけどまず基本的なことからいうと
コンピュータは日本語で「計算機」ともいうのでそっちの方向から攻めると
足し算は現実世界のどこに実装されているんですか？っていうぐらいアホなイチャモン
物や物体的なことにこだわって、概念的なことであるとか関係性といったものを
認めない姿勢は技術者ではない以前に、人間的ですらない
物理法則っていうのは、
例えばすべての物体は引力があるとか？
あ、これ複数のオブジェクトにまたがるんじゃなくて
個々のオブジェクトに引力があるのか
例えば、熱を加えると発火するとか？
あ、これもその物体が変化するだけか
複数のオブジェクトにまたがるメソッドってなんですかね？
数値を入力してボタンを押すと足し算を行うのは
計算機というオブジェクトが持ってる機能ですよね？
それとも電気信号レベルの話をすれば良いのですか？
そろばんでも足し算ができますが、
もしかしてこの２つを同一のものとみなしてるのですか？
そろばんは電気信号じゃなくて物体の位置で表現するって
だけですからね。
数学上での足し算という「概念」の話だ
1に2を足すと3になるっていう概念上の関係性の話だ
別に現実世界に実装があるわけじゃないが、1に2を足すと3になるし、有用なんだよ
ついでに言うと、1とか2とかいう数字自体からして現実世界に実装が存在しているわけではない
1とか2はあくまで数学上の概念だ
もう本当にあほだなぁと思う、あきれて言葉も出ない
こうなったらもうエンジニアとして終わりなんだと思うし
人としても鬱病になる末路なんだろうか、知ったこっちゃないが
>計算機というオブジェクトが持ってる機能ですよね？
>それとも電気信号レベルの話をすれば良いのですか？
この発言もかなり面白くて、この言葉通りにプログラムをすれば
すべてのメソッドはコンピュータインスタンスに紐づくことになる
computer.add(1,2); computer.func(a,b,c);ってところか？
OOだなんだいったって、実際に処理をするのは「コンピュータ」
に他ならないんだから至極当然な意見だわなwww
たしかに現実世界を模してるわ
いわゆるGODクラス、staticおじさんと同じだ
つまりもう、自分がどういう立場をとっていて何を言っているのかすら
よくわかっていない状態ということだな
病的
> 1に2を足すと3になるっていう概念上の関係性の話だ
1という値の数値オブジェクトに
2という数値オブジェクトを引数に
数値オブジェクトの加算メソッドを呼び出すと
3という数値オブジェクトになるって話？
引力を物体間の相互作用じゃなくてオブジェクト単体で定義される性質と思ってんの？
そりゃそうでしょｗ
地球の引力を計算するには、月の存在が必要だ！
などといったら笑われるよｗ
俺がかなり煽った文体で書きこんでるのにもかかわらず
お前の援軍は誰も現れないでしょ、これが現実
頭悪すぎて他人の言っていることも自分の言っていることすら理解できないという
もうどうしようもない残念さで、誰も味方がいない
この手の人は本当にもうどうしようもなくて
かわいそうだからと周りの人が説得を試みても全くの無駄というか
普通の人が当たり前にできる思考が、どうにも理解できないらしく
必ず自分にわかる範囲で自分の領域に持ち込んで考えようとするんだが
その行為自体が間違っているってことが何故か分からないらしい
袋小路でとにかく打つ手なし
なぜ引力という力が働くのかということは
本当のところは誰にもわからない
つまりは表面上そう見えるからそういう力があるのだろうという程度のものであり
根本的な原理は未解明なので、誰が引力を実行しているかとか考えるだけバカ
あと本質的に>>803が言いたいのは、オブジェクトが一つしかなければ
引力など定義しても無意味だし、引力の効能は性質となって表れないから
定義もされないっていう意味だろう
まぁ一般的な考え方だな
世の中は極めて相対的だしな
お金の価値ですらそうだしな
> 引力など定義しても無意味だし、
オブジェクトが一つしかない状態に限っていえば
無意味なんだと言われましても・・・
数字だって一つしかなければ
足し算は無意味ですよ？
マルチメソッドはオブジェクトが一つしかなければ無意味だ！
って言いたいんだな。
Googleのページランクの仕組みは非常に現代的だったわな
たくさんあちこちからリンクが張られているページは有用性が高いのだろう
そして有用性の高いページからリンクが張られているページもまた有用性が
高いのだろうっていう
そんで、かつてのYAHOO方式は負けたわけだ
でも別に珍しいことではなくて、論文とかでもたくさん引用されている論文は
価値が高いってことになってるし、まぁ基本といいますか
たくさん友達のいる人は有能なんだろうってのも大体あってるし
取引先の多い企業、特に大企業との取引がある会社は信用が有るってのも
一般的な価値基準だわなぁ
資本主義に関しても、お金のような流動性のあるものに着目するっていうのが
現代的であるし、お金をどんどん回して経済を発展させようってのも
政治家の大好きな謳い文句だわな
大体世の中そういう構図になっているから、反対へ行く人や軽んじる人
もしくは君みたいに理解できない人は北朝鮮になる
ただ何事もバランスは大事なんだけど、そうはいってもどっちに軸足を置いておくか
ってのはあるわな
簡単な方の考え方は誰にでもできるし、意識する必要もないし、学ぶべき部分もないから
あまり重要視されないんだけど、本音と建て前みたいな話にもなってくるわ
ただ、とっちが建前になってどっちが本音になるかは相手とシチュエーションによるという
つまり俺もOOPを、「使う」わけだが、いつも「必要悪」という考えはある
絶えず反対のことを考えながら吟味してOOする
そのぐらいでちょうど良いバランス
ただ、本音と建前の世界なのでコンセンサスが取りにくい
hpXZLyYVみたいなのが入ってくると破たんする
いちいち面倒くさいんでLinusがC++を追い出す気持ちもわかる
OOPをおもちゃにする奴はマジで糞
では差があるわな
しかも現実世界の引力のメカニズムは解明されていない
どういう理屈で力が働くのかとか、だれにも分からん
>例えばすべての物体は引力があるとか？
>あ、これ複数のオブジェクトにまたがるんじゃなくて
>個々のオブジェクトに引力があるのか
「個々のオブジェクトに引力がある」って何ですか？
すべての人には年齢がある、と同じノリですか？
あぁごめんな
ただあの人のインタビューとか読めばわかるけど
逆張り逆張り言ってる
あの人自身もRubyの筋が良いとかメインストリーム的な思想であるとは
考えてないんだよ
ただ、自分の人生の中で逆張りした場合にうまくいくことが多かったので
逆張りし続けているんだとか
だからRuby3.0でも逆張りの一種として
静的型の機能は導入しない方向を検討しているんだろうな
ただそう何度も逆張りが上手くいくとは思わないし
逆張りはしょせん逆張りだろ？あだ花というかなんというか
そういうこともあって結局Rubyはプチブームで終わった現状があるわけだし
変なことして注目を集めることはあってもそれは一過性だよ、芸人じゃあるまいし
しかも逆張りしたときに自分にとって都合がよいことが多かったってだけで
使い手のことは別に考慮されてないんだよなー
いわんや物理法則をや
個別のふるまいレベルで弄るもんじゃないから、そもそも例えですら出てくるようなもんじゃない。
相互作用は全部神クラスに書けばいいね
オブジェクト指向w
割とそのアプローチで合ってる
キャットドアの出番だ
○ 人間が自然に認識している現実のもの（オブジェクト）を使って
モデル化するから理解しやすいものが出来上がる。
これはあくまでモデル上でのすっきりした切り分けの話であって、こういうオブジェクト化に
「戦場で仲間に"たたかえ"ってなんだよw」とか「順番に交互に殴るのかよ」とか言ってもまったく無意味だというのに
キャットドアじじいはなんかそういうことから理解できてない知恵遅れだからね。
よく勘違いしてるやつが出てくる。
オブジェクト指向で現実世界を実現しようとするやつだ。
シミュレーションでもやらない限りそんなものは意味がない。
その逆、実現したいものを現実世界をヒントに
オブジェクト指向でモデル化するんだよ。
そうすることで現実世界という共通認識を利用して
実現したいものをわかりやすく表現することができる。
具体例かいてくれ
ノブに付属するラッチ（固定具）の状態（ノブの回転に応じて引っ込む）
をオブジェクト指向でモデリングしてみてよ
オートクローザーやドアストッパーが設置されることも加味しつつ
「でも現実を見てみなよ」って。
モデリング終わりがなくなってしまうわけだ。
そういうバカには5000兆円の見積書でも送りつけてやればいい。
理解できない文系のためのモデリング
それがオブジェクト指向
例えば>>826のようの
現実世界にある何か（ドア）をオブジェクト指向で表現してくれ
なんていう考え方がアホなんだよ。
ソフトウェアでドアを作ることがあるとしたら、
ゲームとかだろうけど、ゲームとして必要なドアを
ソフトウェアで実現するならば、オブジェクト指向が便利ですね
なぜなら、ゲーム世界のドアをオブジェクトとして実装することができるので
現実世界で我々がよく知ってるドアを参考にできるからです。
ってな具合
あれがこうしたらこれがこうなる、みたいに。
因果応報。
オブジェクト指向として認識するのだろうか？
同じ人間であっても自分の母親と他人の母親は別だって
理解できるし、人間と動物の区別もついているだろう。
そして、犬はワンワン、猫はニャーニャーって鳴くことを
理解するだろう。
人間の認識とはかくもオブジェクト指向であるものだろうか
ゲームのドアなんぞ開く閉じるの状態と、開く条件(鍵とか)ぐらいだろ。
んで、自動ドア制御とかだとセンサーから信号が来た時だけ開いて、数秒したら閉じれば良い。
人が通った時の赤外線センサーか、人が挟まった時の圧力センサーかはプログラムは知る必要無い。
これらに共通のドアクラスなんぞ作って何か共通点があるの？
開く閉じるの状態があるのは開口部のほうやけんど？
それは現実世界のドアの話だろう？
ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。
3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ
だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。
このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ
それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない！
開口部の状態だって教わったのに意地はっちゃってw
ドアオブジェクトなんてそもそも必要ないんや
こーゆーのをモデリングゆーんやわかったかボケカス
開口部って何って聞かれてるんだから
質問に答えなよｗ
ドアが開いているとか意味がわからない
開口部があってそこがドアというもので塞がれているかどうかだ。
だから「開口部がドアで塞がれていない」と言うべきだ
とか思うのだろうか？
アスペには常人の共通認識は通用しない
オブジェクト指向には不向きな人間だなｗ
なあ？お前の考えた最強の抽象化ってぜんぜん抽象化じゃなかっただろ？
恥ずかしいけどこれで一つ賢くなったんだ
次はもう少し長くドヤれるようになるじゃないかw
誰が最強の抽象化とか言ったんだ？
お前はだれと戦ってるんだ？
俺の言ってることに何一つ反論して無くて
俺のほうが正しかったと主張してるだけ
妄想も大概にしろよ。
え？お前なんか意味のある事言ってたの？
じゃあもう一度言ってみ？聞いてやるからw
ドアには開いている・閉じているという
状態があると認識することだよ。
本当は開口部だーとか細かいことに
こだわるのは抽象化とは逆の考え
はい論破♪
もう一度言えばいいの？
それは現実世界のドアの話だろう？
ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。
3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ
だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。
このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ
それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない！
開口部なんて細かい枝葉は誰も考えてないって所が重要だね。
まあ密室殺人で警察に聞かれた時に
この部屋の開口部はドアで塞がれていましたなんて
言わないのと同じこと。
ドアって開口部を制御するための具体的実装の一例にすぎんのだかw
抽象とは真逆の概念ですよ？オブジェクトハカセw
だから、お前、オブジェクト指向を現実世界をシミュレートするために使うなって
それが間違ったオブジェクト指向の解釈なんだよ。
ドアを抽象化して考えろ。細かい枝葉は取り除け
抽象化
https://ja.wikipedia.org/wiki/%E6%8A%BD%E8%B1%A1%E5%8C%96
> 抽象化（ちゅうしょうか、英: Abstraction、独: Abstraktion）とは、
> 思考における手法のひとつで、対象から注目すべき要素を重点的に抜き出して他は無視する方法である。
https://goo.gl/soXPyb
> ▼誤解されがちな、「抽象化」という言葉
> 結構な人々が抽象化を「曖昧にすること」とか思っていて、抽象絵画は「なんか曖昧な絵」みたく思っているので始末に負えない。
> まず「抽象（abstraction）」っていうのは、「物事の共通部分を抽出して把握すること」だ。
> 「対象物の特徴をつかみ、枝葉を切り捨てた本質をとらえる」思考力を抽象化思考力と呼びます。
> コンサルタントが「抽象度をあげろ」というときには、実は「抽象的にしろ」とは言っていません。「概念化して語れ」と言っているのです。
> 抽象化とは、一般化（上位の概念に包括）することです。例えば亀→両生類→動物→生物という具合に、上位の分類の言葉に置き換えていくことです。
お前が抽象化できんかったからドアが残ったって言いたいんだろ？
知ってるってw
ハカセそれ抽象化ちゃうw細分化やw
ドアが残ったってなんだ？
またお前が言い出した言葉を
俺が言ったことにしたいのか？
お前が言い出した言葉に対して、「知ってるってｗ」って
なに自分で自分にレスしてるんだ？
妄想も大概にしろ
これも意味がわからん。
こいつバカなのか？
端的に言ってお前支離滅裂だぞ
少なくとも今夜俺は
お前に抽象化のなんたるかを垣間見せてやったのだから
明日からもう少しまじめに勉強しろよ
まあ今夜は恥ずかしくて顔から火がでてるだろうから
多少の発狂は仕方ないけどなw
え？ どれ？
具体的実装の話をすること？
それは抽象化の逆だけど？
> 端的に言ってお前支離滅裂だぞ
ID:ZkAshefq が支離滅裂
> 少なくとも今夜俺は
> お前に抽象化のなんたるかを垣間見せてやったのだから
ID:ZkAshefq に俺が見せてやった
> 明日からもう少しまじめに勉強しろよ
ID:ZkAshefq が勉強しろ
> まあ今夜は恥ずかしくて顔から火がでてるだろうから
ID:ZkAshefq が恥ずかしくて顔から火が出てる
> 多少の発狂は仕方ないけどなw
ID:ZkAshefq が発狂している。
本当は自分のことなのに、それをごかます
幼稚なやつがやる手段だなぁ
はたまた恥ずかしすぎてトボケてるだけなのか？
いまのところ前者が優勢ですけどねw
俺が言いたいのはこれ（三度目のコピペ。二度目はID:ZkAshefq にもう一度書けと言われて書いたのに無視されたｗ）
それは現実世界のドアの話だろう？
ゲームの世界のドアは、現実世界を参考にできるが
ゲーム特有のドアという仕様を作る。
3Dゲームであれば、ドアには開く閉じるという状態は必要ないだろう
なぜなら物体をすり抜けられないという仕様と
蝶番を支点にドアを動かせるという仕様があればよいからだ
だけど2D RPGみたいなドアであれば、ドアの状態というものがあってもよい
開いているドアであれば、その上を移動することができ、
取っじているドアであれば、その上に移動することはできない。
このようにオブジェクト指向は現実世界の物シミュレートためのものじゃなくて
作りたい仕様を、みんなが持っている現実世界の共通認識を使って
わかりやすくする表現するための技術なんだよ
それにしても現実世界のドアについての人間の認識ってのも面白いよな。
ドアからすれば、物理的にはどういう位置にあるかでしかないのに、
人間は「開いている」「閉まっている」というドアの状態として認識しているわけだ
この認識、利用しない手はない！
オブジェクト指向は抽象化して考えるためのものでもあって
どういう具体的実装であるかは置いといて、
「ドアが開いてる・開いてる」という状態で表現できるわけよ
学習できない奴の特徴まんまw
ごめん。もうお前にレスはしてないんだｗ
ドアとどう関係があるんですか？
オブジェクト志向には色々な側面があるんだし、その二つは別に対立せん気がするが
するものじゃないってことを言ってるだけだよ。
オブジェクト指向で現実世界のあれができないこれができないっていうのは
的外れだってこと
ま、そもそもオブジェクト指向で「ドア」を実装するにはどうすればいいだ？って
ドアというオブジェクトを持ってきてる時点で、
オブジェクト指向は人間の認識と相性が良いんだってわかるんだけどねｗ
すまんやっぱり>>867はなしで
>>868
主張のまとまりがいまいち良くないけど、好意的に解釈する限り言ってることは間違ってないと思うよ
ID:ZkAshefqを抽出したらびっくりするほどなんにも言ってなかった。
「ばーかばーかおれの勝ちィ！」しか書いてなくね？
なんでスレ進んでんの？
Simula 67 ではオブジェクト、 クラス、サブクラス、継承、動的束縛（仮想関数）、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
Simula はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように Simula はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、Simula 当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイが Simula の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では Simula が世界最初のオブジェクト指向言語であり、
Simula は「オブジェクト指向として再認識が可能な最古の言語」ということができる。
> ID:ZkAshefqを抽出したらびっくりするほどなんにも言ってなかった。
だろ？ｗ
生年月日： 1950年2月20日 (67歳)
https://ja.wikipedia.org/wiki/Simula
志村(67) ではオブジェクト、 クラス、サブクラス、継承、動的束縛（仮想関数）、
コルーチン、 ディスクリートイベントシミュレーション、ガベージコレクションの機能をもち、
オブジェクト指向プログラミングの基本概念はすべてここで発案されているといえる。
志村 はプログラミングパラダイムとして最初のオブジェクト指向言語であると考えられる。
その名前が示すように 志村 はシミュレーションを行うために設計され、
その必要性から今日のオブジェクト指向言語で使われる多くの機能のためのフレームワークを提供した。
なお、志村 当時「オブジェクト指向」という言葉はまだない。
この用語は 荒井・注 が 志村 の概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味では 志村 が世界最初のオブジェクト指向言語であり、
志村 は「オブジェクト指向として再認識が可能な最古の言語」ということができる。
シミュレーションをするための言語を作ると
オブジェクト指向になるってのは
やはりオブジェクト指向は現実世界の人間の認識と
相性がいいってことなんだろうね。
毎回思ってることだけど、アランケイのオブジェクト指向のポイントは
むしろメッセージセンドでオブジェクトに命令を送るという方式の発案なので
(さらにいうと、インスタンスを作るのにクラスそのものに「複製を作れ」と命令して作らせる
言語システム(予約語)から離れてクラスが自律的に動く思想の方)
Simulaはかなり毛色の違うオブジェクト指向だし
言ってしまうとこれがカンチガイされたままオブジェクト指向だと思われた結果
C++というそびえ立つクソの山が産まれて業界を何十年も混乱に陥れた元凶だから
Simula持ってきて「オブジェクト指向とは〜」ってやった瞬間
お話にならないぐらいオブジェクト指向を理解していないバカが来た。
で話が終わるんだけど。
昔、15年ぐらい前に学生だった時に先生がこれからはエージェント指向だって言ってたんだが
その説明きいて、俺はそれってオブジェクト指向＋メタデータじゃね？程度に思ってた。
オブジェクトが自律的に仕事をする。みたいな事を言ってたんだが、
それを実現するにはどんな要望であっても、それを実現するためのモジュールが存在し
その要望を完璧に判断してモジュールを選択できるAIでも搭載してなきゃできないような
ものだったのでエージェント指向でもなんでもないし実現は不可能と思っていたが。
まあエージェント指向とやらにはさっさと見切りをつけたので
俺が間違って理解してるんだと思うけどねｗ
でも事実としてオブジェクト指向を置き換えるものにはならなかったようだね。
シミュレーションをするために言語を作ったけど、
本来の用途としてはあまり使われず、（よくよく考えてみれば
シミュレーションなんてそんなにするか？ってことなんだろう）
副産物として生まれてオブジェクト指向の技術の基礎とでも
呼べるようなものが独立しそれが洗練されてオブジェクト指向言語
として生まれ変わったってことなんかね。
UMLも似たようなもんだよね。元々はオブジェクト指向分析や設計の方法を
色んな人が考えていたけど、それぞれを比較検討する時、それぞれで図の書き方が
異なっていたので、分析や設計方法が色々あるのはわかる。だけどせめて図の書き方
ぐらいは統一しようじゃないかって生まれたもの。
でもオブジェクト指向の分析や設計方法はみんな飽きてしまったのか話題にならなくなり
UMLという図の書き方だけが広まったと。
「もともとはこうだったのに変質してしまった。クソが！」と思う人がいるのだなあ。
と感じました、まる
ストラウストラップの“オブジェクト指向”はSimulaスタイルのクラスを抽象データ型（ADT）とみなして使うアイデア
抽象データ型の提唱者のリスコフ、Simulaの設計者たち（ダールとニガート）はもちろん、メイヤーも同様のアイデア同時期に提示している
抽象データ型というのは簡単にいうと「ユーザー定義型」のことで言語組み込みの具象データ型に対してこう呼ばれる
OOPの古典的三点セット「カプセル化・継承・ポリモーフィズム」に象徴されていて
カプセル化は抽象データ型の要件、継承とポリモーフィズムはクラスを使う際のオマケの機能を表わしている
ただ、早々にクックらにより継承を使ってサブタイプを表現することには問題が生じうることが指摘されていて
また動的型のダックタイピングのような自由度を得るためにインターフェース（プロトコルなど別の呼び名も）が考案され
現在はそれが汎用されている
一方、ケイの“オブジェクト指向”はSimulaのオブジェクトにメッセージの受け手を担当させるアイデア
メッセージングはあくまで方便で狙いはその先の設計・実装・運用等、あらゆる局面での「遅延結合の徹底」
遅延結合というと実装のみに固執してしまう人がいるから「決定の遅延」といった方がよいかも
Smalltalk-72はこのアイデアを元に、クラスはJSのクラスのような関数っぽい性質で実現された
このときはメソッドも関数というよりLISP等のリーダーマクロのようなメッセージとなるトークンストリームを順次処理する手順が記述された
次の世代のSmalltalk-76からはSimulaスタイルのクラスが取り込まれ、メソッドも単なる関数になり
前者のオブジェクト指向もそれなりに意識されるようになったので同じSmalltalkでも
Smalltalk-72は純粋なメッセージングのOOPL、Smalltalk-76以降はADPとメッセージングのキメラと考えた方がよいので
もしケイのメッセージングのOOPの考え方に興味があるならPharoやSqueakのような最新のSmalltalkではなく
エミュレーター等で提供されているSmalltalk-72をやるほうがいい
https://ubiteku.oinker.me/2016/05/09/what-is-oo-all-about/#comment-65
ちなみにアクター理論はこのアイデアを実行時の並行性に応用し定式化を試みたもの
つまりデータと処理の抽象化を徹底するということだ
型によってデータ長も処理の方法も変わるのが煩雑さの根源だ
離れたユニットに「この処理をお願いします」と頼むことになって
シーケンシャルな処理待ちしていたらコンピュータが止まっちゃうし
周りの環境も実行時に刻々と変化してゆくから
オブジェクトにはある種の他と切り離された自律性がいるよね。なのに
なぜか21世紀のインターネット時代に「いいや！カッチリ制御して
他に影響が出ないように書ければこの『世界が勝手に変化するバグ』は排除できるはずだ！」
という謎のカルトが一部で流行り出してるのがどうにもよくわからないw
C++のテンプレートは本来ジェネリック程度の機能で良かったのに
ちょっと道を外したら、意外と高度なことができることが分かっちゃって
本来の目的から大きくはずれてコンパイル時コードジェネレータみたいな
もんになっちゃったでしょ？
protcolとdelegateこそが至高
Myfunc.hs
1:module Myfunc where
2:
3:import Data.List
4:import Text.Printf
5:
6:consnum::(Int,String) -> String
7:consnum (i,xs) = printf "%4d:%s" i xs
8:
9:fline f = unlines.f.lines
10:
11:fnumbering f = fline ((map consnum).(zip [1..]).f)
12:
13:numbering = fnumbering id
14:
15:revnumbering = fnumbering reverse
16:
17:allrevnumbering = fnumbering (reverse.map reverse)
18:
19:searchword w = fline (filter (isInfixOf w))
20:
21:putfc (f,c) = printf "%s\n%s" f c
22:
23:mulfileput fs f = mapM readFile fs >>=
24: return.(zip fs).map f >>=
25: mapM_ putfc
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \fs -> mulfileput fs numbering
6:
revnumber.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \fs -> mulfileput fs revnumbering
6:
searchword.hs
1:import System.Environment
2:import Myfunc
3:
4:main = getArgs >>=
5: \(w:fs) -> mulfileput fs ((searchword w).numbering)
6:
だってオブジェクト指向言語使ってた時って、ここまで似たようなコード書かなくて良いくらいライブラリ化出来たことなかったんだもん。
嫌ならもっと低レベルの関数もあるよ？
LISPのSETFと同じくらいガッカリ感ある
オブジェクト指向言語的に考えたら
それはインタフェース自体を増やすと言ってるように聞こえるけど？
オブジェクト生成元クラスのコンストラクタ関数の結果を得るだけなら、
Foo obj = Foo();
とすれば new なくても書けるのに、なぜ new を書く必要があるの?
newがなければ何をすれば良いのかわからない
コンパイラの気持ちになって考えろよ
Base *base_pointer = new Base();
Base base();
bird tweety = bird("Tweety", 0.13);
tweety->eat("corn");
tweety->fly();
tweety->max_altitude = 180.0;
fish b = fish("Bubbles", 1.13);
b->eat("fish food");
b->swim();
animal w = fish("Willy", 4000.0);
w->eat("tourists");
w->swim();
Inheritance | Object-Oriented Programming | Beginner’s Tutorial - Pike Programming Language
https://pike.lysator.liu.se/docs/tut/oop/inheritance.md
コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
人にわかりやすいようにしてあるだけ
なにがコンパイラの気持ちだアホ
(new Foo)(p1,p2,p3) ととらえるか、new (Foo(p1,p2,p3)) と捉えるかの感覚の違いじゃない？
前者なら宣言的に「新しくFooのインスタンスを作って（初期化パラメーター渡して）るんだな」感が出てnewはあったほうがいいし、
後者なら「新しいFooのインスタンスを作る関数のFoo()を呼んでるのにnewなんて余計やろ？」ってなる
従ってコンストラクタとしてFooを定義する言語や、クラスがそもそも関数的な存在の言語ならnewは蛇足
コンパイラとしては無いと困るもんでもない
newのあるなしで挙動は変えられるけど
> コンストラクタはクラス名と同じって制約があるんだから、コンパイラの気持ちになったらnewなんて別にあってもなくてもいいでしょ
class Foo { }
function Foo() { }
function Foo() { }
が両立する言語の場合、
a = new Foo(); // Fooクラスのコンストラクタ
b = Foo(); // 関数Fooの呼び出し
を区別する必要があるから、newが必要
それをnew無しにもできるでしょ。クラスと関数で区別つくんだし
リフレクション
newなしだったら、
a = Foo();
b = Foo();
なんですが・・・
this が正しく、インスタンスを指さない
JavaScript だと、prototype 継承が動作しない
インスタンスを作る方法はnewしかないでしょ？
コンパイラはFooがクラスか関数か、何なのか知ってるから
区別できるよねっていう
ただし意味解析をしなければFooが何なのか分からない
newがあれば構文解析だけで何をしようとしているかわかる
Fooが何かのか解析するまでもなく、字面の並びだけで関数呼び出しなのか
インスタンスの生成なのかの区別がつく
いざコンパイラを作るとなったらこの差はでかい
あとなんつーか、そういうこと言い出したら
(int i = 0; i < 100; ++i ) なんていう並びの書き方はfor文の時にしか使わないんだから
「for」って要らなくね？とか、goto ERR;って書くけど、ERRがラベルであることは
コンパイラは知っているんだから「goto」って要らなくね？とか
ちゃんと専門の学問があってセオリーがある
必ずしもセオリー通りにする必要はないが、いちおうセオリーがある
セオリーに従えばコンパイラは
字句解析→構文解析→意味解析、というステップを踏んで
プログラムを解析することになっている
ここで、Fooがクラスであるか関数であるかによって
インスタンス生成か関数呼び出しか、切り替えるという文法にしてしまうと
意味解析をしなければ構文解析ができない、という逆流現象が発生してしまう
また、コンパイラ生成器にBNFか何かを食わして自動で構文解析のコードを生成してもらうと
思っても、意味解析をしなければ構文が判明しない箇所のある文法では都合が悪いじゃろ
ただし、セオリーはセオリーでしかなく、従わないことも多々ある
たとえばC++の字句解析において、これは最長一致であるので
「>>」は右シフトと判断されそうなものであるが
出現場所によっては「>」と「>」の二つに分解される
これは字句解析がその後の工程であるはずの構文解析を先回りして少しだけ
してしまっている状態
> コンパイラはFooがクラスか関数か、何なのか知ってるから
> 区別できるよねっていう
知らないぞ？っていうかJavaScriptにおいて
クラスは関数と全く同じもの。
JavaScriptにclassキーワードが追加されたのは比較的最近。
互換性を保つ上で、classキーワードは関数に変換される。
また
function Klass と書けばクラス
function func と書けば関数
というふうに先頭が大文字か小文字かで区別する
というのはあるがこれは慣習であって言語仕様ではない。
なぜなら元の>>901の質問者のコードはどう見てもJavaだから
>>919あたりで何故か脱線したようだけど、これは全くのノイズであるから関係がない
例えば、武器を装備するという行為は、
オブジェクト自身に機能を持たせるのか、
actorを第一引数とする処理を別に作るのか。
対象を省略できるからオブジェクトに実装したりするけど、コンテキストの依存性などの問題でゲームマスター的なクラスに処理を任せるべきだなと思ったり。
こっちには結果教えてくれればいいだけなので
その「役割の範囲」そのものが当該クラス任せです。
クラスが自分でやっても、武器総合管理クラスに聞いてても
上位は感知しないことで切り離してるので。
soldier.equip(weapon)
誤解を招かないか、
どっちかというと「モノ」じゃなくて仮想的な「生命体」じゃない？
だって動きを持ってるし、誕生して活動して死ぬわけじゃん。
「モノ」なのはコンストラクタやメソッドでやり取りされる「引数」
の方だろ。
「プロパティ」は「生命体の所有物」だと思えばスッキリする。
なのに生命体の方をオブジェクトと言うのはおかしいよ。
クラスはその生命体の「家系」みたいなもんだな。
両親がいる必要がないから単細胞生物の分裂のほうが近いか、
クラスは「遺伝子情報」だな、これでかなりスッキリするじゃないか。
オブジェクトを無理やり現実に当てはめるやつ
生温く見守ろうぜ
新鮮な意見だな。
コードと現実は違うって概念のカテゴリー分けに使われてるだけだと思った。
全部機械的に把握できるんだな？すげえなぁ、さすが
コンピュータの熟練技術者は違うね。
言語化してるんだから抽象的思考は重要に決まってんだろ。
どこら辺が抽象化してるの？
リンゴは一緒に買いに行ってほしいの
悲しいね
自覚が無いのか意固地になっちゃってるのか知らんけど
まったく的外れ。
世の中を表現したいわけじゃないし、
世の中に似せる必要も全くない。
1事実1箇所と考えたら現実に当てはめないとダメだろ
いいえ
いいえ
残念ながら見当外れ
対応しないとしたら正規化できてない
エンティティは実態でオブジェクトはその射影だよ。
何を持って対応とするの？
エンティティとオブジェクトで可逆性は保証されてないけど
オブジェクト指向とはをなんぞやを語るのやめてよマジでww
何が言いたいのかわからんが、プログラミングしたい事象を、そのままオブジェクトに丸ごと落とし込むんじゃ無くて一旦分解して考える。
共通点とか過去の資産使えそうなのはそうする。
ここは他でも使えそうとかあったら分けておく。
再利用出来そうな場所と、そうでない場所を分ける。
人と車って系統的に全然違うからオブジェクト指向の動物クラスみたいなのじゃ全然違うだろ？
でも移動出来るってのは同じだ。
食事と燃料補給は違うが、エネルギーが無いと動かないってのも同じ。
そうやって全然関係無さそうなものの共通点を考えると抽象的なクラスが出来てくる。
現実のオブジェクトと違うけど、より本質に近いオブジェクトになる。
人と車を動くという共通点によって同じ操作をインターフェイスで作るみたいな感じ?
10画面程度の業務システムしか組んだことないから知らんのだけど大規模システムはそんな風にオブジェクト指向で設計するの?
オブジェクト指向入門見て分類学的に設計するものだと思ってた
業務システムじゃエンティティが正義だと思うけど、ゲームや制御じゃ事情や適用方法が違うんだろうね
制御は構造化しかやったことないけど
アラン・ケイのメッセージングのオブジェクト指向がまさにその着想だな
http://worrydream.com/EarlyHistoryOfSmalltalk/
My biology major had focused on both cell metabolism and
larger scale morphogenesis with its notions of simple mechanisms
controlling complex processes
でも残念ながら現在の主流は抽象データ型のオブジェクト指向
クラスやそれに準ずる言語機能をユーザー定義型として扱うストラウストラップらの着想が根底にあり
生命体とのアナロジーはそぐわない
委譲やインターフェースによる多態性のが好まれる。
これはおいらの推論だが、昔はCUIからGUIに移行するときの規模に対応するためにOOPが誕生した。
今度はPCやスマホなどの多様なGUI、webプログラミングでビューとロジックを分ける必要が出てきた。
ここにOOPは対応しきれてない。
そこで関数型言語が注目されたりした訳だが、今のOOPは関数型言語と同じ所を目指してる最中な気がする。
なぜなら、関数型言語にはコード資産が無いけどOOPには有るから。
全く違うプラットフォーム行くのは怖いから。
実際、言語は優秀でもツール類が絶望的に足りない。
多重で継承すると、デバッグが大変。
継承でロジックの一元化を狙うより、
1番トップの1階層目ぐらいの継承で妥協しておいた方が、
ソースを体系化しやすく、プロジェクトの見通しが良くなる。
言語として多重継承できる言語の方が少ないと思う
あとロジックの一元化は継承とまた別の話だよ
多重じゃなくて、継承の継承でした。
垂直の継承。
継承がロジックの一元化の全てではないが、
手法の一つなので別問題にする必要もないと思うが。
どう別問題に扱うの？
間違いじゃないかな？
関数オブジェクトとかあるし、
GoFのデザパタとかで出て来るオブジェクトは全然DB関係ない
のばっかりじゃん。
JavaScriptやUIプログラミングもオブジェクト指向化してるけど
UIなんてDBと無関係だぞ。
俺は >>937だけど、JavaScriptやっててオブジェクトは「生命体」
だと思ったんだよ、「xxxer」 ていうオブジェクト作ること多いじゃん、
だから「xxxをする人」ってことでしょ。
DIとかオブジェクトを引数としてやり取りしたり、
メソッド内で他のオブジェクトを new したりすると何やってんだか
はじめはわからなくなったけど、
「ある生命体Aの部下として生命体Bを『配属』させ、所有物のように受け渡したり、
部下として仕事をさせる」と考えると結構上手く説明がつくことに気づいたんだよ。
クラスの継承により部分型を表現するのは危険をはらむということはかなり早い時期に指摘されている
だから言語機能としてのインターフェースが考案され、以降はそれを使って部分型を安全に表現する言語が汎用されている
継承は部分型を表現すること以外に、実装の重複をなくす（簡単にいうとコピペによる分散を防ぐ）役割も担っていたが
初期のインターフェースは実装を持てなかったため、継承のメリットのうち後者は捨てるか、クラスとの併用で気をつけて使うしかなかった
ただ、型クラスやトレイトという考え方や言語機能が考案され、インターフェイスも実装を持てるようになったので
クラス（というか継承）の役割はほぼ終わりつつある
初心者への例え話レベルですね。
客、ウェイター、料理人、冷蔵庫(データベース)
客がウェイターに指示をする。
ウェイターが料理人に指示をする。
料理人が冷蔵庫から材料を取り出す。
でも、プログラム上では冷蔵庫から食材を料理人に渡す人がいる。
現実世界では包丁は料理人が使わないと効果を発揮しない。
プログラム上では、包丁だけあれば食材を切り刻むことができる。
店長は、店員を部下を持つ。
だが、店長の所有物ではない。
店員のリポジトリから、店コードでアクセスするものだ。
店長も店から見れば店の所有物なのだから。
だから、データにアクセスする機能は人オブジェクトにはない。
なんか今日はこまめにID変えてるけど。
そうじゃなくて、むかしは大型コンピュータしかなかったから
大きな処理を行うにつれて「ネットワークで繋がった他のコンピュータに処理を委譲する」という
処理形式が現実になってきた。
そうなるともはや処理時間も通信状態も不明な他所のコンピュータで動いてる処理を
シーケンシャルな一意の順番で行ってゆくというのが非現実的になるのが明白で
そういった視点から「こういう処理をせよ」とクラス(独自の処理単位/物理的に別な機械)に命令したら
その単位が他に依存しないで自律的に処理を行う「オブジェクト指向」が提唱された。
(オブジェクトの再利用がどーのというオブジェクト指向とは別物)
そして、現代では「このシーケンシャルに処理が行われるとは限らない」は
薄れるどころかますます重要性を増してる要素なのだけど
なぜか亡霊のように『処理の間に他人が絡まなければ』って
局所的処理があたかもこれからも可能だと"信心"してる
関数型言語とかいうのが地獄の底から這い出してきて
世界の皆が困惑してる。だいたいそんな状況。
> 昔はCUIからGUIに移行するときの規模に対応するためにOOPが誕生した。
それはアラン・ケイのメッセージングのOOPの話で、継承を前提とした現在主流の抽象データ型のOOPとは関係ないよ
念のためメッセージングのOOPというのは所謂「オブジェクトにメッセージを送って」とかいうお題目を唱えながら
設計・実装・実行・運用と幅広い局面における「可能な限りの決定の遅延」を徹底する考え方ね
http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf
>>978
> そうなるともはや処理時間も通信状態も不明な他所のコンピュータで動いてる処理を
> シーケンシャルな一意の順番で行ってゆくというのが非現実的になるのが明白で
> そういった視点から「こういう処理をせよ」とクラス(独自の処理単位/物理的に別な機械)に命令したら
> その単位が他に依存しないで自律的に処理を行う「オブジェクト指向」が提唱された。
そんな「オブジェクト指向」の出自は初耳なんだけど誰が提唱したもの？
ちなみに抽象データ型のオブジェクト指向は、C with Classe（後にC++）のスウストラップのこちらの所謂 what-is 論文が有名
http://dl.acm.org/citation.cfm?id=624721
同時期にEiffelのメイヤー、抽象データ型のリスコフ、SIMULAでクラスとオブジェクトを考案したダールとニガードも
同様の着想（SIMULAスタイルのクラスを抽象データ型として扱い、その継承機構で部分型を表現する）を得ている
その再利用とは別のオブジェクト指向ってどうなったんよ。
MVCとかMVVMじゃ無いよね？そんな昔じゃ無いし。
そのsmalltalkやRubyのオブジェクト指向が関数型言語と同じ方向目指してるなって感じてて、でも今の所関数型言語のが相性が良いように思える。
継承の概念を作ったのはC++
そのさきは
そりゃ大事だろ
誰がどういう背景でどんなことを目指して考案・発案したかって知らないでどうやって使いこなすのさ？
特に「オブジェクト指向」は同名の違う考え方が混在しているうえに
想像で語られるオレ定義が跳梁跋扈しているから、それらに翻弄されないためになおさらでしょ
>>982
誰が提唱したかを知っていれば、それを冠することで区別が付けやすいってだけの話
同じ「オブジェクト指向」でも異質な考え方があるのを区別しなければならない特殊事情を鑑みてこれは必要なこと
いいこと言った
つまりオブジェクト指向に継承やカプセル化は
必要ないし害悪ですらあるってことが明らかになってきているってことだな
あ〜深いヤツは見ててしんどいですね
ロジックの一元化を「このメソッドいろんなところで同じ処理するからまとめたよ！継承したら呼べるよ！」って感じで使ってる所だととても大変
振る舞いを一元化して異なる動作をさせたいメソッドのoverrideで使ってたら苦にはならないよ
手法としては存在するよね？って聞かれたら存在する
でも問題は設計であって継承ではないと考える
お、出たな
カプセル化不要論は浸透したかい？
ありがとうだけど、継承はともかくカプセル化は必要。
モジュールも広い意味でのカプセル化だからね。
それまで不要とは思わないし、副作用と縁のきれない手続き型言語にカプセル化ある種運命共同体。
「どう構造化し記述すべきなのか」なんである
カプセル化が必要なくなるように設計するべき
手続き型に逃げちゃダメ
オブジェクト指向やりたいんでしょ？
カプセル化が要らなくなるまで設計を洗練させること
これ即ちオブジェクトの正規化なり
いんや。
関数型言語したいん。
だから対岸の火事なのん。
ごめん、ちょっと言い方間違えたは、別に部下として配属する
必要はないな。
あと、thisって何かイマイチしっくり来なかったんだけど、
「この」って解釈するからどういう意味なのかわからかったが、
「俺の」と解釈しほうがいいと思った。
つまり任意のパラメータを「俺のもの」として保持しておけば、
外部から「こいつの(xxさんの)」として呼び出せるって訳だ。
カプセル化は最重要だよ
おまえは何もわかってない
わかろうともしていない
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 96日 3時間 8分 15秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 【文春】M-1王者コンビ「ウエストランド」河本太、タクシー運転手に暴行トラブル「腕に噛みつき、前歯が欠け…」 [Anonymous★]
- 【鉄道】女性「電車で隣に座ってくる男キモい」SNS“炎上”…男女で《賛否》真っ二つ、それぞれの言い分とは [ぐれ★]
- 【三重】保健室に来た男子中学生を抱きしめたりキスをしたり…２７歳女性養護教諭を懲戒免職 [シャチ★]
- 【文春】「相合い傘で自宅マンションへ…」内田理央と人気YouTuberヒカルの寿司デート＆お泊まり愛“スクープ撮 [Ailuropoda melanoleuca★]
- 『平和堂』公式X、いなり寿司誤認逮捕事件「いなりずしを渡した知人もダメ」投稿2件に「いいね」 「誤った操作」と陳謝 [Hitzeschleier★]
- 【広島】「男性が燃えている」通報 重いやけどの男性「たばこ消えたと思いポケットに」 [少考さん★]
- 【実況】博衣こよりと周防パトラのドキドキたこパ🧪
- 【速報】ベジタリアンが苦痛を与えるのは同意するだろうね
- お前らのズボンの上からおちんちんさわさわ
- 【悲報】DLsite、クレカ決済が使えなくなり売上がヤバイぐらい下がる [637618824]
- 【悲報】那須川天心、変なことを言い出す
- 【速報】空見ろ！！ [782460143]