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

0003デフォルトの名無しさん2017/04/02(日) 17:00:47.26 ID:n7h/bBRg

モダンC言語プログラミング
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 まとめ

0004デフォルトの名無しさん2017/04/02(日) 17:02:31.63 ID:n7h/bBRg

https://teratail.com/questions/37674

以前、Linuxのカーネルを読んだ時、オブジェクト指向的なプログラムされているなと思ったことが有ります。
データと関数ポインタをセットにしているイメージですね。（仮想関数的なテクニックだったように思います。）

0005デフォルトの名無しさん2017/04/02(日) 17:06:49.50 ID:n7h/bBRg

Linuxシステムプログラミング - 60 ページ - Google ブック検索結果
https://books.google.co.jp/books?isbn=4873113628
> Linux のすべてのフアイルシステムの基本となる共通フアイルモデル
> 〈 c 。 mm 。 n 血 em 。 de ー)を導入し、抽象化を図っています。共通ファイルモデルでは、
> 関数ポインタやオブジェクト指向的な考え方†を採用したフレームワークを提供し、フアイル

0006デフォルトの名無しさん2017/04/02(日) 17:52:12.44 ID:KLExlLIQ

●ドア設計問題　(出典は初代スレ)
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)数匹の犬猫が同時にドアを押すと合計重量で押すことができる

0007デフォルトの名無しさん2017/04/02(日) 18:47:42.03 ID:w0zTGR96

おつかれさまでした

0008デフォルトの名無しさん2017/04/02(日) 20:12:49.88 ID:0XahTNwQ

>>6　1(a)(b)のRubyによる実装

http://ideone.com/or6JyE

0009デフォルトの名無しさん2017/04/02(日) 20:48:03.21 ID:TvISwdcG

>>6
ドアをどういうソフトウェアの中でどう使うのかを説明しろよ
それなしに”設計せよ”とか意味不明だぞ

そこに書いてるのはドアの属性だけだから単なるデータ
クラスとかオブジェクト指向とか全く関係ない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0016デフォルトの名無しさん2017/04/03(月) 11:28:24.86 ID:MWcUZH/3

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

0017デフォルトの名無しさん2017/04/03(月) 12:06:00.26 ID:4MLmk5yA

開発者に嫌われているプログラミング言語 25
http://news.mynavi.jp/news/2017/03/30/133/
オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net->画像>6枚

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

0018デフォルトの名無しさん2017/04/03(月) 12:20:09.66 ID:28dsjWMc

>>17
他のせんたくしが

0019デフォルトの名無しさん2017/04/03(月) 12:21:52.64 ID:28dsjWMc

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

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

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

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

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

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

まだやってんの？

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

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

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

勝ち負けってあったの？

0025デフォルトの名無しさん2017/04/03(月) 20:20:18.71 ID:7vHtJU9B

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

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

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

勝負してないじゃん

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

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

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

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

0029デフォルトの名無しさん2017/04/03(月) 21:47:10.19 ID:7vHtJU9B

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

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

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

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

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

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

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

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

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

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

抽象化（）

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

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

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

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

なるほど、そうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0040デフォルトの名無しさん2017/04/03(月) 23:09:18.39 ID:7vHtJU9B

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

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

0041デフォルトの名無しさん2017/04/03(月) 23:57:11.85 ID:7vHtJU9B

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

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

俺も俺も

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

いいぞ。遠慮なく死ね

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0054デフォルトの名無しさん2017/04/04(火) 19:01:23.29 ID:12S8JRG0

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

0055デフォルトの名無しさん2017/04/04(火) 19:22:07.15 ID:6xG2515u

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

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

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

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

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

0058522017/04/04(火) 20:11:51.69 ID:PnaBNYoq

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

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

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

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

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

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

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

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

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

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

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

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

0063デフォルトの名無しさん2017/04/04(火) 21:08:42.56 ID:8WGG2cnP

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

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

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

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

>>60
リポジトリ

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

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

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

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

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

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

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

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

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

0069デフォルトの名無しさん2017/04/05(水) 00:16:02.14 ID:Zf7glq/Z

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

0070デフォルトの名無しさん2017/04/05(水) 00:38:08.73 ID:yRUZ/Ldq

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

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

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

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

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

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

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

0074デフォルトの名無しさん2017/04/05(水) 09:38:42.71 ID:Zf7glq/Z

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

0075デフォルトの名無しさん2017/04/05(水) 10:59:33.50 ID:1lx41BrP

>>74
【が】が多い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0082デフォルトの名無しさん2017/04/06(木) 01:57:21.96 ID:FGV9lFi+

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

0083デフォルトの名無しさん2017/04/06(木) 04:16:30.36 ID:2G8EDGPv

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

0084デフォルトの名無しさん2017/04/06(木) 04:54:01.44 ID:2G8EDGPv

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

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

0085デフォルトの名無しさん2017/04/06(木) 05:56:27.93 ID:8G48c3ze

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>92
ね　ぼ　け　る　な！

0094デフォルトの名無しさん2017/04/06(木) 18:06:11.40 ID:7ga4e71i

オブ農って何ですか？

0095デフォルトの名無しさん2017/04/06(木) 18:24:59.98 ID:FGV9lFi+

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

0096デフォルトの名無しさん2017/04/06(木) 18:36:07.83 ID:FGV9lFi+

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

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

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

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

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

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

0099デフォルトの名無しさん2017/04/07(金) 07:14:09.24 ID:mWTY/96m

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

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

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

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

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

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

0102デフォルトの名無しさん2017/04/07(金) 11:00:36.56 ID:Bku+sAks

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

0103デフォルトの名無しさん2017/04/07(金) 11:05:00.66 ID:Bku+sAks

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

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

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

と読んでしまった

0105デフォルトの名無しさん2017/04/07(金) 14:06:58.01 ID:IIlb/TvM

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

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

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

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

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

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

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

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

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

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

http://ideone.com/lcnAEj

0108デフォルトの名無しさん2017/04/08(土) 12:10:05.09 ID:gBZ8NF+o

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

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

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

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

ここ、何のスレだっけ？

0110デフォルトの名無しさん2017/04/08(土) 13:06:18.31 ID:MgZOgx+n

マルチスレッドわろｗ

0111デフォルトの名無しさん2017/04/08(土) 13:31:56.58 ID:D50K8DvF

よくわからないことを喚き散らすやつの隔離スレだよ

0112デフォルトの名無しさん2017/04/08(土) 13:51:19.98 ID:MmqHTY99

まともにキャットドアもデータベース接続もできないゴミが、僕が使ってる言語のライブラリをだしにしてホルホルするスレだよ

0113デフォルトの名無しさん2017/04/08(土) 14:06:38.04 ID:FmwPLc4P

お疲れ様でした！

0114デフォルトの名無しさん2017/04/08(土) 17:16:52.66 ID:6tEdYN6j

>>112
やはりキャットドア問題を解決することなく次にはいけんな

0115デフォルトの名無しさん2017/04/08(土) 18:27:20.39 ID:ZmPKT6lF

>>108
集約関数もバッチ処理も理解できないやつは
いちからやり直すかプログラミングから足を洗うかしてくれ

0116デフォルトの名無しさん2017/04/08(土) 19:54:52.03 ID:FmwPLc4P

>>114
あんただけだよいつまでもキャットドア問題とか言ってんの

0117デフォルトの名無しさん2017/04/09(日) 01:56:39.35 ID:+d/g4xuk

要件の一つに「Oraにロックインされるの勘弁」があるとマッパー必須

……いやなのは「もうOracleにカネ献上するのは嫌なんや！」って奴
既存のストアド見て置き換えなきゃいかんでしょ

最高にクソだったのは1関数5000行if12段のストアド
あれはサジ投げてとりあえずおっつけの改修だけやることにした

0118デフォルトの名無しさん2017/04/09(日) 02:27:20.83 ID:S92Irkmv

>>117
設計書なかったんだ、ははワロス

0119デフォルトの名無しさん2017/04/09(日) 02:34:17.14 ID:+d/g4xuk

>>118
設計書がどうこうとかじゃなくて、「おにぎりスタッバー」程度余裕で超えるド畜生
丸尾末広とか風船クラブ級の理解不能レベル

だから俺のところに来たんだろうが、さすがに当座のおっつけ以上の対応はムリだったな

0120デフォルトの名無しさん2017/04/09(日) 02:39:11.61 ID:+d/g4xuk

むしろ1関数5000行if12段の脅威を感覚でわからんとかヤバいな

最低でも2048くらい分岐が発生する
平均的な人間は7くらいしかわからん（Code Completeを参照のこと）

0121デフォルトの名無しさん2017/04/09(日) 02:50:02.23 ID:+d/g4xuk

一応言っておくが、俺はWAISテストで引っかかってるんで3か4しかわかんねぇようだ
まぁそのくらいあればシノギはできるようだがね

WAISでググるこたぁなかろうし、ググったらヘイトするんだろうけどな

0122デフォルトの名無しさん2017/04/09(日) 08:12:06.51 ID:MBRFLDgA

if12段が*最低*でも2048*くらい*分岐って計算の方がヤバい

0123デフォルトの名無しさん2017/04/09(日) 08:18:43.92 ID:BIX5wjPO

分岐を志向するか統合を志向するかで無能か有能か分かれそう

0124デフォルトの名無しさん2017/04/09(日) 08:49:12.98 ID:Zg/bzUyC

と言いますと？

0125デフォルトの名無しさん2017/04/09(日) 09:36:40.13 ID:Ch2od0MN

無理なクラスタリングはハンマー釘病になる
その場その場に応じた最適解を選べばいいだけ

0126デフォルトの名無しさん2017/04/09(日) 11:52:37.41 ID:cTj84sSr

釘宮病ってなんだ？

0127デフォルトの名無しさん2017/04/09(日) 23:56:30.49 ID:dNHxTouX

12段ifに於ける1つの分岐
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;
}}}}}}}}}}}}

0128デフォルトの名無しさん2017/04/10(月) 00:17:53.55 ID:f5bfXI8/

改良版

if(a && b && c && d && e && f && g && h && i && j && k && l) {
....x;
} else {
....y;
}

ここから言いたいことがわかるかね？

0129デフォルトの名無しさん2017/04/10(月) 02:17:00.84 ID:ogTJ3oaz

>>128
先に言えハゲ

0130デフォルトの名無しさん2017/04/10(月) 02:17:56.14 ID:f5bfXI8/

はげてねーよはげ

0131デフォルトの名無しさん2017/04/10(月) 07:53:31.28 ID:1VtPDmxC

>>130
ハゲろ

0132デフォルトの名無しさん2017/04/10(月) 08:53:35.90 ID:SOLotzzn

ガキかよ...

0133デフォルトの名無しさん2017/04/10(月) 12:33:19.05 ID:dyJkQ9HN

>>132
うるせー、ハゲ

0134デフォルトの名無しさん2017/04/10(月) 13:12:58.61 ID:Bu07ZLW6

>>120
ちょっとはまともな文章書けないのかね。

12段ifというのが12個のifということなら、分岐回数は最大で12回。
ネストしない12個のifなら、分岐の組み合わせは2^12=4096個。
>>127のように完全にネストした12個のifなら、分岐の組み合わせは13個。

Code Completeに何が書かれてるのかしらんが、正しく読み取れてないのでは？

0135デフォルトの名無しさん2017/04/11(火) 04:41:06.97 ID:mchlWSiU

>>134
あーうん、そんなもんだねぇ2048じゃなかったな

キャンパスノートを2冊くらい使ってメモしつつ
デバッグしてもどこでバグってるのかわからんのよ、あれは参った
とりあえず動くようにはしたがエラー系がすげぇ怖いね
後日何も連絡来ないから気にしなくていいんだろうけど

>>134
変数や関数などは、平均的な人間は7個までしか覚えられないから気をつけろよ、
という心理学の知見が公表されているページがあるんよ

0136デフォルトの名無しさん2017/04/11(火) 07:15:24.21 ID:8/HzfseJ

物理クラス設計にDTOって書きますか?

一応クラスだしなぁと
悩んでます

流石に論理じゃ不要と思いますが

0137デフォルトの名無しさん2017/04/13(木) 07:07:56.79 ID:FYxnOP1R

社員クラスと所属クラスがあって
年月を問い合わせたら
その年月時点での所属を返すように
したいのですが、どちらのクラスに問い合わせるのが正しいと思いますか

0138デフォルトの名無しさん2017/04/13(木) 07:18:59.41 ID:m/ZfxtWH

おいらなら、社員クラスに所属クラスを埋め込むが。
と言うか、所属はクラスである必要すら感じない。
構造体でよく無いか？

0139デフォルトの名無しさん2017/04/13(木) 08:37:21.93 ID:UeuCulgt

sql

0140デフォルトの名無しさん2017/04/13(木) 09:29:06.54 ID:i0SFiNXj

>>137
とりあえず社員クラスと所属クラスと年月の関係を書くように

0141デフォルトの名無しさん2017/04/13(木) 11:36:09.37 ID:Wjez3hz+

所属クラスって名前でいいのか？
部署クラスとかが普通だと思うな

0142デフォルトの名無しさん2017/04/13(木) 20:19:04.83 ID:U0NTTHzz

所属クラスは確かにおかしいですね
部の下にグループがあるので部署という名前は避けたのですが
部署クラスがグループ教えてくれるのはなんら問題ないことに気付いたので部署クラスに改名しました

社員クラスのフィールドには
·社員番号
·氏名

部署クラスのフィールドには
·部署
·部署配下のグループ

としているのですが
所属部署を知りたい時に、社員に今の所属を聞くべきか、部署に社員の所属を教えて貰うのか、どちらが好ましいのかなとお聞きしたくて書きました

0143デフォルトの名無しさん2017/04/13(木) 21:34:32.88 ID:kfgJyhKZ

>>142
社員がわかっているときは、社員に聞けばいいし、
部署がわかっている場合は、部署に聞けばいい。
どちららでもOKだし、ちゃんと作るならば
どちらからでもできるようにする

これは分かってない人意外と多いんじゃないかと思うけど、
データベース（RDBMSを使わないにしろ）っていうのは、
単体のテーブルの集まりではなくて、全体で一つのデータベースなんだよ

クラスに置き換えていうならば、クラス一つ一つが単独で存在しているのではなくて
クラスとクラス、そしてその関係を定義して、複数のクラスで一つのデータベースを表現する
（ただし設定テーブルのような、他の完全に独立しているテーブルのような例外はある）

だから社員クラスのフィールドには、所属部署というフィールドを持っているだろうし
部署クラスには、所属社員を取得するメソッドが存在している

0144デフォルトの名無しさん2017/04/13(木) 22:59:09.23 ID:Wjez3hz+

キリッ

0145デフォルトの名無しさん2017/04/14(金) 01:10:42.96 ID:DK6sdjwT

>>137
どっちでもええ、ダメだったら直すまでだ

JavaのAPIというか一回書いたら半永久的に治せないインターフェースを書いてるわけでもないだろ
あるいは大企業の連中が使ってるイミフなフレームワークか

そんなん言っても満足されないならこのくらい

