オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/04/02(日) 21:12:28.24

ドアクラスの設計に上位クラスの意思が必要なら、それはモジュール分解できてないってことじゃね

**デフォルトの名無しさん** · 2017/04/02(日) 21:21:56.68

>>9
こんなんで意味不明とか言ってたらついていけんぞ
このドアに猫を通すにはどうするとか言ってたんだから

**デフォルトの名無しさん** · 2017/04/02(日) 21:30:37.45

>>10
〇〇がどう使われるかは全くわかりません
〇〇にはこれこれこういう属性(性質)がありえます
〇〇を設計せよ
ふぁい！？

モジュール分解とか全く関係ない

**デフォルトの名無しさん** · 2017/04/02(日) 21:38:49.75

ドアストッパーは回転角に制限を与える
ドアクローザーは、半開状態時にゆるやかに閉状態へと変化する機構

犬猫が突進すればドアタイプと重量によっては開き、場合によっては開かない

**デフォルトの名無しさん** · 2017/04/02(日) 22:03:35.89

建築家がCADで使うためのドアのモデル
ドアメーカーが生産管理のために使うためのドアのモデル
住宅メーカーが受注管理のために使うドアのモデル
ドア開け系のスマホゲームで使うためのドアのモデル

これらが同じになるわけがないんだから
どういう目的でどういう風にソフトウェア上で使われるのか
それがわからないものを設計しようとするのは時間の無駄

**デフォルトの名無しさん** · 2017/04/03(月) 01:16:59.01

>>14
よくよく考えてみるととても難しいが完全不可能ではないしょ、具体的にこんなドアと呼んでないからこそ
どんな状況とパターンでもドアをドアと呼ぶに相応しい共通項を見つけるゲームや
投げる物ではないし食べる物でもないしまぁある程度までは

**デフォルトの名無しさん** · 2017/04/03(月) 11:28:24.86

なんでメソッド名って三単現じゃないことが多いの？

**デフォルトの名無しさん** · 2017/04/03(月) 12:06:00.26

開発者に嫌われているプログラミング言語 25
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

**デフォルトの名無しさん** · 2017/04/03(月) 12:20:09.66

>>17
他のせんたくしが

**デフォルトの名無しさん** · 2017/04/03(月) 12:21:52.64

>>17
他の選択肢を比較的簡単に選べるものが上位になってる気がする。
つまりdisりやすいっていう

**デフォルトの名無しさん** · 2017/04/03(月) 13:17:31.81

>>1
糞みたいなテンプル貼るのやめろ

**デフォルトの名無しさん** · 2017/04/03(月) 19:08:53.61

>>17
名前さえ上がらないCobol

**デフォルトの名無しさん** · 2017/04/03(月) 19:16:57.14

まだやってんの？

**デフォルトの名無しさん** · 2017/04/03(月) 20:08:09.88

>>22
最後にレスした奴が勝者だからな

**デフォルトの名無しさん** · 2017/04/03(月) 20:17:49.73

勝ち負けってあったの？

**デフォルトの名無しさん** · 2017/04/03(月) 20:20:18.71

俺２ｃｈの議論で負けたことない

変なこと言い出したり話がそれたりで、俺がレスしなくなるか
俺が相手をやりこめて、相手がレスしなくなるかだ

**デフォルトの名無しさん** · 2017/04/03(月) 20:23:36.71

勝負してないじゃん

**デフォルトの名無しさん** · 2017/04/03(月) 20:54:50.17

土俵の下からヤジ飛ばしているだけで勝負している気になってるいつものあいつかw

**デフォルトの名無しさん** · 2017/04/03(月) 20:57:17.28

ウィナーオブジェクト作ろうぜ。とりあえずメソッドはコールだけ

**デフォルトの名無しさん** · 2017/04/03(月) 21:47:10.19

>>14
そこが決まってないからこそ
物事の捉えかたが人によって違うのがいいんだろ

最初から無駄なのはわかりきってるんだから無駄とかいうな

**デフォルトの名無しさん** · 2017/04/03(月) 21:49:08.96

>>15
どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるのは
ソフトウェアの設計やプログラミングの話ではなく言語学や哲学における分節化の話
なので板違い

**デフォルトの名無しさん** · 2017/04/03(月) 21:57:16.66

>>29
どういうシステムでどういう使われ方をするドアを想定した結果なのかを示せば
少しはマシだったろうけどそれをやったやつ前スレで1人でもいたか？

コンテキスト無しで現実をモデリングしようとしても設計力は高まるどころか低下するだけ
オブジェクト指向かどうかとか関係ない
無駄