・社員が子会社に転籍とかフツーにあり得るなら「社員」に持たす、全グループ間で同一のアプリ使ってる前提だが
部署だと会社跨いだら引けなくなる設計になってる可能性もあるんでな
・一社だけなら部署でも社員でもノリで決めていい（多分直せるはずだ）

01461452017/04/14(金) 01:15:51.93 ID:DK6sdjwT

とりあえず目的が「特定の社員の所属状況を引く（あるいは特定社員の在籍履歴を引きたくなって機能追加）」なら
社員に持たすだろうかな
個人のトラッキングが目的なら個人を扱うクラスが責任取るべき

部署に持たすってなら「今日の部署の人員配置状況がわかること」が目的ってことになるんで

0147デフォルトの名無しさん2017/04/14(金) 01:21:47.69 ID:5G8BkNCQ

>>145
Java関係ないやん

0148デフォルトの名無しさん2017/04/14(金) 01:36:29.65 ID:DK6sdjwT

>>147
interfaceがうるさい連中の筆頭はJavaっ子なんでなあ
パっと思いついたのがアレだった

ンなんだったらJSRにvar変数提案しろよとも思うのだが（あるいはScalaっぽくするか）

01491482017/04/14(金) 01:36:57.02 ID:DK6sdjwT

varがあればダックタイピングもできるだろうしな

0150デフォルトの名無しさん2017/04/14(金) 03:32:44.79 ID:DK6sdjwT

もう寝るか

Java8のlambdaなんとかならんもんかねぇ
スレッドのラッパーってのは期待してなかった（高階関数と、関数テーブル用途が使えん）
ドロイド君のイベントに差し込むのには使えようが

0151デフォルトの名無しさん2017/04/14(金) 07:12:34.16 ID:n5pL5Dn8

意外とどちらでも良いんですね

モデリング的に部署に聞くのはあり得ないとか言われると思ったのですが

ただ、社員にも部署にも問い合わせ可能なのが好ましいというのは驚きでした　冗長と言われそうで考えになかったもので　参考になります

0152デフォルトの名無しさん2017/04/14(金) 07:31:08.07 ID:dq/wP8H9

「現実世界」なんて忘れて

0153デフォルトの名無しさん2017/04/14(金) 09:07:05.40 ID:aK3T4zVf

>>150
はい？

0154デフォルトの名無しさん2017/04/14(金) 21:02:07.32 ID:KZAGQEdK

クラス構造に凝っても意味ないじゃん

0155デフォルトの名無しさん2017/04/14(金) 23:49:30.63 ID:Sw6Rs9Qs

そろそろjavaは遺物扱いで良いんじゃないかって思ってる

0156デフォルトの名無しさん2017/04/14(金) 23:57:33.02 ID:2Ku103cF

Cobolですら現役なのに

JavaをオワコンにしようとしてるやつはJavaの何が気に入らんのだ

0157デフォルトの名無しさん2017/04/15(土) 00:00:58.14 ID:PX53Hw9S

うまく作れないことを言語のせいにしたいだけだと思ってる

0158デフォルトの名無しさん2017/04/15(土) 00:03:32.65 ID:0ry10bQQ

その通りやで

0159デフォルトの名無しさん2017/04/15(土) 00:06:46.85 ID:0ry10bQQ

ところでそろそろjavaにも型推論追加された？

0160デフォルトの名無しさん2017/04/15(土) 00:14:08.96 ID:b29XQl7t

されねーしいらねーし

0161デフォルトの名無しさん2017/04/15(土) 00:24:58.93 ID:PX53Hw9S

javaスレでどうぞ

0162デフォルトの名無しさん2017/04/15(土) 00:28:17.04 ID:0ry10bQQ

じゃあ何の話するの？

0163デフォルトの名無しさん2017/04/15(土) 00:32:30.38 ID:PX53Hw9S

何もなけりゃ何も話さなくていいんだよ

0164デフォルトの名無しさん2017/04/15(土) 00:37:51.34 ID:uwyLFIA1

好き嫌いだよ好き嫌い
それでいいよ

0165デフォルトの名無しさん2017/04/15(土) 09:43:01.13 ID:01wvAL9A

>>134
でも分岐数4Kって訳でもないんだろ？
それ2048の関数があるのと変わらない

0166デフォルトの名無しさん2017/04/16(日) 02:05:28.12 ID:IBph2Vsu

>>156
Javaはもともと組み込み言語だったんで、真剣にやると
他言語ではできることがJavaではできないってことがよくある

手数かけりゃそりゃいくらでもできるが、要求が出たら今日リリースできて当然の
職場だと厳しいよ

01671662017/04/16(日) 02:23:40.59 ID:IBph2Vsu

Struts1 + Hibernate固定とか、Spring + Hibernate固定の現場で、
お客さんからハナシ聞いて1～2週間後に納品、みたいなのが許されるならJavaでも構わないと思う
まあアレだ「エラーが絶対に出ないこと」ならJavaのほうが有利なのは認めるんで

エラーが多少出てもいいから最速で「だいたい」動くものが必要だって働き方だとJavaキツい

0168デフォルトの名無しさん2017/04/16(日) 02:41:47.00 ID:cCOM2/u0

>.166
組み込み言語だったことが理由で
他の言語で出来てJavaで出来ないことって何？

0169デフォルトの名無しさん2017/04/16(日) 02:42:52.99 ID:cCOM2/u0

>>167
エラーが多少出てもいいの
「多少」ってどのくらい？

0170デフォルトの名無しさん2017/04/16(日) 05:04:51.94 ID:IBph2Vsu

>>168
lispあるいはrubyのlambaか、groovyかscalaのクロージャ
pythonのは不完全だ
mixinとかについてはもうどうでもいいや

>>169
時間的な意味で言うと、半年～1年くらいでバグレポが電話で届くくらい
社内におったてたReadmineに「今日なんか動きません >_<」って事務員のおぜうさまからご連絡があるとか、その辺

0171デフォルトの名無しさん2017/04/16(日) 09:40:21.87 ID:0mT+BZRD

オブジェクト指向と言ったらjavaがメジャーだしjavaが出来れば良いと思う

C++メインでオブジェクト指向できるという人は構造化プログラマが多い気がするから業務システムでの採用は避けたい

C#は隠れVB野郎が擬態してる可能性が高いから根本的に避けたい

Rubyは俺が知らないw

0172デフォルトの名無しさん2017/04/16(日) 09:44:29.62 ID:0mT+BZRD

VB.NETでオブジェクト指向してる人間って2割居ないんじゃ無いかと思う
構造化プログラムしてるのが5割で、残りは非構造化プログラムってイメージ

0173デフォルトの名無しさん2017/04/16(日) 10:02:40.78 ID:3arFtvKs

cobolerやVBerがjavaやったらやっぱり同じだよ

0174デフォルトの名無しさん2017/04/16(日) 10:24:00.81 ID:pKwaze4n

>>171
C#erがVB程度しか使いこなせて無いかどうかは、Linq使いこなせるかどうかで大体判別可能。

0175デフォルトの名無しさん2017/04/16(日) 10:44:52.25 ID:deLvCvQZ

JavaとかRubyは純粋指向の人が多いような気がする

0176デフォルトの名無しさん2017/04/16(日) 13:37:47.43 ID:P5/zt8YK

純粋でメリットがあるのって、開発環境的なツールだけだよな。
人間にとっては、そのツールの恩恵を受けられる事に多大なメリットがあるけど、言語自体に直接的なメリットを感じないわ。

0177デフォルトの名無しさん2017/04/17(月) 09:26:03.38 ID:ZPW6EaCZ

>>171
レッテルでdisってるだけという

0178デフォルトの名無しさん2017/04/17(月) 09:29:54.87 ID:ZPW6EaCZ

てかC#の売りは、あのXMLでフォームを作れる点じゃないのかね。
泥のアプリに感覚が近い。
フレームワークなんだろうが、あれなしでC#を使うとは思えず、凝ったことはAPIやCOMを自分で使わないといけないような。
だから、業務系システムでC#はわかる。

0179デフォルトの名無しさん2017/04/17(月) 09:46:57.33 ID:NmJeD+FV

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

0180デフォルトの名無しさん2017/04/17(月) 09:53:49.97 ID:avieXFWj

>>178
はい？

0181デフォルトの名無しさん2017/04/17(月) 21:36:17.70 ID:kf1yWIvT

コーヒーを飲むって動作は誰にさせると上手くいきますか？

コーヒーを飲む人？
コーヒーが飲ませる機能を持っている？
コーヒーを飲む人でないメイドさんか誰かが飲ませてくれる？

0182デフォルトの名無しさん2017/04/17(月) 21:47:08.34 ID:viGpNXOw

２つの物体の相互作用をどちらかを主語にしないと記述できない時点で
今主流のオブジェクト志向はクソ

0183デフォルトの名無しさん2017/04/17(月) 21:49:52.39 ID:avieXFWj

石原さとみのおっぱいに垂らした温いコーヒーをナメるのがベスト

0184デフォルトの名無しさん2017/04/17(月) 21:56:46.03 ID:LB/3uUQe

>>181
> コーヒーを飲むって動作は誰にさせると上手くいきますか？
メソッド＝動詞を実行できる人

>>182
2つの物体の相互作用は、それぞれの物体の作用に分解できる

0185デフォルトの名無しさん2017/04/17(月) 22:04:31.38 ID:D9tI2U/v

>>183
それを設計するとナメるという行為と石原さとみのおっぱいのたゆみ、それによるコーヒーの流れ、流れに応じた舌の移動、さらに石原さとみの悶えという不確定要素など複数のオブジェクト間のフィードバックループを形成しないといけない
現実をプログラムにするというのは非常に難しいものだ

0186デフォルトの名無しさん2017/04/17(月) 22:16:18.42 ID:VvYNlkfx

オブジェクトはメソッド実行するときはたいてい目的語
でもたまに、処理を移譲するよなときは主語になる

一定してないから混乱の原因
自信ついたあたりで現実のモデリングをしようとすると面食らう

0187デフォルトの名無しさん2017/04/17(月) 22:26:26.94 ID:n/MHuOf5

だいぶ前にこの類いのスレ立ててる奴が
「コーヒー」クラスが「ドリンク」メソッドで「プログラマー」に代入されてるジョークTシャツ持ってきて
「だからオブジェクト指向は～」ってやってたのの本人による再放送でしょ。
キャットドア誰も相手してくれなくなったから。

0188デフォルトの名無しさん2017/04/17(月) 23:55:38.00 ID:a8QARk7l

メソッドは状態が変化する物に帰属させないとオブジェクト志向の意味ないよね

0189デフォルトの名無しさん2017/04/18(火) 00:38:27.27 ID:ibb6Zkrz

>>188
そんなことはないよ。

0190デフォルトの名無しさん2017/04/18(火) 07:13:33.23 ID:YLExNRL3

去年.NET3.5の新規開発で
VB9.0を選択しちゃうウチの職場は
未だにオブジェクト指向を導入していません

そろそろオブジェクト指向開発を調査した方がいいでしょうか

0191デフォルトの名無しさん2017/04/18(火) 09:09:55.12 ID:+QApwmMZ

その程度の仕事しかしてないということなので不要です

0192デフォルトの名無しさん2017/04/18(火) 09:59:29.58 ID:QQU8yDeJ

キャットドア問題も解決できないオブジェクト指向は不要

0193デフォルトの名無しさん2017/04/18(火) 12:33:10.21 ID:7gPK71Iv

NGワード：キャットドア
これでスッキリ

0194デフォルトの名無しさん2017/04/18(火) 13:42:04.65 ID:dT36T5gx

キャットドア厨はオブジェクト指向以外で問題解決してみてから言えよ
これやらないからカスなんだよ

0195デフォルトの名無しさん2017/04/18(火) 17:45:27.51 ID:QQU8yDeJ

>>194
オブジェクト指向以外に解決策を求めてる時点で草ｗｗｗｗｗｗ

0196デフォルトの名無しさん2017/04/18(火) 17:58:40.72 ID:ymBV4AxE

cat.open(door), cat.open_door()
person.drink(cofee)

0197デフォルトの名無しさん2017/04/18(火) 20:10:28.20 ID:PoabM2Bb

何通りか解決してただろ
なんでリセットされてるんだよ

0198デフォルトの名無しさん2017/04/18(火) 20:35:48.45 ID:MNbxM32c

>>197
悪魔の証明と化してる

0199デフォルトの名無しさん2017/04/18(火) 21:39:51.91 ID:2/KqF/My

>>192
朗報だ
キャットドア問題をオブジェクト指向で完全に解決した
https://paiza.io/projects/9D_RVq0fdaUXDugXFTpp2g

0200デフォルトの名無しさん2017/04/18(火) 21:40:24.96 ID:2/KqF/My

オブジェクト指向のおかげです

0201デフォルトの名無しさん2017/04/18(火) 21:41:20.30 ID:2/KqF/My

オブジェクト指向完全に理解した、超簡単だった

0202デフォルトの名無しさん2017/04/18(火) 22:37:17.80 ID:PoabM2Bb

人間だけ中身からっぽでわろｗ

0203デフォルトの名無しさん2017/04/19(水) 00:25:57.42 ID:iVTtZEtx

恣意的な

0204デフォルトの名無しさん2017/04/19(水) 10:30:31.20 ID:kYerY5of

>>189
カプセル化しないの？

0205デフォルトの名無しさん2017/04/19(水) 11:36:32.83 ID:ZFpUIjRr

>>199
n種類の操作主体がいて、m種類の操作対象があるとき、DoorOpener的なクラスをm個作り、それぞれにnこのメソッドを作るのか？
操作主体が一つ増えると、既存のm個のクラスにそれぞれ一つのメソッドを追加する必要がある
また、操作対象が一つ増えると、あらたにn個のメソッドを作成する必要がある

0206デフォルトの名無しさん2017/04/19(水) 12:10:38.64 ID:rIlDsUIc

>>205
ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな

0207デフォルトの名無しさん2017/04/19(水) 12:15:05.34 ID:rIlDsUIc

>>204
カプセル化は頭空っぽの木偶の坊のためにある
オブジェクト指向の本質とは程遠い

0208デフォルトの名無しさん2017/04/19(水) 12:20:37.70 ID:rIlDsUIc

継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向

0209デフォルトの名無しさん2017/04/19(水) 12:29:42.19 ID:xWugx3VW

複数性が重要事項

0210デフォルトの名無しさん2017/04/19(水) 12:32:00.02 ID:rIlDsUIc

文字コードを相互に変換するときいったんウニコードに変換するように、対象や主体をそれぞれ抽象化オブジェクトに変換すればよいのかもね

対象と主体の操作は抽象化オブジェクトに対して行うようにしておけば、対象や主体が増えたとしても抽象化オブジェクトへの変換だけ実装すればよい

0211デフォルトの名無しさん2017/04/19(水) 12:55:20.19 ID:rIlDsUIc

抽象化オブジェクトに変換を行うトランスフォーマクラスと抽象化オブジェクトに対する操作を行うプロセッサクラスがある

具象オブジェクトが追加されたときはトランスフォーマとプロセッサを変える必要がある

見通しはいいかもわからんね、抽象化オブジェクトの関係は一箇所に集約されるから