**デフォルトの名無しさん** · 2017/04/03(月) 21:57:20.04

>>30
つまりオブジェクト指向は哲学と言うことだな。納得出来る

**デフォルトの名無しさん** · 2017/04/03(月) 22:05:05.77

抽象化（）

**デフォルトの名無しさん** · 2017/04/03(月) 22:05:09.73

>>30
> どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるのは

取っ手のないドアがあるから、取っ手は共通項には含まれない
鍵のないドアもある。
材質も関係ない。

**デフォルトの名無しさん** · 2017/04/03(月) 22:18:18.28

なるほど、そうか。

オブジェクト指向を「現実世界を構成しているクラスを見つけ出す作業」と
捉えるからややこしいことになるんだ。

手続き型でも関数型言語でも、現実世界を表現する関数を見つけ出す作業
なんて考えるやつはいない。

見つけ出す作業ではなくて、作り出す作業なんだ。
現実世界ではなくターゲットとする要件を実現する
クラスや関数を自分たちで作り出す作業。

だから最初に要件が決まらないとクラスも関数も作れない

あたり前のことだが、混ぜっ返すやつは
「そのクラス・関数では世界のすべてを表現できない」と言ってるわけだな。

**デフォルトの名無しさん** · 2017/04/03(月) 22:25:42.68

プログラミングが目的になっちゃうと
そういう思考になるのかしらん？

**デフォルトの名無しさん** · 2017/04/03(月) 22:25:47.59

どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるってのは
ドアという言葉を定義づけるのと同じこと

言葉を定義づけるには「ドアと窓は何が違うのか？」とか
「ふすまや障子はドアなのか？」みたいに隣接する概念と比較する以外有効な方法はない

で「ドアと窓は何が違うか？」みたいな問いを考えるゲームがしたけりゃ
どっか他でやりなよ
ここは板違い

**デフォルトの名無しさん** · 2017/04/03(月) 22:42:21.43

そう。我々がやってるのは、要件でドアと定義されたものを
クラスに落とし込む作業なのだ。

決しての中にあるドアがどういうクラスかを
解析する仕事ではないのだ。

**デフォルトの名無しさん** · 2017/04/03(月) 22:42:49.69

決して世の中にあるドアがどういうクラスかを
解析する仕事ではないのだ。

**デフォルトの名無しさん** · 2017/04/03(月) 23:09:18.39

>>31
同じドアを扱っているにもかかわらず
最初は小売りか設計かと思わせておいて
いきなり「猫に押される」っていうコンテキストも抽象度も異なるものが割り込んでくるのが
問題の肝

多少視点をゆさぶられても大丈夫なのを設計しろってことだろ
そこで状況がわかんないとか言ってたら降参してるようなもんじゃん

**デフォルトの名無しさん** · 2017/04/03(月) 23:57:11.85

なんかわからんけど急にしにたくなった

**デフォルトの名無しさん** · 2017/04/04(火) 00:16:51.37

俺も俺も

**デフォルトの名無しさん** · 2017/04/04(火) 00:32:31.54

いいぞ。遠慮なく死ね

**デフォルトの名無しさん** · 2017/04/04(火) 00:33:57.09

現実世界をモデリングできているか、とかいう謎の評価基準

迷宮を進むゲームでドアとして表現されたドアがあったとして、そのモデリングの良し悪しを
・家の内装をVR体験させるソフトでも使えるか
・大型家電通販でドア付きの部屋に搬入できるかをチェックするプログラムでも使えるか
・エアコンの空調のシミュレーションでも使えるか
で判断したことがあるのかな。そうだったら何も言えない。

**デフォルトの名無しさん** · 2017/04/04(火) 01:01:13.36

オブジェクト指向にむりやり難癖つけてるけど結局
「具体性を持たせることで取り回しが楽になった」に対して
「これには対応できるのか！」「こういう例外はどうだ！」って難癖てるだけだから
「で、おまえの棲んでるとこの方は取り回しどうなの？」って
隠れ家に光浴びせると黙って棲んでる泥に潜っていくというね…

**デフォルトの名無しさん** · 2017/04/04(火) 01:32:16.54

>>40
問題の肝でもなんでもないわｗ

そういうふうに設計が変わった時に
安全な方法で設計を変更するのが
リファクタリングだよ。

どっかのバカ共は、汚いコードを修正するものだと
勘違いしているようだがね。

オブジェクト指向に限らず、変更はあるのだから
その変化についていく技術が重要

**デフォルトの名無しさん** · 2017/04/04(火) 01:37:41.67