0212デフォルトの名無しさん2017/04/19(水) 12:55:21.77 ID:cvkGewar

pコードみたいだな

0213デフォルトの名無しさん2017/04/19(水) 12:56:19.07 ID:rIlDsUIc

やっぱオブジェクト指向最高だな

0214デフォルトの名無しさん2017/04/19(水) 13:42:18.93 ID:Rk+PkBJv

>>207
木偶の坊が何か実装するときに何も考えさせないためにカプセル化するんだと思ってたわ

0215デフォルトの名無しさん2017/04/19(水) 13:49:21.08 ID:ZFpUIjRr

>>206
> ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな
まあ、あのコードが最小限だとして、その範囲ですらOCPに違反してるんじゃないですかねって指摘なんだが。

0216デフォルトの名無しさん2017/04/19(水) 19:01:16.59 ID:rIlDsUIc

>>215
ocpは耄碌したメイヤおじさんの考えだろ
オブジェクト指向がブラッシュアップされる前の
無駄の塊だった頃の話だ

最新のオブジェクト指向では継承もカプセル化も
害悪でしかないことがわかってる

0217デフォルトの名無しさん2017/04/19(水) 19:03:57.03 ID:rIlDsUIc

>>214
オブジェクト指向が浸透するまでは有益だったかもしれないが、今や誰もがオブジェクト指向を熟知し使いこなす時代、カプセル化はロジックを不鮮明にするノイズでしかない

0218デフォルトの名無しさん2017/04/19(水) 19:06:43.59 ID:rIlDsUIc

メイヤおじさんは実装の継承を推奨する老害だからな
バージョン管理ソフト使えよと

0219デフォルトの名無しさん2017/04/19(水) 19:09:12.02 ID:rIlDsUIc

プレインクラスこそオブジェクト指向の本質

0220デフォルトの名無しさん2017/04/19(水) 19:29:36.25 ID:/l6NHl5b

>>217
不鮮明となるのであればそれは用件が曖昧であるためカプセル化できてないと俺は考える
エンジンの仕組みを知らなくてもアクセルを踏めば車は動くようにわざわざ考える必要もない事は隠蔽しちゃおうぜ！ってのがカプセル化だと思ってる

まぁ解釈はそれぞれだから合わせてもらわなくていいけどね

0221デフォルトの名無しさん2017/04/19(水) 19:35:54.11 ID:XuQTPPrh

フスマと回転扉で同じキャットドアで済むわけないじゃん
これを違うものとして組めないコードは問題

結局、キャットドアなんだよ

0222デフォルトの名無しさん2017/04/19(水) 19:37:09.40 ID:rIlDsUIc

>>220
それもそうだな

0223デフォルトの名無しさん2017/04/19(水) 19:39:26.07 ID:rIlDsUIc

>>221
ドアクラスの変数名をふすまにすればいと思うの
難しく考えずにシンプルな解決策を探そうよ

0224デフォルトの名無しさん2017/04/19(水) 19:45:45.55 ID:d/SqmCf2

>カプセル化はロジックを不鮮明にするノイズでしかない
寝言にもほどがある

中が丸見えで依存しまくってたら
何かするたびに処理の全体追わなきゃいけなくなるだろうが

0225デフォルトの名無しさん2017/04/19(水) 19:52:16.42 ID:XuQTPPrh

>>223
フスマと回転扉で同じキャットドアが使えると思ってらっしゃる?

0226デフォルトの名無しさん2017/04/19(水) 19:56:33.37 ID:qJxXjZRc

>>224
ほんとこれ

カプセル化のおかげでどこにバグがあるかもはっきりする

0227デフォルトの名無しさん2017/04/19(水) 20:00:55.07 ID:qOdNs+TP

>>225
はい

0228デフォルトの名無しさん2017/04/19(水) 20:01:49.80 ID:qOdNs+TP

>>224
依存しないように実装すれば良いが

0229デフォルトの名無しさん2017/04/19(水) 20:02:59.08 ID:qOdNs+TP

>>226
んなアホな、それは言い過ぎだわ
話盛ってるわ

0230デフォルトの名無しさん2017/04/19(水) 20:05:24.07 ID:d/SqmCf2

>>228
間違ってしちゃうかもしれないし、どっかで誰かがしちゃってるかもしれんだろ

0231デフォルトの名無しさん2017/04/19(水) 20:07:46.83 ID:d/SqmCf2

あまりにもオブジェクト指向が当たり前になりすぎて、それがもたらしてくれるものを忘れてるだけだ

Cに++なんてついてなかった時代
配列を関数に渡すとき一緒に配列の長さを引数で渡してた
地獄のような時代があったんだぞ…

0232デフォルトの名無しさん2017/04/19(水) 20:11:22.44 ID:/l6NHl5b

>>229
言い過ぎじゃない
カプセル化の意図は隠蔽と独立

ガス欠で動かなくなった車に対してタイヤ交換はしなくていい
問題を切り分けて問題解決の速度を向上させるためにカプセル化はとても有効

0233デフォルトの名無しさん2017/04/19(水) 20:23:32.33 ID:XuQTPPrh

>>227
ちょっと絵に描いてみなよ

0234デフォルトの名無しさん2017/04/19(水) 20:26:00.72 ID:3xQf6WAc

『"このパーツの動作は保障されている"がないとプログラムは工業製品にならない』
ってのが始まりだしね。

ある意味「企業向けオーダーメードプログラムを手作業で人月かけてやるのが
職業プログラマって仕事なんだよっ！！」って請負業者がプログラマ名乗って
コンシュマーに売る工業製品としてのアプリケーションプログラム販売が傍流みたいになってる日本じゃ
「動きゃいい」が蔓延するのもしかたがないこと

0235デフォルトの名無しさん2017/04/19(水) 20:33:37.46 ID:lCKuRFX1

>>233
UMLでこの図なんていうんだっけ、名前は忘れたけどきちんと設計できる
オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net->画像>6枚

0236デフォルトの名無しさん2017/04/19(水) 20:34:11.59 ID:lCKuRFX1

端末変えたからID変わってるから

0237デフォルトの名無しさん2017/04/19(水) 20:35:16.70 ID:lCKuRFX1

>>232
それただのたとえ話じゃん
バグが寸分の狂いもなく立ちどころにわかるってのは言い過ぎだよ

0238デフォルトの名無しさん2017/04/19(水) 20:36:51.30 ID:lCKuRFX1

>>231
構造体に配列の長さと配列をセットで持たせればいいのに

0239デフォルトの名無しさん2017/04/19(水) 20:37:47.92 ID:/l6NHl5b

>>237
それは設計不足

0240デフォルトの名無しさん2017/04/19(水) 20:41:15.47 ID:lCKuRFX1

>>239
カプセル化に夢見すぎだよ
バグってる場所が3秒でわかるとか大嘘もいいところだよ
絶対嘘だね、どんなバグかもわかんないしさ

0241デフォルトの名無しさん2017/04/19(水) 20:41:33.40 ID:oz+MR2rn

まぁまぁ　ロジックの中が見えてバグがどこで発生しているかもすぐに分かる純粋関数が最強ってことで

0242デフォルトの名無しさん2017/04/19(水) 20:42:40.87 ID:lCKuRFX1

カプセル・スリー・セカンド

0243デフォルトの名無しさん2017/04/19(水) 20:44:01.82 ID:/l6NHl5b

>>240
誰が三秒って言ったのよ
速度向上と言ったまでさ

繰り返しになるけど所詮価値観の違いなので合わせてもらわなくていい

0244デフォルトの名無しさん2017/04/19(水) 20:46:48.18 ID:lCKuRFX1

>>243
速度向上ならわかるけど

0245デフォルトの名無しさん2017/04/19(水) 20:49:45.97 ID:lCKuRFX1

>>241
純粋関数ってメソッドの中でも再代入を許さないんだっけ？
それって遅くない？　モナド使わないと現実的に厳しくない？
すべてがモナドになればよくない？　そうしてできたのがC言語です

0246デフォルトの名無しさん2017/04/19(水) 20:58:24.07 ID:oz+MR2rn

>>245
そして構造化プログラミング、モジュールプログラミング、オブジェクト指向のカプセル化と来て
関数型に戻るわけですな

0247デフォルトの名無しさん2017/04/19(水) 21:02:34.85 ID:lCKuRFX1

>>246
極端なところに正解はないと思うんだよ
バランスが取れているのが現実的に最も優れている
カプセル化してないオブジェクト指向が最高ってことになるのかな？とどのつまり

0248デフォルトの名無しさん2017/04/19(水) 21:08:35.02 ID:d/SqmCf2

ちょっとは人の話きけりょ

0249デフォルトの名無しさん2017/04/19(水) 21:10:34.01 ID:oz+MR2rn

カプセル化してないオブジェクト指向のメンバーなんて
読みにくいグローバル変数みたいなもんじゃない？

0250デフォルトの名無しさん2017/04/19(水) 21:18:19.43 ID:lCKuRFX1

>>248
聞く、どうぞお話どうぞ

0251デフォルトの名無しさん2017/04/19(水) 21:20:38.66 ID:lCKuRFX1

>>249
グローバル変数とは全然違う
フィールドはオブジェクトに属しています
オブジェクトがなければありません
オブジェクトを作って初めて使うことができます
オブジェクトのライフサイクルと運命をともにするからこそ
オブジェクト指向なんです
finalをつけるのがデフォ

0252デフォルトの名無しさん2017/04/19(水) 21:41:01.53 ID:/l6NHl5b

>>247
極端だろうが何だろうが正解なんかないさ
おまえはおまえの思いでやればいい

すべてを同じ枠に押し込めようとして八方塞がりにならないよう気をつけなよ

0253デフォルトの名無しさん2017/04/19(水) 21:56:25.91 ID:lCKuRFX1

>>252
俺が俺の思いでやるのは当たり前のことだと思うんだよ
雨が降ったら傘をさせばいいと言ってるようなもの
当たり前じゃん？いう意味なくない？
プールで泳ぐときは服を脱げばいいみたいな
出かけるときは靴を履けばいいみたいな
価値観の違いにこだわってるのはそっちのほうなんじゃないかなって思いました

0254デフォルトの名無しさん2017/04/19(水) 21:59:29.16 ID:lCKuRFX1

カプセル化しないオブジェクト指向がモダンで優れた設計っていうのは
>>252と俺の共通認識としてあるわけだから、その上で思いを語っていただけたら

0255デフォルトの名無しさん2017/04/19(水) 22:03:04.69 ID:/l6NHl5b

>>254
俺はカプセル化推奨だぞ

0256デフォルトの名無しさん2017/04/19(水) 22:06:05.25 ID:lCKuRFX1

>>255
フィールドが全部finalだったらprivateなんて必要ないだろ？
つまり、カプセル化って必要なくない？

0257デフォルトの名無しさん2017/04/19(水) 22:07:41.10 ID:lCKuRFX1

隠すメリットより公開するメリットの方が莫大だと思わない？

0258デフォルトの名無しさん2017/04/19(水) 22:18:28.62 ID:lCKuRFX1

公開するメリット隠すデメリットを考えよう

0259デフォルトの名無しさん2017/04/19(水) 22:22:01.02 ID:/l6NHl5b

思わないなぁ
カプセル化って無駄を省いてわかりやすいものにして再利用しやすいよう作ることと思ってるからね

そもそもカプセル化はフィールドだけじゃない
インターフェースを用いて処理を委譲させるように設計してしまえばデータだけじゃなく処理を丸ごと隠蔽できるしオブジェクト間の依存関係も稀薄にできる

0260デフォルトの名無しさん2017/04/19(水) 22:26:31.08 ID:lCKuRFX1

>>259
なるほどね、それはあるね

0261デフォルトの名無しさん2017/04/19(水) 22:27:13.48 ID:lCKuRFX1

カプセル化完全に理解した

0262デフォルトの名無しさん2017/04/19(水) 22:34:52.50 ID:/l6NHl5b

おめでとう
まぁ俺はまだまだ勉強中だからうらやましいよ

0263デフォルトの名無しさん2017/04/19(水) 23:01:17.77 ID:KzpInSVx

>>256
通りすがりだが、年齢フィールドとか一定の幅に制限したい時に勝手に300歳とか設定されたら困るだろう。
だからprivateにしてメソッドやプロパティで0-120なりの範囲に制限するようにするんじゃないの？

0264デフォルトの名無しさん2017/04/19(水) 23:08:00.65 ID:qOdNs+TP

>>263
入力チェックをデータがやっていいものか
これは議論が別れるところですよ

0265デフォルトの名無しさん2017/04/19(水) 23:10:42.57 ID:2dTlCsss

>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……？

0266デフォルトの名無しさん2017/04/19(水) 23:12:01.85 ID:qOdNs+TP

>>265
代数的データ型とはなんぞや？

0267デフォルトの名無しさん2017/04/19(水) 23:13:00.35 ID:HSKBgTxb

「300歳なんてあるわけないからカチカチに型で数字の範囲を絞ればいいんだよ」
「300歳なんて異常な数字を送らないように送り手が責任を持つべきだ」
「300歳が送られてきても"数字がおかしい"って返事するようにすれば良くね」

どれがいいと思うかで、その人のそもそものスタンスとセンスがわかるな。

0268デフォルトの名無しさん2017/04/19(水) 23:16:21.53 ID:qOdNs+TP

>>267
俺ならチェックせずに文字列のフィールドにそのままセットしちゃうね、純粋オブジェクト指向

0269デフォルトの名無しさん2017/04/19(水) 23:19:37.80 ID:qOdNs+TP

type c = a or b
みたいな？

0270デフォルトの名無しさん2017/04/19(水) 23:20:37.20 ID:qOdNs+TP

これもオブジェクト指向と言ってもいいでしょう！

0271デフォルトの名無しさん2017/04/19(水) 23:21:42.97 ID:HSKBgTxb

ちなみに最後のがいちばんオブジェクト指向っぽくて
大きな仕様変更に強いゆるさがあると思うけど
カチカチが好きなタイプのプログラマーは"ゆるさ"の部分が
許せないのだろうな。

0272デフォルトの名無しさん2017/04/19(水) 23:23:56.87 ID:KzpInSVx

>>264
え、でもそうでもなきゃ、データの外部でデータチェックとかは関数型言語や構造化プログラミング的な発想だけど。
副作用あるのに、その発想は危険過ぎない？
他の誰かがその外部のチェック用クラスを使ってくれる保証は無いよ？

0273デフォルトの名無しさん2017/04/19(水) 23:30:11.23 ID:qOdNs+TP

>>272
必要なら必要になったとき必要な人が自分で作れば良いじゃん、自由と自己責任の精神だよ、ルールで縛られたガチガチのオブジェクトじゃままならぬ事もあるでしょう！

0274デフォルトの名無しさん2017/04/19(水) 23:33:14.31 ID:KzpInSVx

>>267
オブジェクトが各々責任を持つとするなら、それぞれのクラスでデータチェック(ダブルチェック)が正解なんだろうね。
じゃないと、その二つのクラスは二つで一つになる。
依存関係が出来てしまう。
違うクラスでも、年齢に関するデータなら受け取れるようにした方がいいんじゃ無いかな。

実際には依存関係呑み込んでどっちかしかチェックしないってのが多そうだが。

0275デフォルトの名無しさん2017/04/19(水) 23:34:21.76 ID:HSKBgTxb

"誰がその数値に責任を持ってるか"っしょ。
それを明確にできてればそこを修正すればいいけれど
「私は知らない」「私は受け付けない」「私の責任ではない」って
例外の責任が見えないと責任者探しから始めなくちゃいけなくて
後から来たプログラマが死ぬ。

0276デフォルトの名無しさん2017/04/19(水) 23:37:47.94 ID:KzpInSVx

。。。オブジェクト指向は事なかれ文化の日本と相性悪いんじゃ無いかと思えてくる文言ダネ＾＾;

0277デフォルトの名無しさん2017/04/19(水) 23:39:15.89 ID:qOdNs+TP

テストすれば良いじゃん

0278デフォルトの名無しさん2017/04/19(水) 23:41:15.55 ID:qOdNs+TP

ちゃんとオブジェクトが連携できてるかなって
そうだよ僕たちには結合テストがあるじゃないか

0279デフォルトの名無しさん2017/04/19(水) 23:46:37.27 ID:qOdNs+TP

値を変換するコンバータクラスと値をチェックするバリデータクラスがあれば良いじゃないか
責務の分離だよ

0280デフォルトの名無しさん2017/04/19(水) 23:48:34.03 ID:qOdNs+TP

データ保持するクラスがチェックまでやるのは複雑すぎるよ、素直じゃない

0281デフォルトの名無しさん2017/04/19(水) 23:51:12.30 ID:qOdNs+TP

オブジェクトも大事だがコラボレーションも大事

0282デフォルトの名無しさん2017/04/19(水) 23:52:23.70 ID:zPBwEPLo

連投せずにまずは落ち着くのが大事

0283デフォルトの名無しさん2017/04/19(水) 23:57:15.78 ID:/l6NHl5b

目的の動きを満たせばだいたい正解なんだから熱くなるなよ
自分の意見を押し通したいのはわからんでもないがな

0284デフォルトの名無しさん2017/04/20(木) 00:29:25.65 ID:jJkbXdni

208 デフォルトの名無しさん[sage] 2017/04/19(水) 12:20:37.70 ID:rIlDsUIc

継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向

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

これもオブジェクト指向と言ってもいいでしょう！

こんなん草生える

0285デフォルトの名無しさん2017/04/20(木) 07:19:48.83 ID:JH3XDWGN

チェックも色々とデータが必要なとき多いしな

0286デフォルトの名無しさん2017/04/20(木) 11:36:45.75 ID:vlFc/PD3

>>216
> 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の五大原則のひとつとしてあげられるのが普通。

> 最新のオブジェクト指向では継承もカプセル化も
> 害悪でしかないことがわかってる
そうなんだ、それは知らなかったよ。

0287デフォルトの名無しさん2017/04/20(木) 14:18:44.61 ID:Wfe8Hvf2

継承は特定の親に縛られすぎるのであまりよくないね。ってなってるが
カプセル化はむしろ危険な直接アクセスを防ぐ意味で常識になってる気が。

0288デフォルトの名無しさん2017/04/20(木) 20:00:36.90 ID:OWrdGWgc

やっぱりインターフェースこそオブジェクト指向だよな

0289デフォルトの名無しさん2017/04/20(木) 20:17:41.83 ID:JH3XDWGN

>>287
でもカプセル化って汎用性悪いじゃん
変数１つアクセスできないだけで実現したいことできなくなっちゃうかもよ?

0290デフォルトの名無しさん2017/04/20(木) 20:22:03.18 ID:jeWo4Dft

それもうわざわざクラス使わずに構造体使っちゃいなよ

0291デフォルトの名無しさん2017/04/20(木) 20:29:03.08 ID:nHxDShTL

悪い依存関係はそのコードの利用者にコピベプログラムを強いる
これ経験則な

0292デフォルトの名無しさん2017/04/20(木) 20:37:59.47 ID:x1mUV01b

汎用性ならインターフェースと抽象クラスじゃねーの？

0293デフォルトの名無しさん2017/04/20(木) 21:21:03.65 ID:1ly+xIep

>>286

> 最新のオブジェクト指向では継承もカプセル化も
> 害悪でしかないことがわかってる

まーたくだらない嘘をつく
すぐにバレるのわかってるだろｗ

害悪でしかないならば、lintなどのツールで使うなって警告が出るはずだ。
そういったlintツールがない（継承やカプセル化を使った時にエラーにする方法がない）
もとから、害悪でしかないっていうのは完全に間違いだ。

反論があるならどうぞ

0294デフォルトの名無しさん2017/04/20(木) 21:40:16.04 ID:NBs+Bll8

>>289
それ汎用性ちゃうで。
そんな内部実装の細かいとこ勝手に使われたら、バグ修正すらなんの影響があるか怖くてできんくなる。
結局特定用途にしか使えなくなる。

0295デフォルトの名無しさん2017/04/20(木) 21:44:56.84 ID:1ly+xIep

結局、privateっていうのは、

この変数は外部から直接触ることを想定していません。
決められた値以外を入れた時の保証はしませんし、
将来の変更で互換性がない形に変更する必要がありますので
参照しないでください

とコメントで書くわかりに、コンピュータでも理解できる
言語で書くってだけの話なんだよね。

0296デフォルトの名無しさん2017/04/20(木) 21:46:00.98 ID:1ly+xIep

あ、もちろんprivateを使ったほうが良いって話だよ。

コメントで長々書いても読まないし、
ソースを見ないかもしれない。

そういう時にコンピュータでも理解できる言語で書いていれば
コンパイル時にしっかりチェックしてくれる。間違いがない。

0297デフォルトの名無しさん2017/04/20(木) 21:47:30.56 ID:JH3XDWGN

>>294
クラスなんて使わなければいいのでは?

0298デフォルトの名無しさん2017/04/20(木) 21:53:58.83 ID:Rk6y34sG

>>293
帰納的な推理は往々にして間違うものなんだよ

0299デフォルトの名無しさん2017/04/20(木) 21:55:36.70 ID:1ly+xIep

>298
ちょっと邪魔しないで、

反論が出てくるかどうか待っている所だからｗ

0300デフォルトの名無しさん2017/04/20(木) 21:56:45.24 ID:Rk6y34sG

マンコが本当にあるなら俺のチンコが純粋であることの説明がつかないみたいな

0301デフォルトの名無しさん2017/04/20(木) 21:57:23.53 ID:x1mUV01b

>>299
反論がでない＝正当性が証明された
などと言うつもりかい？

0302デフォルトの名無しさん2017/04/20(木) 21:58:02.87 ID:Rk6y34sG

純粋チンコ型論理

0303デフォルトの名無しさん2017/04/20(木) 22:03:33.81 ID:Rk6y34sG

>>297
クラスわ使わないでどうやってデータを管理する？
配列か？

0304デフォルトの名無しさん2017/04/20(木) 22:07:49.44 ID:OWrdGWgc

カプセル化は正しい方向性だというのは賛成だが
lintで警告が出ないからという権威主義的な根拠はどうなのか

0305デフォルトの名無しさん2017/04/20(木) 22:10:46.32 ID:Rk6y34sG

>>290
構造体を使うとしてその構造体に連関する関数をどうやって整理する？

構造体ごとにファイルを分けるのは面倒だし、認知行動学的に考えて厳しくない？

整理することこそプログラミング、そのコストが低い言語が良い言語だと思うんだよね

0306デフォルトの名無しさん2017/04/20(木) 22:12:10.00 ID:NBs+Bll8

>>297
せやな。
必要性がないと判断したんなら使わなければいいんじゃないか？
間違ってないと思うで。

ただまあ、構造体が必要になる所では、ほぼ間違いなくクラス化した方が使い方の見通しが良くなるで。

0307デフォルトの名無しさん2017/04/20(木) 22:12:52.70 ID:x1mUV01b

自分で考えるってことをしないんだろ

他人の定めたルールが正当である
それが目に見える形とならねば虚構である

むなしいね

0308デフォルトの名無しさん2017/04/20(木) 22:13:09.41 ID:1ly+xIep

>>301
それで何か問題あるの？

0309デフォルトの名無しさん2017/04/20(木) 22:14:14.53 ID:1ly+xIep

俺様が決めたルール（＝害悪でしかない）が正当であると思ってるんだろうねｗ

だから俺様以外が決めたルールであるかどうかを確認している。
さて反論は？

0310デフォルトの名無しさん2017/04/20(木) 22:15:28.83 ID:Rk6y34sG

俺は今ガリレオさんの気持ちだ

0311デフォルトの名無しさん2017/04/20(木) 22:17:39.49 ID:x1mUV01b

>>308
おまえが満足するならそれでかまわないよ
別に誰かに認められるために学んでるわけじゃないし

もっとも残念ながら俺はカプセル化については推奨派なので反論とかするまでもなくどーだっていい
ただおまえの発想はかわいそうだと思うだけ

0312デフォルトの名無しさん2017/04/20(木) 22:18:02.65 ID:Rk6y34sG

死に際にそれでも地球は回っていると言ってのけたガリレオさんも気持ちだ

0313デフォルトの名無しさん2017/04/20(木) 22:22:56.58 ID:1ly+xIep

>>311
そういうことは最初から言わないか？

なんで俺に「反論がでない＝正当性が証明されたなどと言うつもりかい？」と聞いた？
最初から「反論が言えなくても、正当かもしれないだろ！」と言えばいいじゃないか？

それがお前が本当に言いたいことだろ？

それならそれで俺は最初からこう答えるよ。
だから、お前が言っていることを正当だと他人に認めてもらうために、
お前は反論（信頼性があるソース）を出せって。

はい、で、信頼性があるソースは？

0314デフォルトの名無しさん2017/04/20(木) 22:24:14.04 ID:Rk6y34sG

それでもカプセル化は必要ない
lintはろくでも無いクラス設計がまかり通っていたときの負の遺産だ、javabeansやcomが盛んに作られた時代の名残だ、隠蔽して守られるより公開して守られるクラス設計を目指すべき

0315デフォルトの名無しさん2017/04/20(木) 22:25:02.69 ID:Rk6y34sG

>>313
ソースは俺

0316デフォルトの名無しさん2017/04/20(木) 22:25:24.28 ID:1ly+xIep

補足しておくと「継承やカプセル化が害悪でしかない」という仮説が
正しいという信頼性がある（俺様が決めたルールではないとう）ソースを出せ。
という話ね

0317デフォルトの名無しさん2017/04/20(木) 22:26:09.67 ID:Rk6y34sG

ソースは現代のガリレオです
よろしくお願いします

0318デフォルトの名無しさん2017/04/20(木) 22:27:09.43 ID:x1mUV01b

>>313
見識が狭すぎるのは大変だよって言いたいだけさ

繰り返しになるけど俺はカプセル化について推奨派なので反論するつもりは全くない
おまえの論調は嫌いだがな

0319デフォルトの名無しさん2017/04/20(木) 22:29:33.08 ID:1ly+xIep

>>318
それを言うなら相手が違うだろ。

見識が広いやつに対して、
お前の広さを（証拠を出すことで）示してやれ！と言うべきだ。

それが俺も言っていることなんだけどなｗ

で、信頼性があるソースはよ

0320デフォルトの名無しさん2017/04/20(木) 22:30:20.01 ID:jeWo4Dft

>>305
俺の経験上はだけど、それオブジェクト志向じゃない方がむしろやりやすいで

0321デフォルトの名無しさん2017/04/20(木) 22:30:37.36 ID:nIwh3CMn

ソースは？の問いに対して
有無以外のレスを繰り返す相手を
それ以上いじめてはいけない

0322デフォルトの名無しさん2017/04/20(木) 22:31:02.97 ID:Rk6y34sG

昔は暗号化のロジックも隠すことで安全性を担保しようとしていたけど、駄目だったんだよ、現代ではロジックを公開できる暗号化こそが真に安全性を備えていることがわかっている

それと全く同じことでいくらプライベートにしようがリフレクション使いまくる現代のプログラミングでは役に立たない、パブリックにしても問題ないように作るのが真のオブジェクト指向

0323デフォルトの名無しさん2017/04/20(木) 22:32:10.96 ID:Rk6y34sG

>>319
ソースは今お前の目の前に居る
さあ

0324デフォルトの名無しさん2017/04/20(木) 22:32:34.93 ID:x1mUV01b

>>319
そうかい
ならば俺にソースを求めることが見当違いだということにも気づいてくれ

0325デフォルトの名無しさん2017/04/20(木) 22:33:31.06 ID:Rk6y34sG

>>320
どうやるん？　クラス作らないとできなくない？

0326デフォルトの名無しさん2017/04/20(木) 22:33:55.62 ID:1ly+xIep

>>322
その理屈を使いたいならば、ロジックは公開すべきある。
共通鍵暗号方式でも公開鍵暗号方式でも、秘密鍵（データ）は隠すことで安全性を保っている。

そのことから・・・と話をするべきだ。

0327デフォルトの名無しさん2017/04/20(木) 22:35:08.71 ID:Rk6y34sG

>>324
カプセル化が必要ないことを説明しろよ

0328デフォルトの名無しさん2017/04/20(木) 22:37:17.66 ID:x1mUV01b

>>327
だからカプセル化について推奨派って言ってんじゃねーか
推奨派が必要ないと考えるわけねーだろーが

少しは考えて発言しな

0329デフォルトの名無しさん2017/04/20(木) 22:37:44.90 ID:Rk6y34sG

>>326
秘密鍵はパスワードとかそういう類の物だからそもそもプログラム内に持たないんだよ

0330デフォルトの名無しさん2017/04/20(木) 22:39:55.49 ID:1ly+xIep

>>329
プライベート変数は、ファイルに保存しろって言いたいわけ？

0331デフォルトの名無しさん2017/04/20(木) 22:41:15.19 ID:Rk6y34sG

>>330
秘密鍵はプログラムに書くものじゃないと言いたいのさ

0332デフォルトの名無しさん2017/04/20(木) 22:43:19.76 ID:1ly+xIep

>>331
だから秘密にしたいデータ（他のクラスから参照されたくないデータ）は
プログラムに入れずにファイルにしておけってことだろ？

0333デフォルトの名無しさん2017/04/20(木) 22:43:43.47 ID:Rk6y34sG

>>328
派閥でどうこう言うんじゃなくていち個人として良心から発言していただきたい、カプセル化が必要ないんだという思いと向き合うべきだと言ってるんだよ

0334デフォルトの名無しさん2017/04/20(木) 22:44:37.36 ID:T8G8upSf

こいつ相当のバカだな

0335デフォルトの名無しさん2017/04/20(木) 22:44:47.88 ID:Rk6y34sG

>>332
違う違う秘密鍵はプログラムに書くものじゃないと言ってるんだよ

0336デフォルトの名無しさん2017/04/20(木) 22:45:25.28 ID:Rk6y34sG

リピートアフターミー
秘密鍵はプログラムに書くものじゃない

0337デフォルトの名無しさん2017/04/20(木) 22:45:53.95 ID:Rk6y34sG