>>17
Swiftが入ってない
やり直し

**デフォルトの名無しさん** · 2017/04/04(火) 05:34:43.80

キャットドア問題解決したのか?

**デフォルトの名無しさん** · 2017/04/04(火) 07:33:17.45

素材まで網羅した完璧なドアの設計を最初からしなくて良いのがオブジェクト指向の強みなんじゃね

難癖野郎の要望にも応えられる

**デフォルトの名無しさん** · 2017/04/04(火) 07:34:20.63

>>17
C#最高なだけじゃねえか

**デフォルトの名無しさん** · 2017/04/04(火) 15:08:10.80

今後も使い続けたいと思うかどうかの割合が低いもの
↓
嫌われている

さすがマイナビ
堂々とすり替えｗ

**デフォルトの名無しさん** · 2017/04/04(火) 18:42:21.83

データベース操作クラスって
アンチパターンらしいですけど
世間ではどうやって操作をまとめてるんですか?

**デフォルトの名無しさん** · 2017/04/04(火) 18:44:12.01

>>52
まず、アンチパターンだと言ってる人に聞いてみてください。

**デフォルトの名無しさん** · 2017/04/04(火) 19:01:23.29

オブジェクト指向って、
プログラミングを自動化＝部品化してくれるものというイメージしかない。
プログラマはプラモデルを組み立てているような感覚。

**デフォルトの名無しさん** · 2017/04/04(火) 19:22:07.15

>>52
レコードセットとかフィールドとかトランザクションを抽象化することの話？

**デフォルトの名無しさん** · 2017/04/04(火) 19:48:05.98

DAOみたいなのがクソなだけで、アクセスを抽象化したクラスは必要。

**デフォルトの名無しさん** · 2017/04/04(火) 19:54:26.70

>>54
これがオブジェクト指向の一つの存在パターンやしな
スマホアプリとかの画面パーツはこれで配布してるし

52 · 2017/04/04(火) 20:11:51.69

操作がクラス名としておかしいと、
何かの読み物で読みました

名詞じゃないクラスは
オブジェクト指向が出来ていないと
疑えと

じゃあデータベースなら良いのかなと
思いましたが、屁理屈かなとも思い

**デフォルトの名無しさん** · 2017/04/04(火) 20:18:23.65

それってUpdateHogeクラスみたいなのがあるってことなの？
Commandパターンとかなら理解できるが
データベース操作用にそういうクラスは普通作らないわな

**デフォルトの名無しさん** · 2017/04/04(火) 20:57:28.90

>>56
その抽象化がDAOやろ？

**デフォルトの名無しさん** · 2017/04/04(火) 21:01:19.65

DAOクラスの設計までごちゃごちゃ言い出すのがオブジェクト指向

お前らの話聞いてたらデータベースにつなぐのに何年かかんだよ

**デフォルトの名無しさん** · 2017/04/04(火) 21:08:11.49

>>61
説明だけなら数分もあれば終わるだろうから
それ聞いて接続できるまでの時間はお前次第だと思う。

**デフォルトの名無しさん** · 2017/04/04(火) 21:08:42.56

extensionがすべて解決してくれる…！

**デフォルトの名無しさん** · 2017/04/04(火) 21:09:58.53

でもDAOが糞面倒なのは同意だが

**デフォルトの名無しさん** · 2017/04/04(火) 21:26:31.39

>>60
リポジトリ

**デフォルトの名無しさん** · 2017/04/04(火) 21:38:41.73

db操作クラスっていかんのか
名前の通りdbから変数やデータ取り出して入れる専用クラスって意味でいいんだよな？

オブジェクトで使い易いんじゃないのか？？

**デフォルトの名無しさん** · 2017/04/04(火) 21:57:16.59

db操作クラスにキャットドアつけよーぜ!

**デフォルトの名無しさん** · 2017/04/04(火) 23:04:38.14

>>62
絶対に数分じゃ説明できない

途中で猫の生態みたいな解説をいれるのがオブジェクト指向だから

SQL叩きますの他の言語とは一味違う

**デフォルトの名無しさん** · 2017/04/05(水) 00:16:02.14

>>68
猫の生態とは例えばどんなことを
お前は説明するの？

**デフォルトの名無しさん** · 2017/04/05(水) 00:38:08.73

オブジェクト指向ってこういうやつやろ！？が酷すぎて
田舎の中学生が「ぼくのかんがえたアメリカ人」の作り話を大人にしてるみたいになっとるな。

**デフォルトの名無しさん** · 2017/04/05(水) 00:38:34.63