カプセル化はオブジェクト指向じゃない

0338デフォルトの名無しさん2017/04/20(木) 22:45:55.45 ID:1ly+xIep

>>335
じゃあ他のクラスから秘密にしたいデータは？

0339デフォルトの名無しさん2017/04/20(木) 22:47:11.97 ID:Rk6y34sG

>>338
公開しなさい

0340デフォルトの名無しさん2017/04/20(木) 22:47:42.98 ID:1ly+xIep

>>322
> 昔は暗号化のロジックも隠すことで安全性を担保しようとしていたけど、駄目だったんだよ、現代ではロジックを公開できる暗号化こそが真に安全性を備えていることがわかっている

違う違う。それは「暗号化ロジック」は公開しろって話なんだよ。

リピートアフタミー「暗号化ロジック」は公開しろ。

それ以外の話は公開しろって意味じゃない。

0341デフォルトの名無しさん2017/04/20(木) 22:48:28.32 ID:1ly+xIep

>>339
なんで？

秘密にしたいデータは、暗号化ロジックじゃないよね？
公開する理由がない。

0342デフォルトの名無しさん2017/04/20(木) 22:49:40.47 ID:Rk6y34sG

>>340
暗号化ロジックは式という形式のデータです

0343デフォルトの名無しさん2017/04/20(木) 22:49:49.13 ID:NBs+Bll8

password.txtに書いてgithubにコミットやろjk

0344デフォルトの名無しさん2017/04/20(木) 22:51:10.30 ID:1ly+xIep

>>342

暗号化ロジック = 式という形式のデータ

故に

式という形式のデータ = 暗号化ロジック

と言ってる？
それは明らかに間違いだよ。

0345デフォルトの名無しさん2017/04/20(木) 22:53:29.90 ID:1ly+xIep

式という形式のデータ、
そこにはいろんなロジックがある。
その沢山の種類のロジックの中で
暗号化ロジックだけは公開しろ

0346デフォルトの名無しさん2017/04/20(木) 22:54:17.23 ID:x1mUV01b

>>333
べき論はよくわからんが、そこまで言うなら個人として伝える

カプセル化は絶対必要である
なんならオブジェクト指向のキモだとも考える
目的に特化させ再利用できるようにデザインすること
きちんとネーミングすること
多様性を持たせるならばインターフェースを用いて処理を実装し移譲すればよい

以上

0347デフォルトの名無しさん2017/04/20(木) 22:55:25.78 ID:zhxiAG0o

ID:rIlDsUIc = ID:Rk6y34sG だよね?
昨日はシラフで今日は酔っ払っているのかな?

0348デフォルトの名無しさん2017/04/20(木) 22:56:30.20 ID:Rk6y34sG

>>343
冗談じゃなくそういうのあるらしいね
awsのなんかあれ

0349デフォルトの名無しさん2017/04/20(木) 23:07:28.95 ID:nIwh3CMn

OOPに必要かどうかしらんけど
カプセル化は単に便利だよね
スコープ的な意味で

0350デフォルトの名無しさん2017/04/20(木) 23:23:01.66 ID:16AwdhdC

横からカプセル化の話題を眺めていたが、素晴らしいカプセル化のアイデアが湧いてきた！

0351デフォルトの名無しさん2017/04/20(木) 23:29:07.88 ID:jeWo4Dft

>>325
最初はクラスの下にでも書いたらいいよ
少なくとも中に書くよりは読みやすいし
後は必要に応じて慣れやね

0352デフォルトの名無しさん2017/04/20(木) 23:49:33.09 ID:hTP3eC2C

インターフェースこそオブジェクト指向だという意見に全面的に同意。
継承自体はクラス目線でモジュール化を進めた結果で得られる構造なだけであって、
インターフェースのように型を意識させることはない。
結果的にはインターフェース+基底クラスパターンが最強だと思うわ

0353デフォルトの名無しさん2017/04/20(木) 23:59:45.86 ID:zhxiAG0o

アルゴリズムを試行錯誤している時はグローバルな構造体の方が楽。
デバッグや保守の時はカプセル化されたオブジェクトの方が楽。
これはmutableとimmutableにも同じことが言える。

カプセル化しないmutableオブジェクトの方が考えやすいなら
プロトタイプ開発ではそうすればよい。
設計が決まったらできるだけカプセル化したimmutableオブジェクトに変えよう。

0354デフォルトの名無しさん2017/04/21(金) 00:06:49.24 ID:T1EM2She

>>351
関数の名前に構造体の名前を入れるん？　面倒じゃない？

0355デフォルトの名無しさん2017/04/21(金) 00:08:09.71 ID:T1EM2She

>>353
不変のものをカプセル化する意味あるのか？
フルオープンでよくね？

0356デフォルトの名無しさん2017/04/21(金) 00:11:37.99 ID:YTf7CJ3G

>>355
不変だからこそカプセル化するんだよ

0357デフォルトの名無しさん2017/04/21(金) 00:14:32.72 ID:TFy/T03e

不変というのはコンパイル時に決まるってわけじゃないからな。
初期状態から変わらないってだけで、
初期状態というものは存在する。
当然それを隠したい場合も存在する。

0358デフォルトの名無しさん2017/04/21(金) 00:26:21.96 ID:Ck7s6rRh

>>354
そうか？俺は元々Lisperだし、全く面倒とは思わん
でももし面倒と思うんなら、特にC++とかならオーバーロードがあるんだから構造体名入れなくてもなんとかなるでしょ
この先UFCSも導入される予定みたいだし

0359デフォルトの名無しさん2017/04/21(金) 00:27:55.81 ID:1EW2mi9U

びっくりするくらい低レベルな会話しててわろた
ホリデープログラマーが語りだすとこうなる

0360デフォルトの名無しさん2017/04/21(金) 00:48:08.26 ID:T1EM2She

>>356
どうして不変だからカプセル化するんだよ？

0361デフォルトの名無しさん2017/04/21(金) 00:48:50.43 ID:T1EM2She

>>357
なぜ隠すのか？
なぜ？　どうして？

0362デフォルトの名無しさん2017/04/21(金) 00:49:23.31 ID:T1EM2She

>>358
LisperにとってJavaのクラスはどう？

0363デフォルトの名無しさん2017/04/21(金) 01:04:07.46 ID:YTf7CJ3G

自分で考えてみな

0364デフォルトの名無しさん2017/04/21(金) 01:18:33.36 ID:Ck7s6rRh

>>362
個人的には作業効率が落ちる感じがして好きじゃない
でも低産階級労働者を縛る鎖としてはいいんじゃない？

0365デフォルトの名無しさん2017/04/21(金) 01:19:22.96 ID:T1EM2She

>>363
説明できないのな、じゃあいいわ

0366デフォルトの名無しさん2017/04/21(金) 01:20:01.11 ID:T1EM2She

>>364
バイアスがすごいな
Lisperはやっぱ屑だな

0367デフォルトの名無しさん2017/04/21(金) 01:34:09.78 ID:YTf7CJ3G

>>365
聞く耳持たないヤツに対して説明できるほど理解は深くないんでね
何度も同じことを繰り返しても仕方ない

0368デフォルトの名無しさん2017/04/21(金) 01:43:34.54 ID:T1EM2She

とどのつまりカプセル化は理解できないものなんだな？

0369デフォルトの名無しさん2017/04/21(金) 02:00:31.00 ID:Ck7s6rRh

>>366
もしかして低産階級労働者だった？これは申し訳ないことを書いた。失礼

0370デフォルトの名無しさん2017/04/21(金) 02:04:34.66 ID:T1EM2She

>>369
ホントだよ！失礼極まりないよ！

0371デフォルトの名無しさん2017/04/21(金) 02:05:08.14 ID:T1EM2She

低産階級労働者は傷ついているのです

0372デフォルトの名無しさん2017/04/21(金) 02:05:31.65 ID:T1EM2She

私は被害者です

0373デフォルトの名無しさん2017/04/21(金) 02:06:19.45 ID:T1EM2She

どうしてLispにはクラスがないんだろうか
みんなで考えてみよう

0374デフォルトの名無しさん2017/04/21(金) 02:12:55.16 ID:TFy/T03e

>>373
クラスを使わないという発想で作られたから
別にいい悪いじゃなくて、ただ単にモットーの問題

0375デフォルトの名無しさん2017/04/21(金) 02:18:17.50 ID:T1EM2She

>>374
でもクラスは便利ですよ

0376デフォルトの名無しさん2017/04/21(金) 02:18:56.37 ID:T1EM2She

クラスがない、つまりカプセル化もできない？

0377デフォルトの名無しさん2017/04/21(金) 04:34:49.48 ID:H6APCPmE

手続き型言語でも定数はグローバル変数でも問題無いんだし、関数型言語の変数はほぼ定数みたいなもんだし。
カプセル化の恩恵そのものがあんまり無い希ガス。

0378デフォルトの名無しさん2017/04/21(金) 05:07:53.93 ID:rPWpf+kQ

そもそも仕様書に書くべき問題をソースなんかに記述しようとするからこうなる

なんだよカプセル化って
ガキの使いでソースに手を入れようとしてるキチガイでもサポートしたいの?
ほらほらボクチンここprivateだから他のクラスから触れないからね!

チンカス過ぎる

0379デフォルトの名無しさん2017/04/21(金) 05:56:50.07 ID:67Y5mbs0

カプセル化はそもそも代入禁止じゃなくて隠蔽なんだが理解して書いてるのか？

SRP原則に則るならカプセル化のほうがいいに決まってる

0380デフォルトの名無しさん2017/04/21(金) 06:07:38.30 ID:H6APCPmE

なぜ隠蔽するかって言うと、不用意な変数の書き換えをさせない為。
関数型言語の場合は必ず変数の書き換え(と言うか再生産だが)を行うには関数を経由する。
変数を隠蔽したい場合は、パッケージで変数や関数単位で公開非公開を指定する。

0381デフォルトの名無しさん2017/04/21(金) 06:09:25.78 ID:rPWpf+kQ

>>379
誰から何を隠蔽するためのものなのか明確になってないんだよ

0382デフォルトの名無しさん2017/04/21(金) 06:13:30.88 ID:rPWpf+kQ

例えばライブラリ提供者と使用者
使用者はライブラリ側のソースを一切触ることがなく
提供者は使用者側からの問い合わせや変更依頼を断れない
ここまで立場が明確なときに隠蔽は意味を持つが

すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない

と俺は思う

0383デフォルトの名無しさん2017/04/21(金) 06:25:22.14 ID:uAFMuOM4

>>380
それだと参照するだけならいいってことになっちゃうよ？
隠蔽するなら不用意な参照もダメだよね。

0384デフォルトの名無しさん2017/04/21(金) 06:33:08.40 ID:67Y5mbs0

>>380
隠蔽はその変数の操作をそのクラス内に限定するためにある
プロパティを介してprivate変数に代入や参照ができるようにしてるのもそのため
変数の書換禁止ならそれこそfinalつければ済む

>>382
>すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない
誰がいじろうとも修正箇所をクラス内に限定する意味はあるだろ

0385デフォルトの名無しさん2017/04/21(金) 06:36:29.75 ID:rPWpf+kQ

>>384
だからそんなものはアプリケーションの仕様の前には意味を成さないんだよ

0386デフォルトの名無しさん2017/04/21(金) 07:13:56.06 ID:zhvS/nL7

車とタイヤをオブジェクト指向で表現する場合、車クラスにタイヤ属性を持つのが良いでしょうか

それぞれクラスを持ってる方が良いでしょうか

0387デフォルトの名無しさん2017/04/21(金) 07:21:08.83 ID:7DnA3IDC

>>383
マルチスレッドでも言われるが、参照だけなら基本問題無い。
上でも書かれている通り、隠蔽したければカプセル化じゃ無くても方法はある。

カプセル化と言うか、クラスと言う型に関数(メソッド)や変数(フィールド)を押し込めるのと、関数プログラミング的な考えはメリット/デメリットがそれぞれある。

クラスは依存関係が出来やすいが、GUIなどの多くの状態を保持するのに向く。
一方の関数プログラミングはデータと関数が分かれるので依存関係を少なく出来るが、状態を関数の引数として引き回すのでGUIに向かない。

関数型言語ではa = 1はそのプログラムではずっと1で、2が欲しければinc a とか、succ aとか関数の結果として2を受け取る。

0388デフォルトの名無しさん2017/04/21(金) 07:23:34.62 ID:fRfyQmKB

>>385
納品したら終わりってアプリを組むときにはカプセル化なんて確かに無用だけど
そもそもカプセル化とかその先のデータ抽象（抽象データ型）とかは、アプリが動いたり大規模化したあと
それをメンテしつつ運用（ちょっとしたバグ修正だけでなく、拡張や機能改変を含め）し続けるときに
それをやりやすくする技術だからなぁ…

0389デフォルトの名無しさん2017/04/21(金) 07:24:52.21 ID:YTf7CJ3G

>>385
個人開発ならばまぁわからんでもないが発想が危険すぎる
頼むからめんどくさいバグを作り込む前にプログラムから手を引いてくれ

0390デフォルトの名無しさん2017/04/21(金) 07:30:28.22 ID:rPWpf+kQ

>>389
何を言ってるんだよ
誰から何を隠蔽するのか明確にしろよ

0391デフォルトの名無しさん2017/04/21(金) 07:38:01.69 ID:rPWpf+kQ

>>389
お前のソースって読み手が完全な傍観者である場合は意味があるけど
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいんだろ
privateにした変数がクラス内グローバル変数みたいな動作してる典型だよね

0392デフォルトの名無しさん2017/04/21(金) 07:40:08.56 ID:uAFMuOM4

>>387
だからいくつかある方法のひとつがカプセル化なんだよね？

>>390実装依存しようとしている人間から実装を隠蔽するんじゃね？

0393デフォルトの名無しさん2017/04/21(金) 07:43:06.82 ID:rPWpf+kQ

>>392
全然意味がわからない
対象のクラスに手を入れようとしてる人間に対して隠蔽したいの?

0394デフォルトの名無しさん2017/04/21(金) 07:48:52.81 ID:uAFMuOM4

「実装依存しようとしている人間から実装を隠蔽する」

これ以上どう簡単に言えるのか？

0395デフォルトの名無しさん2017/04/21(金) 07:59:35.17 ID:YTf7CJ3G

>>391
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいだろ
publicにした変数がクラス外にも波及するグローバル変数みたいな動作してる典型だよね

どこまで影響すると思ってるんだ
調査、設計、対応、試験にかかる工数がとんでもない数値になる

0396デフォルトの名無しさん2017/04/21(金) 08:21:01.29 ID:rPWpf+kQ

>>394
全く意味がわからない
外部設計書とか内部設計書とか
以外の仕様書があってそれに基づいて作成してるの?

0397デフォルトの名無しさん2017/04/21(金) 08:30:29.31 ID:YTf7CJ3G

>>396
ところで全然わかってない自覚があるのになぜ不要と言い張れるの？
不要である理由を明確にしろよ

0398デフォルトの名無しさん2017/04/21(金) 08:30:52.58 ID:rPWpf+kQ

ていうか読み込んだデータに基づいて処理するも
ソースに記述した定数で処理するも仕様書次第じゃないの?
実装依存が何を指して実装依存って言ってるのかわからない

0399デフォルトの名無しさん2017/04/21(金) 08:31:42.41 ID:rPWpf+kQ

>>397
どのレスの不要?
引用して欲しい

0400デフォルトの名無しさん2017/04/21(金) 08:39:43.24 ID:YTf7CJ3G

>>399
カプセル化不要についてだよ

まさかひとつひとつ違うことに対して不要だと言いまくってたの？

0401デフォルトの名無しさん2017/04/21(金) 08:46:39.65 ID:TFy/T03e

知らなくてもなくても作れるのだから不要。
極論すればアセンブルでも作れる。

0402デフォルトの名無しさん2017/04/21(金) 08:54:22.04 ID:rPWpf+kQ

>>400
カプセル化の不要についてだね
おｋ

まず処理の動作は設計書に書くものだろう
ソースでprivateやpublicになってるからどうだってんだよ

ここで反論ある?

0403デフォルトの名無しさん2017/04/21(金) 08:54:46.12 ID:uAFMuOM4

実装がpublicだと他人がその実装に依存して良くないことがありそうだ。参照だけでもマズい。
だからprivateにして実装を隠蔽する。

これのどこに分かりにくい点があるというのか？
設計書とか仕様書とか関係なかろう

0404デフォルトの名無しさん2017/04/21(金) 09:00:18.64 ID:YTf7CJ3G

>>402
ある
利用者は仕様書を確認することなく意図しない方法で利用する

他は？
と言うか一度に全部言ってくれ

0405デフォルトの名無しさん2017/04/21(金) 09:05:15.16 ID:rPWpf+kQ

>>404
利用者って誰?
ソースを改変するソイツ（?）は設計書を記述せずに対象のクラスを変更しようとしてる?
ソイツのことを利用者と呼んでいてお前の環境では存在しうるの?

0406デフォルトの名無しさん2017/04/21(金) 09:10:26.57 ID:n31cY2TM

あぼーん

0407デフォルトの名無しさん2017/04/21(金) 09:27:52.36 ID:Ck7s6rRh

個人製作の観点からはカプセル化はいらんな
テンプレートか抽象タイプと多重ディスパッチあれば継承もいらんしミックスインもいらん

0408デフォルトの名無しさん2017/04/21(金) 09:38:24.71 ID:9S9WRWBb

>>405
実装する人が複数いる時、自分が作ったクラスのメンバ変数やメンバ関数を利用して
その人の担当クラスを実装する他人が自分のクラスの利用者だろう。
自分が作ったクラスも他人が作ったクラスも変更するのは作った人だけだ。

実装を一人で行える規模ではカプセル化の必要を感じないという話なら分かる。
でも前提なしでカプセル化は不要と主張したら大規模ソフトウェアも含まれる。
もしかして大規模ソフトウェアで必要かどうか全然考えてなかったの?

0409デフォルトの名無しさん2017/04/21(金) 09:46:56.85 ID:cmecYv9F

だからホリデープログラマーと話しても無駄やて

0410デフォルトの名無しさん2017/04/21(金) 09:59:20.07 ID:WJo/zINx

むしろここで仕事の話をする方がおかしいけどな

0411デフォルトの名無しさん2017/04/21(金) 10:01:25.18 ID:WJo/zINx

>>408
担当のチェンジは無しなの？

0412デフォルトの名無しさん2017/04/21(金) 10:22:27.45 ID:YTf7CJ3G

>>405
話が止まるからまずは全量を語ってくれ

0413デフォルトの名無しさん2017/04/21(金) 10:43:25.71 ID:+U39WrXp

カプセル化されていると、メンバ変数とアクセサは分離され、外部のクラス利用者（ユーザコード）はもっぱらアクセサを呼ぶことになる。
仮にメンバ変数の実装の詳細を変更することになっても、アクセサを変更しない限り、ユーザコードは変更する必要はない。
間接層の導入による変更の局所化やね。

メリットと煩わしさの比較は人により異なりうるが、少なくとも必要なケースは少なからずあると思うが。

0414デフォルトの名無しさん2017/04/21(金) 10:54:13.27 ID:uAFMuOM4

せっかくカプセル化してもアクセッサなんか作ったら不自由になる。
変数を廃止したり形式の変更をしたりしにくくなる。

0415デフォルトの名無しさん2017/04/21(金) 11:10:28.55 ID:rPWpf+kQ

>>408
じゃあ利用者ってのはクラス使用者（そのクラスには絶対に手を加えない）のことでいいの?

0416デフォルトの名無しさん2017/04/21(金) 12:01:38.24 ID:YTf7CJ3G

>>415
そうだよ
javaで言うならStringクラスの利用者はStringクラスの内容を変更しないだろ

いちいち立ち止まらずまずは全量を語ってくれ

0417デフォルトの名無しさん2017/04/21(金) 12:12:59.55 ID:T1EM2She

【全量】全体の重量。全体の容積。

0418デフォルトの名無しさん2017/04/21(金) 12:20:09.36 ID:YTf7CJ3G

>>417
ありがとう

0419デフォルトの名無しさん2017/04/21(金) 12:41:44.49 ID:rPWpf+kQ

>>416
ほうほう
だったら仮にそのクラス自体に手を入れることになった場合は
隠蔽対象者ではないということでおｋ?

0420デフォルトの名無しさん2017/04/21(金) 12:49:54.80 ID:YTf7CJ3G

>>419
うだうだ言ってねーで早く語れ

0421デフォルトの名無しさん2017/04/21(金) 12:52:42.74 ID:3x8HXz+G

相手にしない方がいいよ時間と労力の無駄
ID:YTf7CJ3Gが楽しんでやっているならとめないけど

0422あ2017/04/21(金) 13:05:41.49 ID:KFYgHFHL

何十年前の話なのかわからなくなるな

0423デフォルトの名無しさん2017/04/21(金) 13:27:43.71 ID:T1EM2She

>>422
いつ何度でも話していいことだと思うが
会話ってそういうものだと思う

人の色恋沙汰なんて4000年前に語りつくされているが
今なお人の心をとらえて離さないだろ

オブジェクト指向にとってカプセル化とは
それくらいの魅力があるものだってこと

会話っていうのは昔々誰々がすでにいったことだから
言っちゃいけない、話しちゃいけないなんてもんじゃない

会話に入りたいって素直に言うべき、カプセル化やめるべきって
ちゃんというべき

0424デフォルトの名無しさん2017/04/21(金) 13:46:02.03 ID:YTf7CJ3G

>>421
ありがとう
うんこタイムの暇潰しなので大丈夫だよ

>>423
べき論はよくわからん
そんなことよりも不要である理由を早く『明確』にしてくれ

0425デフォルトの名無しさん2017/04/21(金) 13:51:29.39 ID:cmecYv9F

>>410
仕事の話ではなくオブジェクト指向の話だろ？
おれは１人で好きに作ってるからカプセル化なんていらねー！といわれても会話にならないよ

0426デフォルトの名無しさん2017/04/21(金) 14:26:24.80 ID:uAFMuOM4

>>425
それはそうだが、誰とどういうレベルで会話するのかってことだろう。
その前にホリデープログラマがどうたらってレスあるから。

0427デフォルトの名無しさん2017/04/21(金) 14:50:09.12 ID:T1EM2She

>>424
お前が明確にするんだよ、カプセル化やめるべきだって言うんだよ
お前の仕事だよ

0428デフォルトの名無しさん2017/04/21(金) 14:51:20.94 ID:T1EM2She

この業界趣味でやってる人の方が技術力高かったりするからね
サンデープログラマを馬鹿にしちゃいけない

0429デフォルトの名無しさん2017/04/21(金) 15:30:29.00 ID:YTf7CJ3G

>>427
俺は必要だと思ってるから無理だな
不要である理由を明確にするのはおまえだ

0430デフォルトの名無しさん2017/04/21(金) 15:33:45.46 ID:I/U40a25

データのカプセル化なんてプログラム上どこまで触って(参照/代入)いいかの線引きを決まりごとからシステム的に制限したかの違いなだけでしょ
c言語のFILE構造体の中身を参照する事はないでしょ。stdio.hに定義されていても
それは暗黙的な決まりごとだからだし、それをアクセス修飾子で明示したのがカプセル化って言葉なだけで昔からの決まりごととしては変わらない

0431デフォルトの名無しさん2017/04/21(金) 15:42:27.29 ID:T1EM2She

>>429
どうして必要だと思ってるのか全量を言えよ、じゃないと理解できない

0432デフォルトの名無しさん2017/04/21(金) 15:46:08.76 ID:T1EM2She

>>430
その決まりが要らないものだったんじゃないかっていうのが
カプセル化害悪論の骨子なんだよ

暗黙的なものは暗黙的なままでよかったんじゃないか？
なぜ明示する必要があったのか、それによってプログラムが
複雑になることを受け入れるのか、プログラムがブラックボックス化することに
歯止めをかけてクリーンなオブジェクト指向を取り戻そうというのが
カプセル化害悪論のモチベーション

0433デフォルトの名無しさん2017/04/21(金) 15:49:33.07 ID:YTf7CJ3G

>>431
聞いてるのはこっちだ
はぐらかすな

0434デフォルトの名無しさん2017/04/21(金) 15:51:44.08 ID:T1EM2She

>>433
聞き返したのは俺だ、ちゃんと全量を示せ、逃げるな

0435デフォルトの名無しさん2017/04/21(金) 15:55:05.36 ID:YTf7CJ3G

質問に対する答えが質問になる程度の考えしか持たぬならもういいわ

0436デフォルトの名無しさん2017/04/21(金) 15:55:47.07 ID:T1EM2She

>>435
捨て台詞まで吐いて逃げるのな？

0437デフォルトの名無しさん2017/04/21(金) 15:56:28.58 ID:T1EM2She

もういいわて、お前は漫才師か！

0438デフォルトの名無しさん2017/04/21(金) 15:57:50.64 ID:YTf7CJ3G

そだね

0439デフォルトの名無しさん2017/04/21(金) 15:59:01.00 ID:T1EM2She

はい逃げた、結局カプセル化を支持するやつって中身のないその場限りの
見栄を張って問い詰められたら逃げるだけの俄かなんだよな

0440デフォルトの名無しさん2017/04/21(金) 16:01:17.62 ID:YTf7CJ3G

そだね

0441デフォルトの名無しさん2017/04/21(金) 16:01:35.09 ID:I/U40a25

>>432
カプセル化害悪論ってのは一理あるし正しいと思うけどね
性善説と性悪説みたいなところだから正解はでないと思うし
ただ、このスレのカプセル化反対の意見はそんなレベルの話じゃない、そもそも議題のカプセル化の認識ズレの話なんじゃないのかな

0442デフォルトの名無しさん2017/04/21(金) 16:08:41.18 ID:rPWpf+kQ

>>424
それは説明したじゃん
402がすべてだよ

0443デフォルトの名無しさん2017/04/21(金) 16:14:29.43 ID:9S9WRWBb

>>441
カプセル化反対の二人はカプセル化の利害を全然理解していないよね。
害があるからいらないではなく、わからないからいらないと言っている。

0444デフォルトの名無しさん2017/04/21(金) 16:20:27.91 ID:rPWpf+kQ

>>443
んでメリットの説明ってあったっけ?

0445デフォルトの名無しさん2017/04/21(金) 16:20:44.14 ID:YTf7CJ3G

>>442
明確になってねーよ
仮にアレで全てだというなら『まず』とか『ここまで』などと言うな

0446デフォルトの名無しさん2017/04/21(金) 16:22:11.78 ID:jkmg2197

カプセル化害悪派 <------- 結合度ビーーーーム
死亡

0447デフォルトの名無しさん2017/04/21(金) 16:35:15.00 ID:9S9WRWBb

>>444
例えば>>403がそうだ。
自分だけが使い仕様変更があったら変更するつもりのメンバ変数やメンバ関数は
勝手に他人に参照されたり呼びだされると変更できなくなって困る。

0448デフォルトの名無しさん2017/04/21(金) 16:41:52.97 ID:uAFMuOM4

どうでもいいけどメリデメって略すの嫌い

0449デフォルトの名無しさん2017/04/21(金) 16:43:18.10 ID:jkmg2197

カプセル化害悪論って、どっかで聞きかじった継承害悪論とごっちゃになってるんじゃないのか？

0450あ2017/04/21(金) 16:49:15.74 ID:KFYgHFHL

>>423
どちらでも無いと思うよ。少なくともどちらかへの「べき」ではない。
隠したいものは隠せばいいし、機械へのポカヨケを埋め込むのも今もうすでに実行不可なメモリみたいなどこのハーバードアーキテクチャだよみたいなの再発明してんじゃん。

0451デフォルトの名無しさん2017/04/21(金) 17:12:45.41 ID:9S9WRWBb

>>449
>>216はごっちゃにしているね。

実装継承は20年前に「継承より委譲」と言われていた。
その後のEJB2の複雑さの反動でPOJOブームが起きた。
でもカプセル化害悪論なんて聞いたことがない。

0452デフォルトの名無しさん2017/04/21(金) 17:31:41.72 ID:jkmg2197

>>199みたいな、ここまでがっちり結合したコードを良しとする人が、数万行程度コードを書いたらどんなことになるのか見てみたいわ

0453デフォルトの名無しさん2017/04/21(金) 18:00:15.36 ID:T1EM2She

>>452
おめーのコード出してもらおうか
俺はそれを複雑すぎるとさんざんにこき下ろすから
他人のコードにいちゃもんつけて自分のコードは出しませんなんて
そんなのありえないだろ、ベッドで女のパンツ脱がして
自分はスリーピースをぴっちり着込んでるようなもの
どちらが変態化は言うまでもないよね？

0454デフォルトの名無しさん2017/04/21(金) 18:03:14.83 ID:T1EM2She

>>451
やはりな、継承はオブジェクト指向に必要ないよな
POJOはたしかに話題にはなったが、まだJavaBeansの呪縛から
脱しきれてない過剰カプセル化によって逆に脆くなった
設計ばかりが出回った

いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
聞いたことがあるというべきだし、すぐれた設計だと
後世に伝えていくべき

0455デフォルトの名無しさん2017/04/21(金) 18:04:56.46 ID:YTf7CJ3G

>>453
おまえはおまえのコード以外を認めないんだから黙ってろ

0456デフォルトの名無しさん2017/04/21(金) 18:05:19.93 ID:T1EM2She

>>455
……

0457デフォルトの名無しさん2017/04/21(金) 18:07:31.03 ID:jkmg2197

>>453
別に俺が出すまでもなく、世の中にはそこそこSOLIDを目指したなかなかのコードが死ぬほど公開されてるんだが

> 俺はそれを複雑すぎるとさんざんにこき下ろすから
それらが読めないとしたら、それは複雑すぎる場合もあるだろうが、大抵は君のスキル不足だろうね
試しにgitfubから有名どころの1万行以上のプロダクトを選択してこきおろしてみたら？

0458デフォルトの名無しさん2017/04/21(金) 18:11:31.05 ID:YTf7CJ3G