>>60
ちゃう。抽象化を間違っちゃったのが、DAO

**デフォルトの名無しさん** · 2017/04/05(水) 00:56:26.96

クラス名が名詞じゃないDB操作クラスってマジどういうの?

**デフォルトの名無しさん** · 2017/04/05(水) 08:19:13.48

>>71
どう間違ってるの？

**デフォルトの名無しさん** · 2017/04/05(水) 09:38:42.71

俺がDAOの存在理由が理解できないから、間違い

**デフォルトの名無しさん** · 2017/04/05(水) 10:59:33.50

>>74
【が】が多い

**デフォルトの名無しさん** · 2017/04/05(水) 15:50:39.12

>>74
存在が間違ってる奴本人が自己紹介

>>73
DAO 想像力が足りない辺りでググれば出たくるんじゃなかったかな

あの記事はPHPerのものにしてはとても良く書けているから必読だ。
近くにActiveRecordとDataMapperの実装解説もあるから、まだDAOとか言うゴミを使ってるバカは是非読んだ方がいい。
最終的な実装はあれでもダメダメだけどな。

**デフォルトの名無しさん** · 2017/04/05(水) 21:47:59.72

オブジェクト指向は命名が重要だけど、DTOにはなんて名前付けてますか?

自分はHogeDTOとか付けてるけど
我流なんで自信が無いです

**デフォルトの名無しさん** · 2017/04/05(水) 22:31:27.34

個人的にはHogeDaoとかHogeDtoみたいなのがたくさんあるとやる気なくす
HogeQueryとかHogeCommandとかHogeJsonみたいなもう少し意味のある名前がいい

**デフォルトの名無しさん** · 2017/04/05(水) 22:56:14.24

>>78
お前の個人的なやる気なんか知らないが、
何でもかんでもDTO作りまくる設計は、確かにアホ

**デフォルトの名無しさん** · 2017/04/05(水) 23:31:52.52

ほぼストアドでシステム開発してる人が
最近の連中は技術が無くてストアド書けないと嘆いていたのですが
ストアドでオブジェクト指向は出来るんですか？

C#+EFでほとんどSQLを書いたことが無いので
データベース事情に明るくないもので

**デフォルトの名無しさん** · 2017/04/06(木) 00:05:36.90

SQL serverならSQL clrが使えるはず

**デフォルトの名無しさん** · 2017/04/06(木) 01:57:21.96

なぜにストアドでオブジェクト指向！？

**デフォルトの名無しさん** · 2017/04/06(木) 04:16:30.36

>>80
一応Ora限定で出来たと思うけど、Web方面だと
エッジサーバ側であれこれするからストアドいらん気もするよ
業務系だとストアド一本で職になるようだが

**デフォルトの名無しさん** · 2017/04/06(木) 04:54:01.44

1クラスについて、最低1in/1out(interface)を作るよう指示されたことあったな
全てのクラスについて

ヘキサゴナルなんだと、それが……

**デフォルトの名無しさん** · 2017/04/06(木) 05:56:27.93

なんでもストアドでやるのはバッドノウハウだが使うべき所では使わないとくっそ遅いシステムが出来上がるぞ

某大手ITが作ったくっそ高いシステムみたいに

オブジェクト指向も拗らせ過ぎるとこうなるって典型例

**デフォルトの名無しさん** · 2017/04/06(木) 09:05:31.52

>>76
最終的な正解が書いてあるサイトはどこですか

**デフォルトの名無しさん** · 2017/04/06(木) 09:40:42.68

>>85
その話のどこにオブジェクト指向が関係するのか？

**デフォルトの名無しさん** · 2017/04/06(木) 10:32:51.49

第 (N+1) 次オブジェクト指向問答
https://togetter.com/li/1097950

**デフォルトの名無しさん** · 2017/04/06(木) 12:29:44.71

>>82
オブジェクト指向と言わず
共通の開発手法があるのかなと

モデリングがそれに当たるのかな

**デフォルトの名無しさん** · 2017/04/06(木) 12:47:05.55

>>86
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.

**デフォルトの名無しさん** · 2017/04/06(木) 12:49:59.24

**デフォルトの名無しさん** · 2017/04/06(木) 13:35:28.83

>>90
Oh, dont say that!Dont say that.Im a stupid man.You should be kind to me!

**デフォルトの名無しさん** · 2017/04/06(木) 13:41:15.62

>>92
ね　ぼ　け　る　な！

**デフォルトの名無しさん** · 2017/04/06(木) 18:06:11.40