>>454
>いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
>聞いたことがあるというべきだし、すぐれた設計だと
>後世に伝えていくべき

一切論じられてないよ
悪いんだけどどこらで論じてたのか教えてくれる？

0459デフォルトの名無しさん2017/04/21(金) 18:11:49.39 ID:T1EM2She

>>457
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ

0460デフォルトの名無しさん2017/04/21(金) 18:12:34.04 ID:jkmg2197

>>453
選ぶの面倒とかいいそうだから、俺が選んでやろう
Javaで実装された超有名プロダクト
https://github.com/kohsuke/jenkins
ほら、駄目だししてみ？

0461デフォルトの名無しさん2017/04/21(金) 18:13:54.37 ID:T1EM2She

>>458
>>322 この辺とかすごくいい議論ができてるしとても有益でためになると思う

0462デフォルトの名無しさん2017/04/21(金) 18:14:43.96 ID:T1EM2She

>>460
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ
他人のふんどしで相撲取ろうとするな卑怯者

0463デフォルトの名無しさん2017/04/21(金) 18:15:18.80 ID:T1EM2She

とうぜんキャットドア問題を解決するコードだ

0464デフォルトの名無しさん2017/04/21(金) 18:16:17.62 ID:T1EM2She

結局キャットドア問題を解決できたの俺だけじゃん
カプセル化を導入してたらできてなかったと思う
俺は歴史の生き証人

0465デフォルトの名無しさん2017/04/21(金) 18:17:40.73 ID:jkmg2197

>>462,463
俺には難しすぎて読めませんって白状しろよ

0466デフォルトの名無しさん2017/04/21(金) 18:17:51.34 ID:T1EM2She

キャットドア問題をオブジェクト指向で解決してください
権威や数の力は不要だ、オブジェクト指向をわかっているなら
自力で解決できるはずだ

0467デフォルトの名無しさん2017/04/21(金) 18:18:26.45 ID:YTf7CJ3G

>>461
悪いんだけど根拠のない言い合いに意味はないよ
根拠を示してくれる？

0468デフォルトの名無しさん2017/04/21(金) 18:18:45.77 ID:jkmg2197

>>464
そもそも、キャットドア問題とか知らんし
他人のコード書いてほしけりゃ、仕様示せ

0469デフォルトの名無しさん2017/04/21(金) 18:19:13.64 ID:T1EM2She

>>465
で、キャットドア問題を解決するオブジェクト指向のお前が書いたコードは？
俺は書いたよ、お前にいちゃもんつけられたけど
だから、俺はお前が書いたコードをボコボコに貶してやる所存だけど
お前はその覚悟もできてるし受けて立つ実力もあるんだよな
じゃあコードを書いてもらおうか

0470デフォルトの名無しさん2017/04/21(金) 18:20:45.36 ID:T1EM2She

>>468
このスレにいて知らないはありえない
すれを検索すればすぐにでてくる >>6

0471デフォルトの名無しさん2017/04/21(金) 18:21:06.06 ID:T1EM2She

仕様にいちゃもんつけて逃げたりしてｗ

0472デフォルトの名無しさん2017/04/21(金) 18:21:25.26 ID:jkmg2197

>>466
>>199程度のコードなら、誰がどう書いても複雑にはならんだろ
俺の>>199の批判ポイントはSOLIDだ

OCPはダメダメらしいが、S,L,I,Dも駄目なら批判しなよ

0473デフォルトの名無しさん2017/04/21(金) 18:21:43.58 ID:T1EM2She

この手の手合いは他人を否定するけど自分では何も作れない木偶の坊と相場が決まってるからな

0474デフォルトの名無しさん2017/04/21(金) 18:22:17.82 ID:T1EM2She

さて、どんなコード書くんだろうな、楽しみだわ

0475デフォルトの名無しさん2017/04/21(金) 18:23:03.71 ID:T1EM2She

>>472
>>199は俺のコードだからパクっちゃだめだぞ、カンニングは卑怯な行為だからな
あくまで仕様を読んで作るんだぞ

0476デフォルトの名無しさん2017/04/21(金) 18:23:31.45 ID:jkmg2197

>>470
なんだ、>>199と全然違うじゃんか
俺は>>199の範囲で>>199のコードが糞だと断言するわwww

0477デフォルトの名無しさん2017/04/21(金) 18:24:37.49 ID:T1EM2She

他人を否定すればするほど自分のハードルがあがるけど大丈夫なのかな
結局自分のコード書けないパターンをちゃくちゃくと歩んでるようだけど大丈夫なのかな
逃げ出しそうだぞ、大丈夫なのかな

0478デフォルトの名無しさん2017/04/21(金) 18:26:54.78 ID:YTf7CJ3G

>>477
カプセル化害悪論の根拠を示してくれるかな？

0479デフォルトの名無しさん2017/04/21(金) 18:27:35.87 ID:T1EM2She

>>478
……

0480デフォルトの名無しさん2017/04/21(金) 18:28:40.65 ID:YTf7CJ3G

>>479
あ、根拠ないんだね
了解

0481デフォルトの名無しさん2017/04/21(金) 18:29:00.98 ID:T1EM2She

……

0482デフォルトの名無しさん2017/04/21(金) 18:29:47.23 ID:T1EM2She

黙ってろって言われたから黙らざるを得ないのに
それで了解とか自己完結しすぎだと思う、病んでるよ彼は病んでるよ

0483デフォルトの名無しさん2017/04/21(金) 18:30:19.40 ID:YTf7CJ3G

>>482
じゃあ黙り続けろよ

0484デフォルトの名無しさん2017/04/21(金) 18:30:38.43 ID:T1EM2She

>>483
……

0485デフォルトの名無しさん2017/04/21(金) 18:30:56.12 ID:T1EM2She

俺のことは寡黙な人と呼んでくれ

0486デフォルトの名無しさん2017/04/21(金) 18:31:20.37 ID:YTf7CJ3G

>>485
黙ってねーじゃねーか

0487デフォルトの名無しさん2017/04/21(金) 18:32:01.93 ID:T1EM2She

>>486
クソレスすんなハゲ

0488デフォルトの名無しさん2017/04/21(金) 18:33:35.27 ID:YTf7CJ3G

>>487
ごめんね
ハゲでごめんね^^

0489デフォルトの名無しさん2017/04/21(金) 18:36:02.42 ID:T1EM2She

ハゲもプログラム書けんの？
書けるんだったらオブジェクト指向でキャットドア問題に調整してほしい

0490あ2017/04/21(金) 18:39:02.82 ID:KFYgHFHL

あのドアってこういう話の発端から出てきた問題だったんだな。
オブジェクト指向で、ってそういう事か、なるほど。
ナンセンスだな。

何を以ってドアと成立するか定義できてるようで出来てない。
定義1を死守したければ、俺なら定義1は定義0の子クラスにして、定義2は定義1を継承せずに定義0から作るわ。
定義0は最終的にObjectに収斂する。

クラス設計を破壊せずに性質を追加ってのが矛盾してる。
ワイン樽と泥水の問題。

0491デフォルトの名無しさん2017/04/21(金) 18:42:27.87 ID:T1EM2She

↑こうやって仕様に文句を付けて
コードから逃げる人間は飽きるほど見てきた

オブジェクト指向のコードをかける人間はいないのか

0492あ2017/04/21(金) 18:45:08.24 ID:KFYgHFHL

>>491
俺どっかで書いたぞ

0493デフォルトの名無しさん2017/04/21(金) 18:46:48.77 ID:T1EM2She

>>492
それどこよ？　どれよ？　どこなのよ？　どこーーー！！

0494デフォルトの名無しさん2017/04/21(金) 18:47:06.08 ID:T1EM2She

取り乱してしまいまして

0495あ2017/04/21(金) 18:48:45.01 ID:KFYgHFHL

もちろん、オブジェクト指向が役に立ちづらい、リアルな機械はそもそもコンポーネント指向で作るとも書いたし、コード自体適当なのも確かだが。
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

0496あ2017/04/21(金) 18:53:00.35 ID:KFYgHFHL

何でわざわざ関数作ったのに放棄してクロージャ変数にしてるか見たら、カプセル化がオブジェクト指向の専売でもなけりゃ普遍的に便利なものか気づくだろ。

0497デフォルトの名無しさん2017/04/21(金) 18:59:03.34 ID:T1EM2She

>>496
クロージャがカプセル化じゃないとしたら
カプセル化害悪論には賛成していただけるよね？

0498あ2017/04/21(金) 19:05:27.23 ID:dftFol4E

>>497
クロージャはカプセル化で、カプセル化害悪論には大反対だ。
カプセル化されてるから、ドアは責任を持ってイベントに対して好きなことを好きなだけできるし、他人はそれに関与せずにイベントの投げ合いで済む。
鍵のないドアだってあるんだから。

0499あ2017/04/21(金) 19:06:54.30 ID:dftFol4E

見せたくないものを隠すんだけじゃない。
見て不快なものが目に入らないようにするためにも使えるんだよ。
NHKの入らないテレビみたいなもんだ。

0500デフォルトの名無しさん2017/04/21(金) 19:27:31.37 ID:rPWpf+kQ

>>499
具体的に誰に対してやってるの?

0501デフォルトの名無しさん2017/04/21(金) 19:29:06.55 ID:T1EM2She

>>498
カプセル化害悪論に反対しているとのことだけれども
もしクロージャがカプセル化ではないと仮定したら
カプセル化害悪論に反対する理由もなくなると思うんだよ

クロージャってどちらかというとローカル変数じゃない？
クロージャオブジェクトを使うところって関数内に限られると思うんだよ
そう考えるなら結局クロージャってローカル変数ってことになるわけじゃん？
だからクロージャを使ってもカプセル化害悪論には反しないんだよ

0502あ2017/04/21(金) 20:03:29.23 ID:qsriX73g

>>500
自分かも知れないし、他人かもしれないけど、それを考えたくない場面でそれが目に入らないようにしてる。
その関数以外書いてるときに、その関数なんて考えたくないじゃん。

>>501
だからクロージャは一つのカプセル化だって言ってるんよ。
ローカル変数って言葉が良くないが、ローカル変数には違いない。ただ、お前が思ってるローカル変数よりも限定的で、そして並行的だよ。
関数内に限られるわけではない。mallocして何かに帰そうが勝手だよ。
クロージャの中でいくつかのコールバックに渡したりするならなおさら。
つまるところ、オブジェクト指向のインスタンスのメンバ変数とあまり変わらん。

0503デフォルトの名無しさん2017/04/21(金) 20:07:05.07 ID:rPWpf+kQ

>>502
はぁ?
ちゃんと設計書は書いてる前提でいいんだよね?

0504あ2017/04/21(金) 20:17:17.21 ID:qsriX73g

>>503
うん。書いてるから何？
書いてるから触ってはいけないとわかるはずだ、なら、無意味かつ実務知らなすぎだな。
書いてて触ってはいけないならば、触れることができてはいけないんだよ。本来は。
AppleのMacOSのUIのデザイン規約くらいの時代から書いてた話。
感電するよって書いてたら覆いをしなくたって良いなんて機械はありえないのと同じ。

0505デフォルトの名無しさん2017/04/21(金) 20:22:47.97 ID:YTf7CJ3G

包丁は料理にのみ使われるものだから傷害事件で扱われる刃物は包丁以外であるって理屈

0506デフォルトの名無しさん2017/04/21(金) 20:32:03.02 ID:rPWpf+kQ

>>504
じゃ、君の想定してる環境って

本来なら設計書を記述してから修正すべきなのに
それがやりにくい現場ってことでいいのかな?

カプセル化は設計書を記述する手順を踏んだとき役に立たない?

0507デフォルトの名無しさん2017/04/21(金) 20:45:20.00 ID:YTf7CJ3G

車のブレーキだけを踏んでたら全然進まないのでプレーキを踏んでもちゃんと進むように修理する工場だな

0508デフォルトの名無しさん2017/04/21(金) 20:51:25.16 ID:uAFMuOM4

カプセル化の意義を誤解するものはfriendの意義も誤解する

0509あ2017/04/21(金) 21:04:20.97 ID:qsriX73g

>>506
本来なら設計書を記述するどころか設計変更申請出して承認を経て設計書と設計変更書を出して、実装を変更して設計変更書から起こされた上がってきたテスト仕様書でテストして完了するけど、何もやりにくくないでしょ。

カプセル化は役に立つよ。担保となる元の設計書で使ってる部品の設計書を出来る限り見ずに済むし、
なんなら部品ごと新しく変えてもIFさえあってれば良い証左になるんだから。

>>507
プレーキとやらの定義が、踏めば進むというものであるならそう治すべく修理なり改修なりするわな。
このパンチメタルで穴が空いてる部品は共有部品で、AT車ならフットレスト、MT車ならクラッチペダルにつける部品の首がよく腐るから設計変更するなら、
押してクラッチが切れるかもしれない部品であり、押しても何も起こらない部品を同時に設計変更してる事になるが。
お前らのドアってこのパンチメタルの板くらいフワフワした定義。

0510デフォルトの名無しさん2017/04/21(金) 21:09:39.74 ID:rPWpf+kQ

>>509
設計書書いてるんだよね?

だったら今回の開発でそのメソッドを呼び出す奴は決まってる
今後増える予定を想定することの記述も設計書にはないでしょ?

この状態でprivateとpublicになんの意味があるの?

0511デフォルトの名無しさん2017/04/21(金) 21:11:56.33 ID:YTf7CJ3G

>>509
全面的に同意
ふわっふわしまくってるせいでカプセル化が害だとか言うバカみたいな考えなしの意見が出てくるんだと思う

0512あ2017/04/21(金) 21:16:51.77 ID:qsriX73g

>>510
呼び出すやつは決まってる、今後呼び出し方が変わる予定も無い。
ならばそいつはそれがインターフェイスで良いと思うけど、インターフェイスが無いわけではない。そいつがそのものであるだけで。
その上で、疎通にはこれを使おうね、これは使ってくれるなよ、と言う設計は無為味だし、むしろそうならばモジュラーにせずにそれごと機械に埋めてしまえとなる。
そうでは無くて、壊れたらこれだけ変えられるようにしとこう、とか、これだけを改良できるようにしよう、とか、
不具合が出たときに特定しやくすしとこうとなると、ある意味不自由を強制する形で決まった形で疎通させるのは当然でしょ。
お前のパソコンがノートパソコンならタッチパッドは前者、USBマウスは後者だよ。

0513デフォルトの名無しさん2017/04/21(金) 21:25:56.38 ID:rPWpf+kQ

>>512
何?次の開発を想定してるの?
よくわからないんだけど?

問題があったら設計書を修正してレビューしてソース修正する流れでいいんだよね?

0514デフォルトの名無しさん2017/04/21(金) 21:29:21.44 ID:JwbSy4qm

ここまでの流れで面白いのは>>414の視点だけ
カプセル化がどうの
その是非がどうのとはさんざん繰り返されがちだが

アクセッサ自体が意外と臭いよねって観点まで到達できる人は少ない
また、そこから先の議論についてもあまり見かけない