オブ農って何ですか？

**デフォルトの名無しさん** · 2017/04/06(木) 18:24:59.98

>>92
気持ちの伝わるいい返しだな

**デフォルトの名無しさん** · 2017/04/06(木) 18:36:07.83

>>89
ストアドは基本SQLだからDB設計出来る程度のリレーショナルモデルの知識あれば十分
技術うんぬん言うほと難しい話じゃない DBが違えば中身はいろいろと違ってくるけどね

ストアドで条件分岐やループやカーソルを多用してる場合
本当にDBレイヤーでやるべき仕事なのか考えたほうがいいと思う
ビジネスロジックのあるべき場所や柔軟性と最適化のバランス次第

**デフォルトの名無しさん** · 2017/04/06(木) 22:21:27.75

制御文減らすための文法じゃないの？

**デフォルトの名無しさん** · 2017/04/06(木) 23:19:03.66

>>95
伝わるか！　ボケナス！

**デフォルトの名無しさん** · 2017/04/07(金) 07:14:09.24

データベースのモデリングした後
オブジェクト指向のために
クラス設計すると、エンティティの
抽出とか同じ事をしている気に
なってくるんですが

モデリングは実はクラス設計だけで
OKとかありますか?

**デフォルトの名無しさん** · 2017/04/07(金) 09:46:16.48

>>99
そのためにO/Rマッパーがある。
O/Rマッパーを使うとデータベースのモデリングを
クラスで表現できるから、そのまま移植すれば良い

**デフォルトの名無しさん** · 2017/04/07(金) 10:24:46.37

ORマッピングすればDaoなんていらんね

**デフォルトの名無しさん** · 2017/04/07(金) 11:00:36.56

>>97
意識して減らそうとしないと無理かな
ストアドは、テーブルや索引、マテリアらいずビューとかの整理に使う物かな
要は、あるタイミングでデータベースを単一の主体が加工する場合に使うと便利
複数クライアントが平行して操作するときに共通化を求めてやるもんじゃない。
それは、ビューなりストアドトリガーや制約で共通化するべきもの。
条件分岐があるなら、BLに溶け込ませろってのはそういう意味かと

**デフォルトの名無しさん** · 2017/04/07(金) 11:05:00.66

ストアドプロシージャは、共有メモリや通信を目的に設計されていない。
なんかの結果を通信用に設けたテーブルに書いて、そのテーブルを別の主体が参照して連動させるとかオーバヘッドが多く、排他が冗長になり、パフォーマンスがでない。

**デフォルトの名無しさん** · 2017/04/07(金) 12:51:44.94

>>95
気持ちのわるいいい返しだな

と読んでしまった

**デフォルトの名無しさん** · 2017/04/07(金) 14:06:58.01

>>102,103
基本的に何言ってるかよくわからない。

例えば集約関数実装することを考えれば、元となるデータの通信を行わなくて良い分、
ストアドの方が速い可能性が高い。

また、複雑なデータ処理や文字列操作が多くてストアド自身のコードの実行が遅い場合もあるが、
ストアドに別言語を使えるRDBMSもある。

さらに言えば、ストアドがimmutableであるなどの宣言ができるRDBMSがあり、その場合は
実行結果をキャッシュしてくれたりする（同じ引数の場合はコードを実行しない）。

ビジネスロジックをRDBMS内部におくべきかどうかというのは、また別の話。

**デフォルトの名無しさん** · 2017/04/07(金) 18:38:30.82

最初はデータ中心アプローチでいいよ

カージナリティーとかに抜けが発生するからね
それからモデル層の設計すればいい

**デフォルトの名無しさん** · 2017/04/07(金) 19:36:14.64

思ったよりスレッド周りで手こずったけど>>8をPHPで書いてみた

http://ideone.com/lcnAEj

**デフォルトの名無しさん** · 2017/04/08(土) 12:10:05.09

>>105
集約関数、つまりある複雑な条件、複数のテーブルを結合せずに参照し、なんらかの判定を行う。
これは一般的なバッチ処理と言われるもので、データベースインスタンスに閉じて実行すればよい。
何らかのパラメータが伴い、レコードのサブセットのみを対象にする場合、ストアドにしても処理遂行を基準に、倉実行してもパフォーマンスは劇的には変わらない。

データベースは、純粋に取り扱うレコード数に比してパフォーマンスが確定する。

あと、結合できるなら、ストアドはいらない。
ビューなりマテリアルズどビューのがまし

**デフォルトの名無しさん** · 2017/04/08(土) 12:16:30.94

ここ、何のスレだっけ？