0515デフォルトの名無しさん2017/04/21(金) 21:31:37.27 ID:cmecYv9F

>>514
そもそもアクセサなんてものはモダン言語では自動生成なので論外

0516デフォルトの名無しさん2017/04/21(金) 21:33:08.50 ID:YTf7CJ3G

>>513
いつもよくわかってないな

0517デフォルトの名無しさん2017/04/21(金) 21:34:14.81 ID:JwbSy4qm

その自動生成ってのを嬉しがる精神性が問題
アクセッサなんか書きにくいほうが健全
きみにはまだ伝わらないと思うし
これ以上言葉費やす予定もない

0518あ2017/04/21(金) 21:35:03.27 ID:AJ6tejAv

>>513
一般的に開発ってこんなもんだろ。
物理的な製造業から何まで、本来は。

問題があったら、設計変更の起案からだよ。
設計変更より作り直したほうが安くつくとか考えないといかんだろ。
ソース修正した後に、何を担保にしてその修正が妥当か、どういうテストが妥当かを定義するときに、組み合わせ爆発が起こらんようにIF定義するんじゃん。

>>514
アクセサのあるprivateなメンバなんか、ちょっと運が良ければチェックロジックなんか入ってるかも？運が悪ければ違う値まで変わっちゃうかも？みたいな、余計に面倒くさい奴だしな。

0519デフォルトの名無しさん2017/04/21(金) 21:40:55.19 ID:rPWpf+kQ

>>518
修正した設計書通りでしょ?
これがすべてに優先されるんでいいんだよね?っていうかそうじゃなかったらびっくりだわ

前のソースは関係ないよ
privateやpublicに意味なんかないよ

0520あ2017/04/21(金) 21:44:00.25 ID:AJ6tejAv

>>519
修正した仕様書の妥当性はどう計測して、修正したソースの妥当性はどう計測するの？
インアウトが確実に2つずつなら、ステートマシンでも組み合わせ数は知れてるだろうが、
インアウトの数が担保できなければそんなもの検証しようがない。

0521あ2017/04/21(金) 21:46:20.92 ID:AJ6tejAv

逆に言うわ。publicなものの組み合わせを検証する必要が本当に正しいと証明するためにはある。それはnCmで増える。
だから、組み合わせを減らしたい。

0522デフォルトの名無しさん2017/04/21(金) 21:47:22.88 ID:cmecYv9F

>>517
いーやわかってないのはおまえ
アクセサの必要性が低いなんてことは歴史的背景ふまえググれば中学生でもわかること
ではなぜ事実上、必須になっているか
そこまで考えてはじめて俺と同じ土俵に立てる
出直せ

0523あ2017/04/21(金) 21:51:18.83 ID:AJ6tejAv

>>522
アクセサは自動生成されるべきじゃないし、される言語も少なくないか？アクセサ作ったらメンバが生えるのはあるだろうけと。

0524デフォルトの名無しさん2017/04/21(金) 21:51:19.37 ID:TFy/T03e

publicフィールド = 何の制限もかけられないアクセッサだよ

つまりいずれにしろアクセッサ相当のものを使っているわけで、
問題はアクセッサがいるかどうか？ではなく、
制限をかける必要があるかどうか？

で考えたほうが良い。

0525あ2017/04/21(金) 21:52:38.91 ID:AJ6tejAv

>>521
意味わからん文になってた。証明するためには全パターンを網羅する必要がある、だな。

0526デフォルトの名無しさん2017/04/21(金) 21:58:52.01 ID:cmecYv9F

>>523
されるべきなんだよ
何故なら90%のメンバ変数はアクセサなんて必要としないから
残り10%のために手書きなんてバカらしいだろう

0527デフォルトの名無しさん2017/04/21(金) 21:59:11.05 ID:rPWpf+kQ

>>520
設計書通りに動くことを確認するよ

これができなくなっちゃうって言ってる?

0528あ2017/04/21(金) 22:07:30.53 ID:AJ6tejAv

>>526
メンバ変数を見ればいいなら、メンバ変数見れば良くない？
アクセサがない限り、見れない書けない方が健全だとは思うが。

>>527
似てるようで違う。
設計書が正しいかが組み合わせ全てを用いないと証明できないし、設計書通りかどうかも同様に証明できない。
インが4本なら16通りだけど、10本だと1024通りだよ。

0529デフォルトの名無しさん2017/04/21(金) 22:11:46.98 ID:TFy/T03e

設計書が正しければ、正しいプログラムができるはずだ！

0530デフォルトの名無しさん2017/04/21(金) 22:15:10.16 ID:TFy/T03e

設計書が正しいことをきちんとテストする必要がある。

つまり、設計書のテスト仕様書が必要だ。

そしてそのテスト仕様書通りに設計書が
正しいかをテストする人間も必要になる。

そこで重用なのは、テストの手法である。
設計書が正しいことをどうやってテストするか？
つまり設計書を書いた人間への聞き取り作業である。

設計書に書き漏れがないか？設計書に書かれた言葉に矛盾がないか？
テスト仕様書に従って設計書を見ながら設計者を問い詰める。
これが設計書に対する優れたテスト方法である

0531あ2017/04/21(金) 22:21:07.33 ID:AJ6tejAv

揶揄してるようだが、設計書をテストする設計書にあたるものが、設計変更申請書だよ。
それはヒアリングやら検証実験やら、承認者の首やら、人の手で担保するもの
大規模開発した事ないのかな。

0532デフォルトの名無しさん2017/04/21(金) 22:22:18.55 ID:cmecYv9F

>>528
アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要
だからモダン言語にはプロパティというものがある
プロパティに出来てpublic変数に出来ないことを考えればおのずとプロパティでいいよねという結論にたどり着くと思うがね

0533デフォルトの名無しさん2017/04/21(金) 22:23:36.50 ID:rPWpf+kQ

うーん
ぶっちゃけそれとカプセル化との関連が不明
もはや何を主張したいのか滅茶苦茶な気がするんだけど

0534デフォルトの名無しさん2017/04/21(金) 22:24:22.02 ID:TFy/T03e

> 設計書をテストする設計書にあたるものが

意味わからん。

設計書をテストするものは、設計書のテスト仕様書だ。

つまりその設計には、○○の場合の処理は抜けていないか？
○○の場合に不整合は起きないか？
などというものが書かれいいるもので無ければ、
設計書のテスト仕様書とはよべない。

0535デフォルトの名無しさん2017/04/21(金) 22:25:20.57 ID:rPWpf+kQ

>>520の発言内容はカプセル化と関係ないよね?

0536デフォルトの名無しさん2017/04/21(金) 22:26:41.05 ID:TFy/T03e

>>532
> アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要

アクセッサはアクセス制限ではなく、アクセスした後に入れようとした値が
正常値かどうかを判断するもの。
型だけでは表現できない特殊なルールを記述する所
アクセス修飾子は単にアクセスできるかどうかしか記述できない。

0537デフォルトの名無しさん2017/04/21(金) 22:32:34.16 ID:cmecYv9F

>>536
それは俺にレスするな
>>528の疑問に答えただけだから>>528にいえよ

俺の主張はgetter、setterの是非なんてものは時代遅れもいいところでその解がプロパティだろってことだけだ

0538あ2017/04/21(金) 22:32:51.15 ID:AJ6tejAv

>>532
プロパティはメンバ関数だよ。
C#ならIL見ればわかるけど、確かアンスコついた変数出来てる。
プロパティ自体もフツーに関数。
何で見えない変数が必要なのか、ってのは、副作用があるプロパティを書くことが出来る限り不必要にならない。
Queueみたいなもののgetのアクセサが、デキューして返すみたいなコードだと、デキューせずに先頭を見る方法が無くなる。

>>534
段取りがおかしい。「設計書のテストの仕様書」が成立するためには、「設計書の設計書」が必要。
なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。
「xxの処理は漏れていないか」は「xxの処理が必要だと定義されている」から書ける。
そのための要件は、すり合わせと設計変更申請のレビューと相手方、担当者の連名の捺印で担保する。

>>535
あるよ。
組み合わせが妥当な手段ではこれ以上ないと言う事が、数が少なくなればなるほど簡単になる。

0539デフォルトの名無しさん2017/04/21(金) 22:34:09.19 ID:TFy/T03e

>>538
> なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。

設計書を書く → その設計書のテストを書く
何の問題もないじゃないか

0540あ2017/04/21(金) 22:34:35.69 ID:AJ6tejAv

>>537
getter,setterとプロパティってシンタックスシュガー以上の違いある？Kotlinとか、getterとsetterを暗黙のプロパティに変換してくれるが。

0541あ2017/04/21(金) 22:35:44.20 ID:AJ6tejAv

>>539
おまえふざけんなよw

0542あ2017/04/21(金) 22:37:04.70 ID:AJ6tejAv

実装してからのテスト作成って何の意味があるのか意味がわからん。

0543デフォルトの名無しさん2017/04/21(金) 22:42:23.85 ID:TFy/T03e

>>542
確認作業だろ？

そもそも似たようなことは検収作業でやってるだろ

0544デフォルトの名無しさん2017/04/21(金) 22:43:24.15 ID:rPWpf+kQ

カプセル化は不要でおｋ?

0545デフォルトの名無しさん2017/04/21(金) 22:44:14.67 ID:YTf7CJ3G

>>544
カプセル化は必要でおｋ

0546デフォルトの名無しさん2017/04/21(金) 22:45:28.27 ID:cmecYv9F

>>538
んなことはわかってるっつーの
だからなんだよ
getter setterなんていらねーよという話から始まってる議論になんの関係がある

0547デフォルトの名無しさん2017/04/21(金) 22:49:35.08 ID:rPWpf+kQ

>>545
じゃあどうして>>506からの流れでカプセル化必要派は壊れてしまうん?

0548デフォルトの名無しさん2017/04/21(金) 22:51:43.93 ID:YTf7CJ3G

>>547
そうか
理解できないから壊れた判定して逃げるんだな

0549デフォルトの名無しさん2017/04/21(金) 22:52:25.01 ID:1EW2mi9U

おまえら相変わらず低レベルな会話してんなww

0550デフォルトの名無しさん2017/04/21(金) 22:54:33.29 ID:JwbSy4qm

アクセッサの記述性は、下に行くほど上品とする
すでに酒飲んでこれ書いてるから、異論の必要は無い

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もなぜか効かない設定

0551デフォルトの名無しさん2017/04/21(金) 22:56:49.22 ID:YTf7CJ3G

>>549
ぜひ収拾つけてくれ
俺にはどーもできん

0552デフォルトの名無しさん2017/04/21(金) 22:57:14.58 ID:cQz9sGMN

至高の言語はswiftだよ
swiftが全ての正解

0553デフォルトの名無しさん2017/04/21(金) 23:05:20.32 ID:IMFbV+tE

>>552
#ifdefのくせになまいきな

0554デフォルトの名無しさん2017/04/21(金) 23:07:41.24 ID:rPWpf+kQ

>>548
じゃあ、設計書をかく前提の開発でカプセル化が必要な理由を説明してよ

0555デフォルトの名無しさん2017/04/21(金) 23:15:04.82 ID:IMFbV+tE

実際に不正な操作がされていないということを保証できるから

設計書ベースだと、オブジェクト使うときは
規約をしっかり読んで、それに抵触しないよう用心してコーディングし、
変なことが起こった時
設計書の記述みて、コード上でオブジェクトの使用箇所全部洗って、
操作の規約が守られてるかどうか逐一人間がチェックして、
それではじめてprivateの一言と同じ成果となるのだ

やってられんしそもそも間違えるし

0556デフォルトの名無しさん2017/04/21(金) 23:16:10.52 ID:YTf7CJ3G

利用者はちゃんと設計書を確認しながら使うとは限らないって何度も言えば、、、

0557デフォルトの名無しさん2017/04/21(金) 23:16:16.72 ID:fRfyQmKB

>>378
たとえば、インスタンス変数aに依存＆結構コストのかかる計算で決まる値bがあったとき
bをインスタンス変数bにキャッシュしておくほうが得だよね？
publicにしたaの変更をどうやってフックするの？

0558デフォルトの名無しさん2017/04/21(金) 23:22:50.81 ID:rPWpf+kQ

>>555
バカなんだね
君はもうレスしなくていいよ

0559デフォルトの名無しさん2017/04/21(金) 23:24:54.21 ID:1EW2mi9U

>>551
普通の人間には無理w
ID:rPWpf+kQは頭の出来が異次元すぎるwww

0560デフォルトの名無しさん2017/04/21(金) 23:26:01.68 ID:JwbSy4qm

バカじゃない人間なら
機械語とバイナリエディタでOS作れてもおかしくない

0561デフォルトの名無しさん2017/04/21(金) 23:27:08.71 ID:IMFbV+tE

ただの煽りかげんなり
ほんとに信じて言ってるのかと思ってた

0562デフォルトの名無しさん2017/04/21(金) 23:28:45.45 ID:YTf7CJ3G

>>559
そーだよなぁ
ただ喚くだけだしね

0563デフォルトの名無しさん2017/04/21(金) 23:34:32.77 ID:V+qA1SkC

>>393
dllやクラスファイルの形で、コードの無いクラスもあるんやで？
クラスやメソッドは紙やWebのみってのが。

0564デフォルトの名無しさん2017/04/21(金) 23:38:07.22 ID:rPWpf+kQ

>>563
それとカプセル化になんの関係があるの?
よく考えて発言してねバカなんだから

0565デフォルトの名無しさん2017/04/21(金) 23:48:31.04 ID:go/6WchZ

>>557
ずれたコメントさせてもらうが、俺ならそのbを計算した都度出力して、自らはキャッシュしない方策を考えるな。

0566デフォルトの名無しさん2017/04/21(金) 23:52:18.75 ID:YTf7CJ3G

>>564
よく考えて発言してね
まぁ自分がバカと認識してるだけマシだけど

dllで提供されたものが他のものに依存してて単体で動かないとか、動くけど他のdllで得るはずの値を利用すること前提だとしたらその前提を知らない奴はうまく使えない
内部の処理を隠蔽し独立した動きを提供すればいいだけなんだよ

0567デフォルトの名無しさん2017/04/21(金) 23:53:01.61 ID:V+qA1SkC

ん？
カプセル化でprivateしてないと勝手にフィールド書き込んでしまう恐れがある。
コード無いからprivateにする意味ある。
そんな例。

あ、publicなフィールドを紙やWebに書かなければいいと言うのはなしね。
ツールが抽出するんで。
手書きじゃ無いんで。

0568デフォルトの名無しさん2017/04/21(金) 23:54:06.38 ID:Ck7s6rRh

エンジニアガイジさあ…… 住処が荒廃したからってここに雑魚狩りに来るのやめなよ

0569デフォルトの名無しさん2017/04/22(土) 00:12:26.79 ID:EzjUI0a0

日を跨いだら突然おとなしくなったなぁ

0570デフォルトの名無しさん2017/04/22(土) 00:28:58.48 ID:OS/5Qg75

>>554
設計で呼び出し元に制限を規定するのであれば、試験仕様書には制限外の呼び出しはNGの試験が用意される
上記を満たす実装はカプセル化と呼ばれるのでは？