5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

1 :デフォルトの名無しさん:2017/04/02(日) 16:30:38.65 ID:n7h/bBRg
前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

2 :デフォルトの名無しさん:2017/04/02(日) 16:45:28.24 ID:n7h/bBRg
C 言語によるオブジェクト記述法 COOL ver.2
http://www.sage-p.com/process/cool.htm

3 :デフォルトの名無しさん: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 まとめ

4 :デフォルトの名無しさん:2017/04/02(日) 17:02:31.63 ID:n7h/bBRg
https://teratail.com/questions/37674

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

5 :デフォルトの名無しさん: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 ー)を導入し、抽象化を図っています。共通ファイルモデルでは、
> 関数ポインタやオブジェクト指向的な考え方†を採用したフレームワークを提供し、フアイル

6 :デフォルトの名無しさん: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

1 下記機能をオプションとして持つドアを設計せよ
  (a)ドアストッパー
  (b)ドアクローザー
  (c)ドアの向こう側を目視できるガラス
  (d)内部から外部の一方通行のみ目視できるのぞき穴

2. 1.で行ったクラス設計を破壊せずに下記性質を追加せよ
  (e)異なる耐火性
  (f)異なる開閉重量
  (g)鍵がついており、サムターンか電子錠である
  (h)異なる遮音性
  (i)開き方は右開き左開き、内開き外開きスライドのいずれもありえる
  (j)ドアノブはついていることもついてないこともある

3. 2.で行ったクラス設計を破壊せずに下記性質を追加せよ
  (k)犬猫はドアノブを回転させることはできない
  (l)犬猫はプッシュで動くドアなら、ある一定の重量以下で押すことができる
  (m)数匹の犬猫が同時にドアを押すと合計重量で押すことができる

7 :デフォルトの名無しさん:2017/04/02(日) 18:47:42.03 ID:w0zTGR96
おつかれさまでした

8 :デフォルトの名無しさん:2017/04/02(日) 20:12:49.88 ID:0XahTNwQ
>>6 1(a)(b)のRubyによる実装

http://ideone.com/or6JyE

9 :デフォルトの名無しさん:2017/04/02(日) 20:48:03.21 ID:TvISwdcG
>>6
ドアをどういうソフトウェアの中でどう使うのかを説明しろよ
それなしに”設計せよ”とか意味不明だぞ

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

10 :デフォルトの名無しさん:2017/04/02(日) 21:12:28.24 ID:DzpU0i7z
ドアクラスの設計に上位クラスの意思が必要なら、それはモジュール分解できてないってことじゃね

11 :デフォルトの名無しさん:2017/04/02(日) 21:21:56.68 ID:l1VJjSJU
>>9
こんなんで意味不明とか言ってたらついていけんぞ
このドアに猫を通すにはどうするとか言ってたんだから

12 :デフォルトの名無しさん:2017/04/02(日) 21:30:37.45 ID:TvISwdcG
>>10
〇〇がどう使われるかは全くわかりません
〇〇にはこれこれこういう属性(性質)がありえます
〇〇を設計せよ
ふぁい!?

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

13 :デフォルトの名無しさん:2017/04/02(日) 21:38:49.75 ID:DzpU0i7z
ドアストッパーは回転角に制限を与える
ドアクローザーは、半開状態時にゆるやかに閉状態へと変化する機構

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

14 :デフォルトの名無しさん:2017/04/02(日) 22:03:35.89 ID:TvISwdcG
建築家がCADで使うためのドアのモデル
ドアメーカーが生産管理のために使うためのドアのモデル
住宅メーカーが受注管理のために使うドアのモデル
ドア開け系のスマホゲームで使うためのドアのモデル

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

15 :デフォルトの名無しさん:2017/04/03(月) 01:16:59.01 ID:LFQkDYJE
>>14
よくよく考えてみるととても難しいが完全不可能ではないしょ、具体的にこんなドアと呼んでないからこそ
どんな状況とパターンでもドアをドアと呼ぶに相応しい共通項を見つけるゲームや
投げる物ではないし食べる物でもないしまぁある程度までは

16 :デフォルトの名無しさん:2017/04/03(月) 11:28:24.86 ID:MWcUZH/3
なんでメソッド名って三単現じゃないことが多いの?

17 :デフォルトの名無しさん:2017/04/03(月) 12:06:00.26 ID:4MLmk5yA
開発者に嫌われているプログラミング言語 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

18 :デフォルトの名無しさん:2017/04/03(月) 12:20:09.66 ID:28dsjWMc
>>17
他のせんたくしが

19 :デフォルトの名無しさん:2017/04/03(月) 12:21:52.64 ID:28dsjWMc
>>17
他の選択肢を比較的簡単に選べるものが上位になってる気がする。
つまりdisりやすいっていう

20 :デフォルトの名無しさん:2017/04/03(月) 13:17:31.81 ID:DYsJriQe
>>1
糞みたいなテンプル貼るのやめろ

21 :デフォルトの名無しさん:2017/04/03(月) 19:08:53.61 ID:gZTdU5yD
>>17
名前さえ上がらないCobol

22 :デフォルトの名無しさん:2017/04/03(月) 19:16:57.14 ID:Upl31vzs
まだやってんの?

23 :デフォルトの名無しさん:2017/04/03(月) 20:08:09.88 ID:VDwG6zpG
>>22
最後にレスした奴が勝者だからな

24 :デフォルトの名無しさん:2017/04/03(月) 20:17:49.73 ID:Upl31vzs
勝ち負けってあったの?

25 :デフォルトの名無しさん:2017/04/03(月) 20:20:18.71 ID:7vHtJU9B
俺2chの議論で負けたことない

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

26 :デフォルトの名無しさん:2017/04/03(月) 20:23:36.71 ID:Upl31vzs
勝負してないじゃん

27 :デフォルトの名無しさん:2017/04/03(月) 20:54:50.17 ID:OUsiIH4G
土俵の下からヤジ飛ばしているだけで勝負している気になってるいつものあいつかw

28 :デフォルトの名無しさん:2017/04/03(月) 20:57:17.28 ID:LFQkDYJE
ウィナーオブジェクト作ろうぜ。とりあえずメソッドはコールだけ

29 :デフォルトの名無しさん:2017/04/03(月) 21:47:10.19 ID:7vHtJU9B
>>14
そこが決まってないからこそ
物事の捉えかたが人によって違うのがいいんだろ

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

30 :デフォルトの名無しさん:2017/04/03(月) 21:49:08.96 ID:XYXk6jFX
>>15
どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるのは
ソフトウェアの設計やプログラミングの話ではなく言語学や哲学における分節化の話
なので板違い

31 :デフォルトの名無しさん:2017/04/03(月) 21:57:16.66 ID:XYXk6jFX
>>29
どういうシステムでどういう使われ方をするドアを想定した結果なのかを示せば
少しはマシだったろうけどそれをやったやつ前スレで1人でもいたか?

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

32 :デフォルトの名無しさん:2017/04/03(月) 21:57:20.04 ID:LFQkDYJE
>>30
つまりオブジェクト指向は哲学と言うことだな。納得出来る

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

34 :デフォルトの名無しさん:2017/04/03(月) 22:05:09.73 ID:MrxLrKt6
>>30
> どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるのは

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

35 :デフォルトの名無しさん:2017/04/03(月) 22:18:18.28 ID:MrxLrKt6
なるほど、そうか。

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

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

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

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

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

36 :デフォルトの名無しさん:2017/04/03(月) 22:25:42.68 ID:VDwG6zpG
プログラミングが目的になっちゃうと
そういう思考になるのかしらん?

37 :デフォルトの名無しさん:2017/04/03(月) 22:25:47.59 ID:XYXk6jFX
どんな状況でもドアをドアと呼ぶに相応しい共通項を見つけるってのは
ドアという言葉を定義づけるのと同じこと

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

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

38 :デフォルトの名無しさん:2017/04/03(月) 22:42:21.43 ID:MrxLrKt6
そう。我々がやってるのは、要件でドアと定義されたものを
クラスに落とし込む作業なのだ。

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

39 :デフォルトの名無しさん:2017/04/03(月) 22:42:49.69 ID:MrxLrKt6
決して世の中にあるドアがどういうクラスかを
解析する仕事ではないのだ。

40 :デフォルトの名無しさん:2017/04/03(月) 23:09:18.39 ID:7vHtJU9B
>>31
同じドアを扱っているにもかかわらず
最初は小売りか設計かと思わせておいて
いきなり「猫に押される」っていうコンテキストも抽象度も異なるものが割り込んでくるのが
問題の肝

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

41 :デフォルトの名無しさん:2017/04/03(月) 23:57:11.85 ID:7vHtJU9B
なんかわからんけど急にしにたくなった

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

43 :デフォルトの名無しさん:2017/04/04(火) 00:32:31.54 ID:Y80clcxw
いいぞ。遠慮なく死ね

44 :デフォルトの名無しさん:2017/04/04(火) 00:33:57.09 ID:Tk79CS9z
現実世界をモデリングできているか、とかいう謎の評価基準

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

45 :デフォルトの名無しさん:2017/04/04(火) 01:01:13.36 ID:AiGPoot5
オブジェクト指向にむりやり難癖つけてるけど結局
「具体性を持たせることで取り回しが楽になった」に対して
「これには対応できるのか!」「こういう例外はどうだ!」って難癖てるだけだから
「で、おまえの棲んでるとこの方は取り回しどうなの?」って
隠れ家に光浴びせると黙って棲んでる泥に潜っていくというね…

46 :デフォルトの名無しさん:2017/04/04(火) 01:32:16.54 ID:QcgfrUUh
>>40
問題の肝でもなんでもないわw

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

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

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

47 :デフォルトの名無しさん:2017/04/04(火) 01:37:41.67 ID:TSsDdMVB
>>17
Swiftが入ってない
やり直し

48 :デフォルトの名無しさん:2017/04/04(火) 05:34:43.80 ID:ld6GL0Sw
キャットドア問題解決したのか?

49 :デフォルトの名無しさん:2017/04/04(火) 07:33:17.45 ID:gTa0RwdG
素材まで網羅した完璧なドアの設計を最初からしなくて良いのがオブジェクト指向の強みなんじゃね

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

50 :デフォルトの名無しさん:2017/04/04(火) 07:34:20.63 ID:gTa0RwdG
>>17
C#最高なだけじゃねえか

51 :デフォルトの名無しさん:2017/04/04(火) 15:08:10.80 ID:AeH3x9f/
今後も使い続けたいと思うかどうかの割合が低いもの

嫌われている

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

52 :デフォルトの名無しさん:2017/04/04(火) 18:42:21.83 ID:PnaBNYoq
データベース操作クラスって
アンチパターンらしいですけど
世間ではどうやって操作をまとめてるんですか?

53 :デフォルトの名無しさん:2017/04/04(火) 18:44:12.01 ID:pyoNKlrC
>>52
まず、アンチパターンだと言ってる人に聞いてみてください。

54 :デフォルトの名無しさん:2017/04/04(火) 19:01:23.29 ID:12S8JRG0
オブジェクト指向って、
プログラミングを自動化=部品化してくれるものというイメージしかない。
プログラマはプラモデルを組み立てているような感覚。

55 :デフォルトの名無しさん:2017/04/04(火) 19:22:07.15 ID:6xG2515u
>>52
レコードセットとかフィールドとかトランザクションを抽象化することの話?

56 :デフォルトの名無しさん:2017/04/04(火) 19:48:05.98 ID:XraiJtPm
DAOみたいなのがクソなだけで、アクセスを抽象化したクラスは必要。

57 :デフォルトの名無しさん:2017/04/04(火) 19:54:26.70 ID:bhbbdSm0
>>54
これがオブジェクト指向の一つの存在パターンやしな
スマホアプリとかの画面パーツはこれで配布してるし

58 :52:2017/04/04(火) 20:11:51.69 ID:PnaBNYoq
操作がクラス名としておかしいと、
何かの読み物で読みました

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

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

59 :デフォルトの名無しさん:2017/04/04(火) 20:18:23.65 ID:y0lCbigz
それってUpdateHogeクラスみたいなのがあるってことなの?
Commandパターンとかなら理解できるが
データベース操作用にそういうクラスは普通作らないわな

60 :デフォルトの名無しさん:2017/04/04(火) 20:57:28.90 ID:pJiiTfw5
>>56
その抽象化がDAOやろ?

61 :デフォルトの名無しさん:2017/04/04(火) 21:01:19.65 ID:eKQOUvI0
DAOクラスの設計までごちゃごちゃ言い出すのがオブジェクト指向

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

62 :デフォルトの名無しさん:2017/04/04(火) 21:08:11.49 ID:QcgfrUUh
>>61
説明だけなら数分もあれば終わるだろうから
それ聞いて接続できるまでの時間はお前次第だと思う。

63 :デフォルトの名無しさん:2017/04/04(火) 21:08:42.56 ID:8WGG2cnP
extensionがすべて解決してくれる…!

64 :デフォルトの名無しさん:2017/04/04(火) 21:09:58.53 ID:pJiiTfw5
でもDAOが糞面倒なのは同意だが

65 :デフォルトの名無しさん:2017/04/04(火) 21:26:31.39 ID:y0lCbigz
>>60
リポジトリ

66 :デフォルトの名無しさん:2017/04/04(火) 21:38:41.73 ID:bhbbdSm0
db操作クラスっていかんのか
名前の通りdbから変数やデータ取り出して入れる専用クラスって意味でいいんだよな?

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

67 :デフォルトの名無しさん:2017/04/04(火) 21:57:16.59 ID:ld6GL0Sw
db操作クラスにキャットドアつけよーぜ!

68 :デフォルトの名無しさん:2017/04/04(火) 23:04:38.14 ID:eKQOUvI0
>>62
絶対に数分じゃ説明できない

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

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

69 :デフォルトの名無しさん:2017/04/05(水) 00:16:02.14 ID:Zf7glq/Z
>>68
猫の生態とは例えばどんなことを
お前は説明するの?

70 :デフォルトの名無しさん:2017/04/05(水) 00:38:08.73 ID:yRUZ/Ldq
オブジェクト指向ってこういうやつやろ!?が酷すぎて
田舎の中学生が「ぼくのかんがえたアメリカ人」の作り話を大人にしてるみたいになっとるな。

71 :デフォルトの名無しさん:2017/04/05(水) 00:38:34.63 ID:hA0nFIPv
>>60
ちゃう。抽象化を間違っちゃったのが、DAO

72 :デフォルトの名無しさん:2017/04/05(水) 00:56:26.96 ID:T1xSqOuQ
クラス名が名詞じゃないDB操作クラスってマジどういうの?

73 :デフォルトの名無しさん:2017/04/05(水) 08:19:13.48 ID:RcS41rYJ
>>71
どう間違ってるの?

74 :デフォルトの名無しさん:2017/04/05(水) 09:38:42.71 ID:Zf7glq/Z
俺がDAOの存在理由が理解できないから、間違い

75 :デフォルトの名無しさん:2017/04/05(水) 10:59:33.50 ID:1lx41BrP
>>74
【が】が多い

76 :デフォルトの名無しさん:2017/04/05(水) 15:50:39.12 ID:UwNB2dkT
>>74
存在が間違ってる奴本人が自己紹介

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

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

77 :デフォルトの名無しさん:2017/04/05(水) 21:47:59.72 ID:ABzSOhTe
オブジェクト指向は命名が重要だけど、DTOにはなんて名前付けてますか?

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

78 :デフォルトの名無しさん:2017/04/05(水) 22:31:27.34 ID:T1xSqOuQ
個人的にはHogeDaoとかHogeDtoみたいなのがたくさんあるとやる気なくす
HogeQueryとかHogeCommandとかHogeJsonみたいなもう少し意味のある名前がいい

79 :デフォルトの名無しさん:2017/04/05(水) 22:56:14.24 ID:YCJsuu6b
>>78
お前の個人的なやる気なんか知らないが、
何でもかんでもDTO作りまくる設計は、確かにアホ

80 :デフォルトの名無しさん:2017/04/05(水) 23:31:52.52 ID:ABzSOhTe
ほぼストアドでシステム開発してる人が
最近の連中は技術が無くてストアド書けないと嘆いていたのですが
ストアドでオブジェクト指向は出来るんですか?

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

81 :デフォルトの名無しさん:2017/04/06(木) 00:05:36.90 ID:F4y9oj5j
SQL serverならSQL clrが使えるはず

82 :デフォルトの名無しさん:2017/04/06(木) 01:57:21.96 ID:FGV9lFi+
なぜにストアドでオブジェクト指向!?

83 :デフォルトの名無しさん:2017/04/06(木) 04:16:30.36 ID:2G8EDGPv
>>80
一応Ora限定で出来たと思うけど、Web方面だと
エッジサーバ側であれこれするからストアドいらん気もするよ
業務系だとストアド一本で職になるようだが

84 :デフォルトの名無しさん:2017/04/06(木) 04:54:01.44 ID:2G8EDGPv
1クラスについて、最低1in/1out(interface)を作るよう指示されたことあったな
全てのクラスについて

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

85 :デフォルトの名無しさん:2017/04/06(木) 05:56:27.93 ID:8G48c3ze
なんでもストアドでやるのはバッドノウハウだが使うべき所では使わないとくっそ遅いシステムが出来上がるぞ

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

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

86 :デフォルトの名無しさん:2017/04/06(木) 09:05:31.52 ID:sp2ENUYJ
>>76
最終的な正解が書いてあるサイトはどこですか

87 :デフォルトの名無しさん:2017/04/06(木) 09:40:42.68 ID:rNIgAdOn
>>85
その話のどこにオブジェクト指向が関係するのか?

88 :デフォルトの名無しさん:2017/04/06(木) 10:32:51.49 ID:bi7gIbpv
第 (N+1) 次オブジェクト指向問答
https://togetter.com/li/1097950

89 :デフォルトの名無しさん:2017/04/06(木) 12:29:44.71 ID:GOr1AWzR
>>82
オブジェクト指向と言わず
共通の開発手法があるのかなと

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

90 :デフォルトの名無しさん: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.

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

92 :デフォルトの名無しさん: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!

93 :デフォルトの名無しさん:2017/04/06(木) 13:41:15.62 ID:fGciOGwI
>>92
ね ぼ け る な!

94 :デフォルトの名無しさん:2017/04/06(木) 18:06:11.40 ID:7ga4e71i
オブ農って何ですか?

95 :デフォルトの名無しさん:2017/04/06(木) 18:24:59.98 ID:FGV9lFi+
>>92
気持ちの伝わるいい返しだな

96 :デフォルトの名無しさん:2017/04/06(木) 18:36:07.83 ID:FGV9lFi+
>>89
ストアドは基本SQLだからDB設計出来る程度のリレーショナルモデルの知識あれば十分
技術うんぬん言うほと難しい話じゃない DBが違えば中身はいろいろと違ってくるけどね

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

97 :デフォルトの名無しさん:2017/04/06(木) 22:21:27.75 ID:OOQlb81T
制御文減らすための文法じゃないの?

98 :デフォルトの名無しさん:2017/04/06(木) 23:19:03.66 ID:fGciOGwI
>>95
伝わるか! ボケナス!

99 :デフォルトの名無しさん:2017/04/07(金) 07:14:09.24 ID:mWTY/96m
データベースのモデリングした後
オブジェクト指向のために
クラス設計すると、エンティティの
抽出とか同じ事をしている気に
なってくるんですが

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

100 :デフォルトの名無しさん:2017/04/07(金) 09:46:16.48 ID:xCtKbZyH
>>99
そのためにO/Rマッパーがある。
O/Rマッパーを使うとデータベースのモデリングを
クラスで表現できるから、そのまま移植すれば良い

101 :デフォルトの名無しさん:2017/04/07(金) 10:24:46.37 ID:IERj5jiz
ORマッピングすればDaoなんていらんね

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

103 :デフォルトの名無しさん:2017/04/07(金) 11:05:00.66 ID:Bku+sAks
ストアドプロシージャは、共有メモリや通信を目的に設計されていない。
なんかの結果を通信用に設けたテーブルに書いて、そのテーブルを別の主体が参照して連動させるとかオーバヘッドが多く、排他が冗長になり、パフォーマンスがでない。

104 :デフォルトの名無しさん:2017/04/07(金) 12:51:44.94 ID:l4Q0lLSH
>>95
気持ちのわるいいい返しだな

と読んでしまった

105 :デフォルトの名無しさん:2017/04/07(金) 14:06:58.01 ID:IIlb/TvM
>>102,103
基本的に何言ってるかよくわからない。

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

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

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

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

106 :デフォルトの名無しさん:2017/04/07(金) 18:38:30.82 ID:Er4jaX4h
最初はデータ中心アプローチでいいよ

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

107 :デフォルトの名無しさん:2017/04/07(金) 19:36:14.64 ID:vUIUfIKH
思ったよりスレッド周りで手こずったけど>>8をPHPで書いてみた

http://ideone.com/lcnAEj

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

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

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

109 :デフォルトの名無しさん:2017/04/08(土) 12:16:30.94 ID:AqrMKRmZ
ここ、何のスレだっけ?

110 :デフォルトの名無しさん:2017/04/08(土) 13:06:18.31 ID:MgZOgx+n
マルチスレッドわろw

111 :デフォルトの名無しさん:2017/04/08(土) 13:31:56.58 ID:D50K8DvF
よくわからないことを喚き散らすやつの隔離スレだよ

112 :デフォルトの名無しさん:2017/04/08(土) 13:51:19.98 ID:MmqHTY99
まともにキャットドアもデータベース接続もできないゴミが、僕が使ってる言語のライブラリをだしにしてホルホルするスレだよ

113 :デフォルトの名無しさん:2017/04/08(土) 14:06:38.04 ID:FmwPLc4P
お疲れ様でした!

114 :デフォルトの名無しさん:2017/04/08(土) 17:16:52.66 ID:6tEdYN6j
>>112
やはりキャットドア問題を解決することなく次にはいけんな

115 :デフォルトの名無しさん:2017/04/08(土) 18:27:20.39 ID:ZmPKT6lF
>>108
集約関数もバッチ処理も理解できないやつは
いちからやり直すかプログラミングから足を洗うかしてくれ

116 :デフォルトの名無しさん:2017/04/08(土) 19:54:52.03 ID:FmwPLc4P
>>114
あんただけだよいつまでもキャットドア問題とか言ってんの

117 :デフォルトの名無しさん:2017/04/09(日) 01:56:39.35 ID:+d/g4xuk
要件の一つに「Oraにロックインされるの勘弁」があるとマッパー必須

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

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

118 :デフォルトの名無しさん:2017/04/09(日) 02:27:20.83 ID:S92Irkmv
>>117
設計書なかったんだ、ははワロス

119 :デフォルトの名無しさん:2017/04/09(日) 02:34:17.14 ID:+d/g4xuk
>>118
設計書がどうこうとかじゃなくて、「おにぎりスタッバー」程度余裕で超えるド畜生
丸尾末広とか風船クラブ級の理解不能レベル

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

120 :デフォルトの名無しさん:2017/04/09(日) 02:39:11.61 ID:+d/g4xuk
むしろ1関数5000行if12段の脅威を感覚でわからんとかヤバいな

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

121 :デフォルトの名無しさん:2017/04/09(日) 02:50:02.23 ID:+d/g4xuk
一応言っておくが、俺はWAISテストで引っかかってるんで3か4しかわかんねぇようだ
まぁそのくらいあればシノギはできるようだがね

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

122 :デフォルトの名無しさん:2017/04/09(日) 08:12:06.51 ID:MBRFLDgA
if12段が*最低*でも2048*くらい*分岐って計算の方がヤバい

123 :デフォルトの名無しさん:2017/04/09(日) 08:18:43.92 ID:BIX5wjPO
分岐を志向するか統合を志向するかで無能か有能か分かれそう

124 :デフォルトの名無しさん:2017/04/09(日) 08:49:12.98 ID:Zg/bzUyC
と言いますと?

125 :デフォルトの名無しさん:2017/04/09(日) 09:36:40.13 ID:Ch2od0MN
無理なクラスタリングはハンマー釘病になる
その場その場に応じた最適解を選べばいいだけ

126 :デフォルトの名無しさん:2017/04/09(日) 11:52:37.41 ID:cTj84sSr
釘宮病ってなんだ?

127 :デフォルトの名無しさん: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;
}}}}}}}}}}}}

128 :デフォルトの名無しさん: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;
}

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

129 :デフォルトの名無しさん:2017/04/10(月) 02:17:00.84 ID:ogTJ3oaz
>>128
先に言えハゲ

130 :デフォルトの名無しさん:2017/04/10(月) 02:17:56.14 ID:f5bfXI8/
はげてねーよはげ

131 :デフォルトの名無しさん:2017/04/10(月) 07:53:31.28 ID:1VtPDmxC
>>130
ハゲろ

132 :デフォルトの名無しさん:2017/04/10(月) 08:53:35.90 ID:SOLotzzn
ガキかよ...

133 :デフォルトの名無しさん:2017/04/10(月) 12:33:19.05 ID:dyJkQ9HN
>>132
うるせー、ハゲ

134 :デフォルトの名無しさん: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に何が書かれてるのかしらんが、正しく読み取れてないのでは?

135 :デフォルトの名無しさん:2017/04/11(火) 04:41:06.97 ID:mchlWSiU
>>134
あーうん、そんなもんだねぇ2048じゃなかったな

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

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

136 :デフォルトの名無しさん:2017/04/11(火) 07:15:24.21 ID:8/HzfseJ
物理クラス設計にDTOって書きますか?

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

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

137 :デフォルトの名無しさん:2017/04/13(木) 07:07:56.79 ID:FYxnOP1R
社員クラスと所属クラスがあって
年月を問い合わせたら
その年月時点での所属を返すように
したいのですが、どちらのクラスに問い合わせるのが正しいと思いますか

138 :デフォルトの名無しさん:2017/04/13(木) 07:18:59.41 ID:m/ZfxtWH
おいらなら、社員クラスに所属クラスを埋め込むが。
と言うか、所属はクラスである必要すら感じない。
構造体でよく無いか?

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

140 :デフォルトの名無しさん:2017/04/13(木) 09:29:06.54 ID:i0SFiNXj
>>137
とりあえず社員クラスと所属クラスと年月の関係を書くように

141 :デフォルトの名無しさん:2017/04/13(木) 11:36:09.37 ID:Wjez3hz+
所属クラスって名前でいいのか?
部署クラスとかが普通だと思うな

142 :デフォルトの名無しさん:2017/04/13(木) 20:19:04.83 ID:U0NTTHzz
所属クラスは確かにおかしいですね
部の下にグループがあるので部署という名前は避けたのですが
部署クラスがグループ教えてくれるのはなんら問題ないことに気付いたので部署クラスに改名しました

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

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

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

143 :デフォルトの名無しさん:2017/04/13(木) 21:34:32.88 ID:kfgJyhKZ
>>142
社員がわかっているときは、社員に聞けばいいし、
部署がわかっている場合は、部署に聞けばいい。
どちららでもOKだし、ちゃんと作るならば
どちらからでもできるようにする

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

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

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

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

145 :デフォルトの名無しさん:2017/04/14(金) 01:10:42.96 ID:DK6sdjwT
>>137
どっちでもええ、ダメだったら直すまでだ

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

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

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

146 :145:2017/04/14(金) 01:15:51.93 ID:DK6sdjwT
とりあえず目的が「特定の社員の所属状況を引く(あるいは特定社員の在籍履歴を引きたくなって機能追加)」なら
社員に持たすだろうかな
個人のトラッキングが目的なら個人を扱うクラスが責任取るべき

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

147 :デフォルトの名無しさん:2017/04/14(金) 01:21:47.69 ID:5G8BkNCQ
>>145
Java関係ないやん

148 :デフォルトの名無しさん:2017/04/14(金) 01:36:29.65 ID:DK6sdjwT
>>147
interfaceがうるさい連中の筆頭はJavaっ子なんでなあ
パっと思いついたのがアレだった

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

149 :148:2017/04/14(金) 01:36:57.02 ID:DK6sdjwT
varがあればダックタイピングもできるだろうしな

150 :デフォルトの名無しさん:2017/04/14(金) 03:32:44.79 ID:DK6sdjwT
もう寝るか

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

151 :デフォルトの名無しさん:2017/04/14(金) 07:12:34.16 ID:n5pL5Dn8
意外とどちらでも良いんですね

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

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

152 :デフォルトの名無しさん:2017/04/14(金) 07:31:08.07 ID:dq/wP8H9
「現実世界」なんて忘れて

153 :デフォルトの名無しさん:2017/04/14(金) 09:07:05.40 ID:aK3T4zVf
>>150
はい?

154 :デフォルトの名無しさん:2017/04/14(金) 21:02:07.32 ID:KZAGQEdK
クラス構造に凝っても意味ないじゃん

155 :デフォルトの名無しさん:2017/04/14(金) 23:49:30.63 ID:Sw6Rs9Qs
そろそろjavaは遺物扱いで良いんじゃないかって思ってる

156 :デフォルトの名無しさん:2017/04/14(金) 23:57:33.02 ID:2Ku103cF
Cobolですら現役なのに

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

157 :デフォルトの名無しさん:2017/04/15(土) 00:00:58.14 ID:PX53Hw9S
うまく作れないことを言語のせいにしたいだけだと思ってる

158 :デフォルトの名無しさん:2017/04/15(土) 00:03:32.65 ID:0ry10bQQ
その通りやで

159 :デフォルトの名無しさん:2017/04/15(土) 00:06:46.85 ID:0ry10bQQ
ところでそろそろjavaにも型推論追加された?

160 :デフォルトの名無しさん:2017/04/15(土) 00:14:08.96 ID:b29XQl7t
されねーしいらねーし

161 :デフォルトの名無しさん:2017/04/15(土) 00:24:58.93 ID:PX53Hw9S
javaスレでどうぞ

162 :デフォルトの名無しさん:2017/04/15(土) 00:28:17.04 ID:0ry10bQQ
じゃあ何の話するの?

163 :デフォルトの名無しさん:2017/04/15(土) 00:32:30.38 ID:PX53Hw9S
何もなけりゃ何も話さなくていいんだよ

164 :デフォルトの名無しさん:2017/04/15(土) 00:37:51.34 ID:uwyLFIA1
好き嫌いだよ好き嫌い
それでいいよ

165 :デフォルトの名無しさん:2017/04/15(土) 09:43:01.13 ID:01wvAL9A
>>134
でも分岐数4Kって訳でもないんだろ?
それ2048の関数があるのと変わらない

166 :デフォルトの名無しさん:2017/04/16(日) 02:05:28.12 ID:IBph2Vsu
>>156
Javaはもともと組み込み言語だったんで、真剣にやると
他言語ではできることがJavaではできないってことがよくある

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

167 :166:2017/04/16(日) 02:23:40.59 ID:IBph2Vsu
Struts1 + Hibernate固定とか、Spring + Hibernate固定の現場で、
お客さんからハナシ聞いて1〜2週間後に納品、みたいなのが許されるならJavaでも構わないと思う
まあアレだ「エラーが絶対に出ないこと」ならJavaのほうが有利なのは認めるんで

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

168 :デフォルトの名無しさん:2017/04/16(日) 02:41:47.00 ID:cCOM2/u0
>.166
組み込み言語だったことが理由で
他の言語で出来てJavaで出来ないことって何?

169 :デフォルトの名無しさん:2017/04/16(日) 02:42:52.99 ID:cCOM2/u0
>>167
エラーが多少出てもいいの
「多少」ってどのくらい?

170 :デフォルトの名無しさん:2017/04/16(日) 05:04:51.94 ID:IBph2Vsu
>>168
lispあるいはrubyのlambaか、groovyかscalaのクロージャ
pythonのは不完全だ
mixinとかについてはもうどうでもいいや

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

171 :デフォルトの名無しさん:2017/04/16(日) 09:40:21.87 ID:0mT+BZRD
オブジェクト指向と言ったらjavaがメジャーだしjavaが出来れば良いと思う

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

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

Rubyは俺が知らないw

172 :デフォルトの名無しさん:2017/04/16(日) 09:44:29.62 ID:0mT+BZRD
VB.NETでオブジェクト指向してる人間って2割居ないんじゃ無いかと思う
構造化プログラムしてるのが5割で、残りは非構造化プログラムってイメージ

173 :デフォルトの名無しさん:2017/04/16(日) 10:02:40.78 ID:3arFtvKs
cobolerやVBerがjavaやったらやっぱり同じだよ

174 :デフォルトの名無しさん:2017/04/16(日) 10:24:00.81 ID:pKwaze4n
>>171
C#erがVB程度しか使いこなせて無いかどうかは、Linq使いこなせるかどうかで大体判別可能。

175 :デフォルトの名無しさん:2017/04/16(日) 10:44:52.25 ID:deLvCvQZ
JavaとかRubyは純粋指向の人が多いような気がする

176 :デフォルトの名無しさん:2017/04/16(日) 13:37:47.43 ID:P5/zt8YK
純粋でメリットがあるのって、開発環境的なツールだけだよな。
人間にとっては、そのツールの恩恵を受けられる事に多大なメリットがあるけど、言語自体に直接的なメリットを感じないわ。

177 :デフォルトの名無しさん:2017/04/17(月) 09:26:03.38 ID:ZPW6EaCZ
>>171
レッテルでdisってるだけという

178 :デフォルトの名無しさん:2017/04/17(月) 09:29:54.87 ID:ZPW6EaCZ
てかC#の売りは、あのXMLでフォームを作れる点じゃないのかね。
泥のアプリに感覚が近い。
フレームワークなんだろうが、あれなしでC#を使うとは思えず、凝ったことはAPIやCOMを自分で使わないといけないような。
だから、業務系システムでC#はわかる。

179 :デフォルトの名無しさん:2017/04/17(月) 09:46:57.33 ID:NmJeD+FV
キャットドア問題は解決したの?

180 :デフォルトの名無しさん:2017/04/17(月) 09:53:49.97 ID:avieXFWj
>>178
はい?

181 :デフォルトの名無しさん:2017/04/17(月) 21:36:17.70 ID:kf1yWIvT
コーヒーを飲むって動作は誰にさせると上手くいきますか?

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

182 :デフォルトの名無しさん:2017/04/17(月) 21:47:08.34 ID:viGpNXOw
2つの物体の相互作用をどちらかを主語にしないと記述できない時点で
今主流のオブジェクト志向はクソ

183 :デフォルトの名無しさん:2017/04/17(月) 21:49:52.39 ID:avieXFWj
石原さとみのおっぱいに垂らした温いコーヒーをナメるのがベスト

184 :デフォルトの名無しさん:2017/04/17(月) 21:56:46.03 ID:LB/3uUQe
>>181
> コーヒーを飲むって動作は誰にさせると上手くいきますか?
メソッド=動詞を実行できる人

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

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

186 :デフォルトの名無しさん:2017/04/17(月) 22:16:18.42 ID:VvYNlkfx
オブジェクトはメソッド実行するときはたいてい目的語
でもたまに、処理を移譲するよなときは主語になる

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

187 :デフォルトの名無しさん:2017/04/17(月) 22:26:26.94 ID:n/MHuOf5
だいぶ前にこの類いのスレ立ててる奴が
「コーヒー」クラスが「ドリンク」メソッドで「プログラマー」に代入されてるジョークTシャツ持ってきて
「だからオブジェクト指向は〜」ってやってたのの本人による再放送でしょ。
キャットドア誰も相手してくれなくなったから。

188 :デフォルトの名無しさん:2017/04/17(月) 23:55:38.00 ID:a8QARk7l
メソッドは状態が変化する物に帰属させないとオブジェクト志向の意味ないよね

189 :デフォルトの名無しさん:2017/04/18(火) 00:38:27.27 ID:ibb6Zkrz
>>188
そんなことはないよ。

190 :デフォルトの名無しさん:2017/04/18(火) 07:13:33.23 ID:YLExNRL3
去年.NET3.5の新規開発で
VB9.0を選択しちゃうウチの職場は
未だにオブジェクト指向を導入していません

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

191 :デフォルトの名無しさん:2017/04/18(火) 09:09:55.12 ID:+QApwmMZ
その程度の仕事しかしてないということなので不要です

192 :デフォルトの名無しさん:2017/04/18(火) 09:59:29.58 ID:QQU8yDeJ
キャットドア問題も解決できないオブジェクト指向は不要

193 :デフォルトの名無しさん:2017/04/18(火) 12:33:10.21 ID:7gPK71Iv
NGワード:キャットドア
これでスッキリ

194 :デフォルトの名無しさん:2017/04/18(火) 13:42:04.65 ID:dT36T5gx
キャットドア厨はオブジェクト指向以外で問題解決してみてから言えよ
これやらないからカスなんだよ

195 :デフォルトの名無しさん:2017/04/18(火) 17:45:27.51 ID:QQU8yDeJ
>>194
オブジェクト指向以外に解決策を求めてる時点で草wwwwww

196 :デフォルトの名無しさん:2017/04/18(火) 17:58:40.72 ID:ymBV4AxE
cat.open(door), cat.open_door()
person.drink(cofee)

197 :デフォルトの名無しさん:2017/04/18(火) 20:10:28.20 ID:PoabM2Bb
何通りか解決してただろ
なんでリセットされてるんだよ

198 :デフォルトの名無しさん:2017/04/18(火) 20:35:48.45 ID:MNbxM32c
>>197
悪魔の証明と化してる

199 :デフォルトの名無しさん:2017/04/18(火) 21:39:51.91 ID:2/KqF/My
>>192
朗報だ
キャットドア問題をオブジェクト指向で完全に解決した
https://paiza.io/projects/9D_RVq0fdaUXDugXFTpp2g

200 :デフォルトの名無しさん:2017/04/18(火) 21:40:24.96 ID:2/KqF/My
オブジェクト指向のおかげです

201 :デフォルトの名無しさん:2017/04/18(火) 21:41:20.30 ID:2/KqF/My
オブジェクト指向完全に理解した、超簡単だった

202 :デフォルトの名無しさん:2017/04/18(火) 22:37:17.80 ID:PoabM2Bb
人間だけ中身からっぽでわろw

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

204 :デフォルトの名無しさん:2017/04/19(水) 10:30:31.20 ID:kYerY5of
>>189
カプセル化しないの?

205 :デフォルトの名無しさん:2017/04/19(水) 11:36:32.83 ID:ZFpUIjRr
>>199
n種類の操作主体がいて、m種類の操作対象があるとき、DoorOpener的なクラスをm個作り、それぞれにnこのメソッドを作るのか?
操作主体が一つ増えると、既存のm個のクラスにそれぞれ一つのメソッドを追加する必要がある
また、操作対象が一つ増えると、あらたにn個のメソッドを作成する必要がある

206 :デフォルトの名無しさん:2017/04/19(水) 12:10:38.64 ID:rIlDsUIc
>>205
ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな

207 :デフォルトの名無しさん:2017/04/19(水) 12:15:05.34 ID:rIlDsUIc
>>204
カプセル化は頭空っぽの木偶の坊のためにある
オブジェクト指向の本質とは程遠い

208 :デフォルトの名無しさん:2017/04/19(水) 12:20:37.70 ID:rIlDsUIc
継承もカプセル化もオブジェクト指向には必要ない
クラスを作る、つまり型を定義する事こそがオブジェクト指向

209 :デフォルトの名無しさん:2017/04/19(水) 12:29:42.19 ID:xWugx3VW
複数性が重要事項

210 :デフォルトの名無しさん:2017/04/19(水) 12:32:00.02 ID:rIlDsUIc
文字コードを相互に変換するときいったんウニコードに変換するように、対象や主体をそれぞれ抽象化オブジェクトに変換すればよいのかもね

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

211 :デフォルトの名無しさん:2017/04/19(水) 12:55:20.19 ID:rIlDsUIc
抽象化オブジェクトに変換を行うトランスフォーマクラスと抽象化オブジェクトに対する操作を行うプロセッサクラスがある

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

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

212 :デフォルトの名無しさん:2017/04/19(水) 12:55:21.77 ID:cvkGewar
pコードみたいだな

213 :デフォルトの名無しさん:2017/04/19(水) 12:56:19.07 ID:rIlDsUIc
やっぱオブジェクト指向最高だな

214 :デフォルトの名無しさん:2017/04/19(水) 13:42:18.93 ID:Rk+PkBJv
>>207
木偶の坊が何か実装するときに何も考えさせないためにカプセル化するんだと思ってたわ

215 :デフォルトの名無しさん:2017/04/19(水) 13:49:21.08 ID:ZFpUIjRr
>>206
> ドアを障子に変えてくれって要求があるかもしれないし、もしものことを考えて複雑に作るより今の要求を満たす必要最小限にしておけば作り直しやすいのじゃないかな
まあ、あのコードが最小限だとして、その範囲ですらOCPに違反してるんじゃないですかねって指摘なんだが。

216 :デフォルトの名無しさん:2017/04/19(水) 19:01:16.59 ID:rIlDsUIc
>>215
ocpは耄碌したメイヤおじさんの考えだろ
オブジェクト指向がブラッシュアップされる前の
無駄の塊だった頃の話だ

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

217 :デフォルトの名無しさん:2017/04/19(水) 19:03:57.03 ID:rIlDsUIc
>>214
オブジェクト指向が浸透するまでは有益だったかもしれないが、今や誰もがオブジェクト指向を熟知し使いこなす時代、カプセル化はロジックを不鮮明にするノイズでしかない

218 :デフォルトの名無しさん:2017/04/19(水) 19:06:43.59 ID:rIlDsUIc
メイヤおじさんは実装の継承を推奨する老害だからな
バージョン管理ソフト使えよと

219 :デフォルトの名無しさん:2017/04/19(水) 19:09:12.02 ID:rIlDsUIc
プレインクラスこそオブジェクト指向の本質

220 :デフォルトの名無しさん:2017/04/19(水) 19:29:36.25 ID:/l6NHl5b
>>217
不鮮明となるのであればそれは用件が曖昧であるためカプセル化できてないと俺は考える
エンジンの仕組みを知らなくてもアクセルを踏めば車は動くようにわざわざ考える必要もない事は隠蔽しちゃおうぜ!ってのがカプセル化だと思ってる

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

221 :デフォルトの名無しさん:2017/04/19(水) 19:35:54.11 ID:XuQTPPrh
フスマと回転扉で同じキャットドアで済むわけないじゃん
これを違うものとして組めないコードは問題

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

222 :デフォルトの名無しさん:2017/04/19(水) 19:37:09.40 ID:rIlDsUIc
>>220
それもそうだな

223 :デフォルトの名無しさん:2017/04/19(水) 19:39:26.07 ID:rIlDsUIc
>>221
ドアクラスの変数名をふすまにすればいと思うの
難しく考えずにシンプルな解決策を探そうよ

224 :デフォルトの名無しさん:2017/04/19(水) 19:45:45.55 ID:d/SqmCf2
>カプセル化はロジックを不鮮明にするノイズでしかない
寝言にもほどがある

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

225 :デフォルトの名無しさん:2017/04/19(水) 19:52:16.42 ID:XuQTPPrh
>>223
フスマと回転扉で同じキャットドアが使えると思ってらっしゃる?

226 :デフォルトの名無しさん:2017/04/19(水) 19:56:33.37 ID:qJxXjZRc
>>224
ほんとこれ

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

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

228 :デフォルトの名無しさん:2017/04/19(水) 20:01:49.80 ID:qOdNs+TP
>>224
依存しないように実装すれば良いが

229 :デフォルトの名無しさん:2017/04/19(水) 20:02:59.08 ID:qOdNs+TP
>>226
んなアホな、それは言い過ぎだわ
話盛ってるわ

230 :デフォルトの名無しさん:2017/04/19(水) 20:05:24.07 ID:d/SqmCf2
>>228
間違ってしちゃうかもしれないし、どっかで誰かがしちゃってるかもしれんだろ

231 :デフォルトの名無しさん:2017/04/19(水) 20:07:46.83 ID:d/SqmCf2
あまりにもオブジェクト指向が当たり前になりすぎて、それがもたらしてくれるものを忘れてるだけだ

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

232 :デフォルトの名無しさん:2017/04/19(水) 20:11:22.44 ID:/l6NHl5b
>>229
言い過ぎじゃない
カプセル化の意図は隠蔽と独立

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

233 :デフォルトの名無しさん:2017/04/19(水) 20:23:32.33 ID:XuQTPPrh
>>227
ちょっと絵に描いてみなよ

234 :デフォルトの名無しさん:2017/04/19(水) 20:26:00.72 ID:3xQf6WAc
『"このパーツの動作は保障されている"がないとプログラムは工業製品にならない』
ってのが始まりだしね。

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

235 :デフォルトの名無しさん:2017/04/19(水) 20:33:37.46 ID:lCKuRFX1
>>233
UMLでこの図なんていうんだっけ、名前は忘れたけどきちんと設計できる
https://www.fastpic.jp/images.php?file=0258982613.png

236 :デフォルトの名無しさん:2017/04/19(水) 20:34:11.59 ID:lCKuRFX1
端末変えたからID変わってるから

237 :デフォルトの名無しさん:2017/04/19(水) 20:35:16.70 ID:lCKuRFX1
>>232
それただのたとえ話じゃん
バグが寸分の狂いもなく立ちどころにわかるってのは言い過ぎだよ

238 :デフォルトの名無しさん:2017/04/19(水) 20:36:51.30 ID:lCKuRFX1
>>231
構造体に配列の長さと配列をセットで持たせればいいのに

239 :デフォルトの名無しさん:2017/04/19(水) 20:37:47.92 ID:/l6NHl5b
>>237
それは設計不足

240 :デフォルトの名無しさん:2017/04/19(水) 20:41:15.47 ID:lCKuRFX1
>>239
カプセル化に夢見すぎだよ
バグってる場所が3秒でわかるとか大嘘もいいところだよ
絶対嘘だね、どんなバグかもわかんないしさ

241 :デフォルトの名無しさん:2017/04/19(水) 20:41:33.40 ID:oz+MR2rn
まぁまぁ ロジックの中が見えてバグがどこで発生しているかもすぐに分かる純粋関数が最強ってことで

242 :デフォルトの名無しさん:2017/04/19(水) 20:42:40.87 ID:lCKuRFX1
カプセル・スリー・セカンド

243 :デフォルトの名無しさん:2017/04/19(水) 20:44:01.82 ID:/l6NHl5b
>>240
誰が三秒って言ったのよ
速度向上と言ったまでさ

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

244 :デフォルトの名無しさん:2017/04/19(水) 20:46:48.18 ID:lCKuRFX1
>>243
速度向上ならわかるけど

245 :デフォルトの名無しさん:2017/04/19(水) 20:49:45.97 ID:lCKuRFX1
>>241
純粋関数ってメソッドの中でも再代入を許さないんだっけ?
それって遅くない? モナド使わないと現実的に厳しくない?
すべてがモナドになればよくない? そうしてできたのがC言語です

246 :デフォルトの名無しさん:2017/04/19(水) 20:58:24.07 ID:oz+MR2rn
>>245
そして構造化プログラミング、モジュールプログラミング、オブジェクト指向のカプセル化と来て
関数型に戻るわけですな

247 :デフォルトの名無しさん:2017/04/19(水) 21:02:34.85 ID:lCKuRFX1
>>246
極端なところに正解はないと思うんだよ
バランスが取れているのが現実的に最も優れている
カプセル化してないオブジェクト指向が最高ってことになるのかな?とどのつまり

248 :デフォルトの名無しさん:2017/04/19(水) 21:08:35.02 ID:d/SqmCf2
ちょっとは人の話きけりょ

249 :デフォルトの名無しさん:2017/04/19(水) 21:10:34.01 ID:oz+MR2rn
カプセル化してないオブジェクト指向のメンバーなんて
読みにくいグローバル変数みたいなもんじゃない?

250 :デフォルトの名無しさん:2017/04/19(水) 21:18:19.43 ID:lCKuRFX1
>>248
聞く、どうぞお話どうぞ

251 :デフォルトの名無しさん:2017/04/19(水) 21:20:38.66 ID:lCKuRFX1
>>249
グローバル変数とは全然違う
フィールドはオブジェクトに属しています
オブジェクトがなければありません
オブジェクトを作って初めて使うことができます
オブジェクトのライフサイクルと運命をともにするからこそ
オブジェクト指向なんです
finalをつけるのがデフォ

252 :デフォルトの名無しさん:2017/04/19(水) 21:41:01.53 ID:/l6NHl5b
>>247
極端だろうが何だろうが正解なんかないさ
おまえはおまえの思いでやればいい

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

253 :デフォルトの名無しさん:2017/04/19(水) 21:56:25.91 ID:lCKuRFX1
>>252
俺が俺の思いでやるのは当たり前のことだと思うんだよ
雨が降ったら傘をさせばいいと言ってるようなもの
当たり前じゃん?いう意味なくない?
プールで泳ぐときは服を脱げばいいみたいな
出かけるときは靴を履けばいいみたいな
価値観の違いにこだわってるのはそっちのほうなんじゃないかなって思いました

254 :デフォルトの名無しさん:2017/04/19(水) 21:59:29.16 ID:lCKuRFX1
カプセル化しないオブジェクト指向がモダンで優れた設計っていうのは
>>252と俺の共通認識としてあるわけだから、その上で思いを語っていただけたら

255 :デフォルトの名無しさん:2017/04/19(水) 22:03:04.69 ID:/l6NHl5b
>>254
俺はカプセル化推奨だぞ

256 :デフォルトの名無しさん:2017/04/19(水) 22:06:05.25 ID:lCKuRFX1
>>255
フィールドが全部finalだったらprivateなんて必要ないだろ?
つまり、カプセル化って必要なくない?

257 :デフォルトの名無しさん:2017/04/19(水) 22:07:41.10 ID:lCKuRFX1
隠すメリットより公開するメリットの方が莫大だと思わない?

258 :デフォルトの名無しさん:2017/04/19(水) 22:18:28.62 ID:lCKuRFX1
公開するメリット隠すデメリットを考えよう

259 :デフォルトの名無しさん:2017/04/19(水) 22:22:01.02 ID:/l6NHl5b
思わないなぁ
カプセル化って無駄を省いてわかりやすいものにして再利用しやすいよう作ることと思ってるからね

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

260 :デフォルトの名無しさん:2017/04/19(水) 22:26:31.08 ID:lCKuRFX1
>>259
なるほどね、それはあるね

261 :デフォルトの名無しさん:2017/04/19(水) 22:27:13.48 ID:lCKuRFX1
カプセル化完全に理解した

262 :デフォルトの名無しさん:2017/04/19(水) 22:34:52.50 ID:/l6NHl5b
おめでとう
まぁ俺はまだまだ勉強中だからうらやましいよ

263 :デフォルトの名無しさん:2017/04/19(水) 23:01:17.77 ID:KzpInSVx
>>256
通りすがりだが、年齢フィールドとか一定の幅に制限したい時に勝手に300歳とか設定されたら困るだろう。
だからprivateにしてメソッドやプロパティで0-120なりの範囲に制限するようにするんじゃないの?

264 :デフォルトの名無しさん:2017/04/19(水) 23:08:00.65 ID:qOdNs+TP
>>263
入力チェックをデータがやっていいものか
これは議論が別れるところですよ

265 :デフォルトの名無しさん:2017/04/19(水) 23:10:42.57 ID:2dTlCsss
>>208
代数的データ型で型を定義できるHaskellはオブジェクト志向言語だった……?

266 :デフォルトの名無しさん:2017/04/19(水) 23:12:01.85 ID:qOdNs+TP
>>265
代数的データ型とはなんぞや?

267 :デフォルトの名無しさん:2017/04/19(水) 23:13:00.35 ID:HSKBgTxb
「300歳なんてあるわけないからカチカチに型で数字の範囲を絞ればいいんだよ」
「300歳なんて異常な数字を送らないように送り手が責任を持つべきだ」
「300歳が送られてきても"数字がおかしい"って返事するようにすれば良くね」

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

268 :デフォルトの名無しさん:2017/04/19(水) 23:16:21.53 ID:qOdNs+TP
>>267
俺ならチェックせずに文字列のフィールドにそのままセットしちゃうね、純粋オブジェクト指向

269 :デフォルトの名無しさん:2017/04/19(水) 23:19:37.80 ID:qOdNs+TP
type c = a or b
みたいな?

270 :デフォルトの名無しさん:2017/04/19(水) 23:20:37.20 ID:qOdNs+TP
これもオブジェクト指向と言ってもいいでしょう!

271 :デフォルトの名無しさん:2017/04/19(水) 23:21:42.97 ID:HSKBgTxb
ちなみに最後のがいちばんオブジェクト指向っぽくて
大きな仕様変更に強いゆるさがあると思うけど
カチカチが好きなタイプのプログラマーは"ゆるさ"の部分が
許せないのだろうな。

272 :デフォルトの名無しさん:2017/04/19(水) 23:23:56.87 ID:KzpInSVx
>>264
え、でもそうでもなきゃ、データの外部でデータチェックとかは関数型言語や構造化プログラミング的な発想だけど。
副作用あるのに、その発想は危険過ぎない?
他の誰かがその外部のチェック用クラスを使ってくれる保証は無いよ?

273 :デフォルトの名無しさん:2017/04/19(水) 23:30:11.23 ID:qOdNs+TP
>>272
必要なら必要になったとき必要な人が自分で作れば良いじゃん、自由と自己責任の精神だよ、ルールで縛られたガチガチのオブジェクトじゃままならぬ事もあるでしょう!

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

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

275 :デフォルトの名無しさん:2017/04/19(水) 23:34:21.76 ID:HSKBgTxb
"誰がその数値に責任を持ってるか"っしょ。
それを明確にできてればそこを修正すればいいけれど
「私は知らない」「私は受け付けない」「私の責任ではない」って
例外の責任が見えないと責任者探しから始めなくちゃいけなくて
後から来たプログラマが死ぬ。

276 :デフォルトの名無しさん:2017/04/19(水) 23:37:47.94 ID:KzpInSVx
。。。オブジェクト指向は事なかれ文化の日本と相性悪いんじゃ無いかと思えてくる文言ダネ^^;

277 :デフォルトの名無しさん:2017/04/19(水) 23:39:15.89 ID:qOdNs+TP
テストすれば良いじゃん

278 :デフォルトの名無しさん:2017/04/19(水) 23:41:15.55 ID:qOdNs+TP
ちゃんとオブジェクトが連携できてるかなって
そうだよ僕たちには結合テストがあるじゃないか

279 :デフォルトの名無しさん:2017/04/19(水) 23:46:37.27 ID:qOdNs+TP
値を変換するコンバータクラスと値をチェックするバリデータクラスがあれば良いじゃないか
責務の分離だよ

280 :デフォルトの名無しさん:2017/04/19(水) 23:48:34.03 ID:qOdNs+TP
データ保持するクラスがチェックまでやるのは複雑すぎるよ、素直じゃない

281 :デフォルトの名無しさん:2017/04/19(水) 23:51:12.30 ID:qOdNs+TP
オブジェクトも大事だがコラボレーションも大事

282 :デフォルトの名無しさん:2017/04/19(水) 23:52:23.70 ID:zPBwEPLo
連投せずにまずは落ち着くのが大事

283 :デフォルトの名無しさん:2017/04/19(水) 23:57:15.78 ID:/l6NHl5b
目的の動きを満たせばだいたい正解なんだから熱くなるなよ
自分の意見を押し通したいのはわからんでもないがな

284 :デフォルトの名無しさん: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

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


こんなん草生える

285 :デフォルトの名無しさん:2017/04/20(木) 07:19:48.83 ID:JH3XDWGN
チェックも色々とデータが必要なとき多いしな

286 :デフォルトの名無しさん: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の五大原則のひとつとしてあげられるのが普通。

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

287 :デフォルトの名無しさん:2017/04/20(木) 14:18:44.61 ID:Wfe8Hvf2
継承は特定の親に縛られすぎるのであまりよくないね。ってなってるが
カプセル化はむしろ危険な直接アクセスを防ぐ意味で常識になってる気が。

288 :デフォルトの名無しさん:2017/04/20(木) 20:00:36.90 ID:OWrdGWgc
やっぱりインターフェースこそオブジェクト指向だよな

289 :デフォルトの名無しさん:2017/04/20(木) 20:17:41.83 ID:JH3XDWGN
>>287
でもカプセル化って汎用性悪いじゃん
変数1つアクセスできないだけで実現したいことできなくなっちゃうかもよ?

290 :デフォルトの名無しさん:2017/04/20(木) 20:22:03.18 ID:jeWo4Dft
それもうわざわざクラス使わずに構造体使っちゃいなよ

291 :デフォルトの名無しさん:2017/04/20(木) 20:29:03.08 ID:nHxDShTL
悪い依存関係はそのコードの利用者にコピベプログラムを強いる
これ経験則な

292 :デフォルトの名無しさん:2017/04/20(木) 20:37:59.47 ID:x1mUV01b
汎用性ならインターフェースと抽象クラスじゃねーの?

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

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

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

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

反論があるならどうぞ

294 :デフォルトの名無しさん:2017/04/20(木) 21:40:16.04 ID:NBs+Bll8
>>289
それ汎用性ちゃうで。
そんな内部実装の細かいとこ勝手に使われたら、バグ修正すらなんの影響があるか怖くてできんくなる。
結局特定用途にしか使えなくなる。

295 :デフォルトの名無しさん:2017/04/20(木) 21:44:56.84 ID:1ly+xIep
結局、privateっていうのは、

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

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

296 :デフォルトの名無しさん:2017/04/20(木) 21:46:00.98 ID:1ly+xIep
あ、もちろんprivateを使ったほうが良いって話だよ。

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

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

297 :デフォルトの名無しさん:2017/04/20(木) 21:47:30.56 ID:JH3XDWGN
>>294
クラスなんて使わなければいいのでは?

298 :デフォルトの名無しさん:2017/04/20(木) 21:53:58.83 ID:Rk6y34sG
>>293
帰納的な推理は往々にして間違うものなんだよ

299 :デフォルトの名無しさん:2017/04/20(木) 21:55:36.70 ID:1ly+xIep
>298
ちょっと邪魔しないで、

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

300 :デフォルトの名無しさん:2017/04/20(木) 21:56:45.24 ID:Rk6y34sG
マンコが本当にあるなら俺のチンコが純粋であることの説明がつかないみたいな

301 :デフォルトの名無しさん:2017/04/20(木) 21:57:23.53 ID:x1mUV01b
>>299
反論がでない=正当性が証明された
などと言うつもりかい?

302 :デフォルトの名無しさん:2017/04/20(木) 21:58:02.87 ID:Rk6y34sG
純粋チンコ型論理

303 :デフォルトの名無しさん:2017/04/20(木) 22:03:33.81 ID:Rk6y34sG
>>297
クラスわ使わないでどうやってデータを管理する?
配列か?

304 :デフォルトの名無しさん:2017/04/20(木) 22:07:49.44 ID:OWrdGWgc
カプセル化は正しい方向性だというのは賛成だが
lintで警告が出ないからという権威主義的な根拠はどうなのか

305 :デフォルトの名無しさん:2017/04/20(木) 22:10:46.32 ID:Rk6y34sG
>>290
構造体を使うとしてその構造体に連関する関数をどうやって整理する?

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

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

306 :デフォルトの名無しさん:2017/04/20(木) 22:12:10.00 ID:NBs+Bll8
>>297
せやな。
必要性がないと判断したんなら使わなければいいんじゃないか?
間違ってないと思うで。

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

307 :デフォルトの名無しさん:2017/04/20(木) 22:12:52.70 ID:x1mUV01b
自分で考えるってことをしないんだろ

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

むなしいね

308 :デフォルトの名無しさん:2017/04/20(木) 22:13:09.41 ID:1ly+xIep
>>301
それで何か問題あるの?

309 :デフォルトの名無しさん:2017/04/20(木) 22:14:14.53 ID:1ly+xIep
俺様が決めたルール(=害悪でしかない)が正当であると思ってるんだろうねw

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

310 :デフォルトの名無しさん:2017/04/20(木) 22:15:28.83 ID:Rk6y34sG
俺は今ガリレオさんの気持ちだ

311 :デフォルトの名無しさん:2017/04/20(木) 22:17:39.49 ID:x1mUV01b
>>308
おまえが満足するならそれでかまわないよ
別に誰かに認められるために学んでるわけじゃないし

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

312 :デフォルトの名無しさん:2017/04/20(木) 22:18:02.65 ID:Rk6y34sG
死に際にそれでも地球は回っていると言ってのけたガリレオさんも気持ちだ

313 :デフォルトの名無しさん:2017/04/20(木) 22:22:56.58 ID:1ly+xIep
>>311
そういうことは最初から言わないか?

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

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

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

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

314 :デフォルトの名無しさん:2017/04/20(木) 22:24:14.04 ID:Rk6y34sG
それでもカプセル化は必要ない
lintはろくでも無いクラス設計がまかり通っていたときの負の遺産だ、javabeansやcomが盛んに作られた時代の名残だ、隠蔽して守られるより公開して守られるクラス設計を目指すべき

315 :デフォルトの名無しさん:2017/04/20(木) 22:25:02.69 ID:Rk6y34sG
>>313
ソースは俺

316 :デフォルトの名無しさん:2017/04/20(木) 22:25:24.28 ID:1ly+xIep
補足しておくと「継承やカプセル化が害悪でしかない」という仮説が
正しいという信頼性がある(俺様が決めたルールではないとう)ソースを出せ。
という話ね

317 :デフォルトの名無しさん:2017/04/20(木) 22:26:09.67 ID:Rk6y34sG
ソースは現代のガリレオです
よろしくお願いします

318 :デフォルトの名無しさん:2017/04/20(木) 22:27:09.43 ID:x1mUV01b
>>313
見識が狭すぎるのは大変だよって言いたいだけさ

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

319 :デフォルトの名無しさん:2017/04/20(木) 22:29:33.08 ID:1ly+xIep
>>318
それを言うなら相手が違うだろ。

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

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

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

320 :デフォルトの名無しさん:2017/04/20(木) 22:30:20.01 ID:jeWo4Dft
>>305
俺の経験上はだけど、それオブジェクト志向じゃない方がむしろやりやすいで

321 :デフォルトの名無しさん:2017/04/20(木) 22:30:37.36 ID:nIwh3CMn
ソースは?の問いに対して
有無以外のレスを繰り返す相手を
それ以上いじめてはいけない

322 :デフォルトの名無しさん:2017/04/20(木) 22:31:02.97 ID:Rk6y34sG
昔は暗号化のロジックも隠すことで安全性を担保しようとしていたけど、駄目だったんだよ、現代ではロジックを公開できる暗号化こそが真に安全性を備えていることがわかっている

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

323 :デフォルトの名無しさん:2017/04/20(木) 22:32:10.96 ID:Rk6y34sG
>>319
ソースは今お前の目の前に居る
さあ

324 :デフォルトの名無しさん:2017/04/20(木) 22:32:34.93 ID:x1mUV01b
>>319
そうかい
ならば俺にソースを求めることが見当違いだということにも気づいてくれ

325 :デフォルトの名無しさん:2017/04/20(木) 22:33:31.06 ID:Rk6y34sG
>>320
どうやるん? クラス作らないとできなくない?

326 :デフォルトの名無しさん:2017/04/20(木) 22:33:55.62 ID:1ly+xIep
>>322
その理屈を使いたいならば、ロジックは公開すべきある。
共通鍵暗号方式でも公開鍵暗号方式でも、秘密鍵(データ)は隠すことで安全性を保っている。

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

327 :デフォルトの名無しさん:2017/04/20(木) 22:35:08.71 ID:Rk6y34sG
>>324
カプセル化が必要ないことを説明しろよ

328 :デフォルトの名無しさん:2017/04/20(木) 22:37:17.66 ID:x1mUV01b
>>327
だからカプセル化について推奨派って言ってんじゃねーか
推奨派が必要ないと考えるわけねーだろーが

少しは考えて発言しな

329 :デフォルトの名無しさん:2017/04/20(木) 22:37:44.90 ID:Rk6y34sG
>>326
秘密鍵はパスワードとかそういう類の物だからそもそもプログラム内に持たないんだよ

330 :デフォルトの名無しさん:2017/04/20(木) 22:39:55.49 ID:1ly+xIep
>>329
プライベート変数は、ファイルに保存しろって言いたいわけ?

331 :デフォルトの名無しさん:2017/04/20(木) 22:41:15.19 ID:Rk6y34sG
>>330
秘密鍵はプログラムに書くものじゃないと言いたいのさ

332 :デフォルトの名無しさん:2017/04/20(木) 22:43:19.76 ID:1ly+xIep
>>331
だから秘密にしたいデータ(他のクラスから参照されたくないデータ)は
プログラムに入れずにファイルにしておけってことだろ?

333 :デフォルトの名無しさん:2017/04/20(木) 22:43:43.47 ID:Rk6y34sG
>>328
派閥でどうこう言うんじゃなくていち個人として良心から発言していただきたい、カプセル化が必要ないんだという思いと向き合うべきだと言ってるんだよ

334 :デフォルトの名無しさん:2017/04/20(木) 22:44:37.36 ID:T8G8upSf
こいつ相当のバカだな

335 :デフォルトの名無しさん:2017/04/20(木) 22:44:47.88 ID:Rk6y34sG
>>332
違う違う秘密鍵はプログラムに書くものじゃないと言ってるんだよ

336 :デフォルトの名無しさん:2017/04/20(木) 22:45:25.28 ID:Rk6y34sG
リピートアフターミー
秘密鍵はプログラムに書くものじゃない

337 :デフォルトの名無しさん:2017/04/20(木) 22:45:53.95 ID:Rk6y34sG
カプセル化はオブジェクト指向じゃない

338 :デフォルトの名無しさん:2017/04/20(木) 22:45:55.45 ID:1ly+xIep
>>335
じゃあ他のクラスから秘密にしたいデータは?

339 :デフォルトの名無しさん:2017/04/20(木) 22:47:11.97 ID:Rk6y34sG
>>338
公開しなさい

340 :デフォルトの名無しさん:2017/04/20(木) 22:47:42.98 ID:1ly+xIep
>>322
> 昔は暗号化のロジックも隠すことで安全性を担保しようとしていたけど、駄目だったんだよ、現代ではロジックを公開できる暗号化こそが真に安全性を備えていることがわかっている

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

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

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

341 :デフォルトの名無しさん:2017/04/20(木) 22:48:28.32 ID:1ly+xIep
>>339
なんで?

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

342 :デフォルトの名無しさん:2017/04/20(木) 22:49:40.47 ID:Rk6y34sG
>>340
暗号化ロジックは式という形式のデータです

343 :デフォルトの名無しさん:2017/04/20(木) 22:49:49.13 ID:NBs+Bll8
password.txtに書いてgithubにコミットやろjk

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

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

故に

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

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

345 :デフォルトの名無しさん:2017/04/20(木) 22:53:29.90 ID:1ly+xIep
式という形式のデータ、
そこにはいろんなロジックがある。
その沢山の種類のロジックの中で
暗号化ロジックだけは公開しろ

346 :デフォルトの名無しさん:2017/04/20(木) 22:54:17.23 ID:x1mUV01b
>>333
べき論はよくわからんが、そこまで言うなら個人として伝える

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

以上

347 :デフォルトの名無しさん:2017/04/20(木) 22:55:25.78 ID:zhxiAG0o
ID:rIlDsUIc = ID:Rk6y34sG だよね?
昨日はシラフで今日は酔っ払っているのかな?

348 :デフォルトの名無しさん:2017/04/20(木) 22:56:30.20 ID:Rk6y34sG
>>343
冗談じゃなくそういうのあるらしいね
awsのなんかあれ

349 :デフォルトの名無しさん:2017/04/20(木) 23:07:28.95 ID:nIwh3CMn
OOPに必要かどうかしらんけど
カプセル化は単に便利だよね
スコープ的な意味で

350 :デフォルトの名無しさん:2017/04/20(木) 23:23:01.66 ID:16AwdhdC
横からカプセル化の話題を眺めていたが、素晴らしいカプセル化のアイデアが湧いてきた!

351 :デフォルトの名無しさん:2017/04/20(木) 23:29:07.88 ID:jeWo4Dft
>>325
最初はクラスの下にでも書いたらいいよ
少なくとも中に書くよりは読みやすいし
後は必要に応じて慣れやね

352 :デフォルトの名無しさん:2017/04/20(木) 23:49:33.09 ID:hTP3eC2C
インターフェースこそオブジェクト指向だという意見に全面的に同意。
継承自体はクラス目線でモジュール化を進めた結果で得られる構造なだけであって、
インターフェースのように型を意識させることはない。
結果的にはインターフェース+基底クラスパターンが最強だと思うわ

353 :デフォルトの名無しさん:2017/04/20(木) 23:59:45.86 ID:zhxiAG0o
アルゴリズムを試行錯誤している時はグローバルな構造体の方が楽。
デバッグや保守の時はカプセル化されたオブジェクトの方が楽。
これはmutableとimmutableにも同じことが言える。

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

354 :デフォルトの名無しさん:2017/04/21(金) 00:06:49.24 ID:T1EM2She
>>351
関数の名前に構造体の名前を入れるん? 面倒じゃない?

355 :デフォルトの名無しさん:2017/04/21(金) 00:08:09.71 ID:T1EM2She
>>353
不変のものをカプセル化する意味あるのか?
フルオープンでよくね?

356 :デフォルトの名無しさん:2017/04/21(金) 00:11:37.99 ID:YTf7CJ3G
>>355
不変だからこそカプセル化するんだよ

357 :デフォルトの名無しさん:2017/04/21(金) 00:14:32.72 ID:TFy/T03e
不変というのはコンパイル時に決まるってわけじゃないからな。
初期状態から変わらないってだけで、
初期状態というものは存在する。
当然それを隠したい場合も存在する。

358 :デフォルトの名無しさん:2017/04/21(金) 00:26:21.96 ID:Ck7s6rRh
>>354
そうか? 俺は元々Lisperだし、全く面倒とは思わん
でももし面倒と思うんなら、特にC++とかならオーバーロードがあるんだから構造体名入れなくてもなんとかなるでしょ
この先UFCSも導入される予定みたいだし

359 :デフォルトの名無しさん:2017/04/21(金) 00:27:55.81 ID:1EW2mi9U
びっくりするくらい低レベルな会話しててわろた
ホリデープログラマーが語りだすとこうなる

360 :デフォルトの名無しさん:2017/04/21(金) 00:48:08.26 ID:T1EM2She
>>356
どうして不変だからカプセル化するんだよ?

361 :デフォルトの名無しさん:2017/04/21(金) 00:48:50.43 ID:T1EM2She
>>357
なぜ隠すのか?
なぜ? どうして?

362 :デフォルトの名無しさん:2017/04/21(金) 00:49:23.31 ID:T1EM2She
>>358
LisperにとってJavaのクラスはどう?

363 :デフォルトの名無しさん:2017/04/21(金) 01:04:07.46 ID:YTf7CJ3G
自分で考えてみな

364 :デフォルトの名無しさん:2017/04/21(金) 01:18:33.36 ID:Ck7s6rRh
>>362
個人的には作業効率が落ちる感じがして好きじゃない
でも低産階級労働者を縛る鎖としてはいいんじゃない?

365 :デフォルトの名無しさん:2017/04/21(金) 01:19:22.96 ID:T1EM2She
>>363
説明できないのな、じゃあいいわ

366 :デフォルトの名無しさん:2017/04/21(金) 01:20:01.11 ID:T1EM2She
>>364
バイアスがすごいな
Lisperはやっぱ屑だな

367 :デフォルトの名無しさん:2017/04/21(金) 01:34:09.78 ID:YTf7CJ3G
>>365
聞く耳持たないヤツに対して説明できるほど理解は深くないんでね
何度も同じことを繰り返しても仕方ない

368 :デフォルトの名無しさん:2017/04/21(金) 01:43:34.54 ID:T1EM2She
とどのつまりカプセル化は理解できないものなんだな?

369 :デフォルトの名無しさん:2017/04/21(金) 02:00:31.00 ID:Ck7s6rRh
>>366
もしかして低産階級労働者だった? これは申し訳ないことを書いた。失礼

370 :デフォルトの名無しさん:2017/04/21(金) 02:04:34.66 ID:T1EM2She
>>369
ホントだよ!失礼極まりないよ!

371 :デフォルトの名無しさん:2017/04/21(金) 02:05:08.14 ID:T1EM2She
低産階級労働者は傷ついているのです

372 :デフォルトの名無しさん:2017/04/21(金) 02:05:31.65 ID:T1EM2She
私は被害者です

373 :デフォルトの名無しさん:2017/04/21(金) 02:06:19.45 ID:T1EM2She
どうしてLispにはクラスがないんだろうか
みんなで考えてみよう

374 :デフォルトの名無しさん:2017/04/21(金) 02:12:55.16 ID:TFy/T03e
>>373
クラスを使わないという発想で作られたから
別にいい悪いじゃなくて、ただ単にモットーの問題

375 :デフォルトの名無しさん:2017/04/21(金) 02:18:17.50 ID:T1EM2She
>>374
でもクラスは便利ですよ

376 :デフォルトの名無しさん:2017/04/21(金) 02:18:56.37 ID:T1EM2She
クラスがない、つまりカプセル化もできない?

377 :デフォルトの名無しさん:2017/04/21(金) 04:34:49.48 ID:H6APCPmE
手続き型言語でも定数はグローバル変数でも問題無いんだし、関数型言語の変数はほぼ定数みたいなもんだし。
カプセル化の恩恵そのものがあんまり無い希ガス。

378 :デフォルトの名無しさん:2017/04/21(金) 05:07:53.93 ID:rPWpf+kQ
そもそも仕様書に書くべき問題をソースなんかに記述しようとするからこうなる

なんだよカプセル化って
ガキの使いでソースに手を入れようとしてるキチガイでもサポートしたいの?
ほらほらボクチンここprivateだから他のクラスから触れないからね!

チンカス過ぎる

379 :デフォルトの名無しさん:2017/04/21(金) 05:56:50.07 ID:67Y5mbs0
カプセル化はそもそも代入禁止じゃなくて隠蔽なんだが理解して書いてるのか?

SRP原則に則るならカプセル化のほうがいいに決まってる

380 :デフォルトの名無しさん:2017/04/21(金) 06:07:38.30 ID:H6APCPmE
なぜ隠蔽するかって言うと、不用意な変数の書き換えをさせない為。
関数型言語の場合は必ず変数の書き換え(と言うか再生産だが)を行うには関数を経由する。
変数を隠蔽したい場合は、パッケージで変数や関数単位で公開非公開を指定する。

381 :デフォルトの名無しさん:2017/04/21(金) 06:09:25.78 ID:rPWpf+kQ
>>379
誰から何を隠蔽するためのものなのか明確になってないんだよ

382 :デフォルトの名無しさん:2017/04/21(金) 06:13:30.88 ID:rPWpf+kQ
例えばライブラリ提供者と使用者
使用者はライブラリ側のソースを一切触ることがなく
提供者は使用者側からの問い合わせや変更依頼を断れない
ここまで立場が明確なときに隠蔽は意味を持つが

すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない

と俺は思う

383 :デフォルトの名無しさん:2017/04/21(金) 06:25:22.14 ID:uAFMuOM4
>>380
それだと参照するだけならいいってことになっちゃうよ?
隠蔽するなら不用意な参照もダメだよね。

384 :デフォルトの名無しさん:2017/04/21(金) 06:33:08.40 ID:67Y5mbs0
>>380
隠蔽はその変数の操作をそのクラス内に限定するためにある
プロパティを介してprivate変数に代入や参照ができるようにしてるのもそのため
変数の書換禁止ならそれこそfinalつければ済む

>>382
>すべての人間がどのソースもすべて変更する可能性がある環境で隠蔽は意味を成さない
誰がいじろうとも修正箇所をクラス内に限定する意味はあるだろ

385 :デフォルトの名無しさん:2017/04/21(金) 06:36:29.75 ID:rPWpf+kQ
>>384
だからそんなものはアプリケーションの仕様の前には意味を成さないんだよ

386 :デフォルトの名無しさん:2017/04/21(金) 07:13:56.06 ID:zhvS/nL7
車とタイヤをオブジェクト指向で表現する場合、車クラスにタイヤ属性を持つのが良いでしょうか

それぞれクラスを持ってる方が良いでしょうか

387 :デフォルトの名無しさん:2017/04/21(金) 07:21:08.83 ID:7DnA3IDC
>>383
マルチスレッドでも言われるが、参照だけなら基本問題無い。
上でも書かれている通り、隠蔽したければカプセル化じゃ無くても方法はある。

カプセル化と言うか、クラスと言う型に関数(メソッド)や変数(フィールド)を押し込めるのと、関数プログラミング的な考えはメリット/デメリットがそれぞれある。

クラスは依存関係が出来やすいが、GUIなどの多くの状態を保持するのに向く。
一方の関数プログラミングはデータと関数が分かれるので依存関係を少なく出来るが、状態を関数の引数として引き回すのでGUIに向かない。

関数型言語ではa = 1はそのプログラムではずっと1で、2が欲しければinc a とか、succ aとか関数の結果として2を受け取る。

388 :デフォルトの名無しさん:2017/04/21(金) 07:23:34.62 ID:fRfyQmKB
>>385
納品したら終わりってアプリを組むときにはカプセル化なんて確かに無用だけど
そもそもカプセル化とかその先のデータ抽象(抽象データ型)とかは、アプリが動いたり大規模化したあと
それをメンテしつつ運用(ちょっとしたバグ修正だけでなく、拡張や機能改変を含め)し続けるときに
それをやりやすくする技術だからなぁ…

389 :デフォルトの名無しさん:2017/04/21(金) 07:24:52.21 ID:YTf7CJ3G
>>385
個人開発ならばまぁわからんでもないが発想が危険すぎる
頼むからめんどくさいバグを作り込む前にプログラムから手を引いてくれ

390 :デフォルトの名無しさん:2017/04/21(金) 07:30:28.22 ID:rPWpf+kQ
>>389
何を言ってるんだよ
誰から何を隠蔽するのか明確にしろよ

391 :デフォルトの名無しさん:2017/04/21(金) 07:38:01.69 ID:rPWpf+kQ
>>389
お前のソースって読み手が完全な傍観者である場合は意味があるけど
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいんだろ
privateにした変数がクラス内グローバル変数みたいな動作してる典型だよね

392 :デフォルトの名無しさん:2017/04/21(金) 07:40:08.56 ID:uAFMuOM4
>>387
だからいくつかある方法のひとつがカプセル化なんだよね?

>>390実装依存しようとしている人間から実装を隠蔽するんじゃね?

393 :デフォルトの名無しさん:2017/04/21(金) 07:43:06.82 ID:rPWpf+kQ
>>392
全然意味がわからない
対象のクラスに手を入れようとしてる人間に対して隠蔽したいの?

394 :デフォルトの名無しさん:2017/04/21(金) 07:48:52.81 ID:uAFMuOM4
「実装依存しようとしている人間から実装を隠蔽する」

これ以上どう簡単に言えるのか?

395 :デフォルトの名無しさん:2017/04/21(金) 07:59:35.17 ID:YTf7CJ3G
>>391
ハイじゃあソースに手を入れなきゃねってなったときには超絶読みにくいだろ
publicにした変数がクラス外にも波及するグローバル変数みたいな動作してる典型だよね

どこまで影響すると思ってるんだ
調査、設計、対応、試験にかかる工数がとんでもない数値になる

396 :デフォルトの名無しさん:2017/04/21(金) 08:21:01.29 ID:rPWpf+kQ
>>394
全く意味がわからない
外部設計書とか内部設計書とか
以外の仕様書があってそれに基づいて作成してるの?

397 :デフォルトの名無しさん:2017/04/21(金) 08:30:29.31 ID:YTf7CJ3G
>>396
ところで全然わかってない自覚があるのになぜ不要と言い張れるの?
不要である理由を明確にしろよ

398 :デフォルトの名無しさん:2017/04/21(金) 08:30:52.58 ID:rPWpf+kQ
ていうか読み込んだデータに基づいて処理するも
ソースに記述した定数で処理するも仕様書次第じゃないの?
実装依存が何を指して実装依存って言ってるのかわからない

399 :デフォルトの名無しさん:2017/04/21(金) 08:31:42.41 ID:rPWpf+kQ
>>397
どのレスの不要?
引用して欲しい

400 :デフォルトの名無しさん:2017/04/21(金) 08:39:43.24 ID:YTf7CJ3G
>>399
カプセル化不要についてだよ

まさかひとつひとつ違うことに対して不要だと言いまくってたの?

401 :デフォルトの名無しさん:2017/04/21(金) 08:46:39.65 ID:TFy/T03e
知らなくてもなくても作れるのだから不要。
極論すればアセンブルでも作れる。

402 :デフォルトの名無しさん:2017/04/21(金) 08:54:22.04 ID:rPWpf+kQ
>>400
カプセル化の不要についてだね
おk

まず処理の動作は設計書に書くものだろう
ソースでprivateやpublicになってるからどうだってんだよ

ここで反論ある?

403 :デフォルトの名無しさん:2017/04/21(金) 08:54:46.12 ID:uAFMuOM4
実装がpublicだと他人がその実装に依存して良くないことがありそうだ。参照だけでもマズい。
だからprivateにして実装を隠蔽する。

これのどこに分かりにくい点があるというのか?
設計書とか仕様書とか関係なかろう

404 :デフォルトの名無しさん:2017/04/21(金) 09:00:18.64 ID:YTf7CJ3G
>>402
ある
利用者は仕様書を確認することなく意図しない方法で利用する

他は?
と言うか一度に全部言ってくれ

405 :デフォルトの名無しさん:2017/04/21(金) 09:05:15.16 ID:rPWpf+kQ
>>404
利用者って誰?
ソースを改変するソイツ(?)は設計書を記述せずに対象のクラスを変更しようとしてる?
ソイツのことを利用者と呼んでいてお前の環境では存在しうるの?

406 :デフォルトの名無しさん:2017/04/21(金) 09:10:26.57 ID:n31cY2TM
あぼーん

407 :デフォルトの名無しさん:2017/04/21(金) 09:27:52.36 ID:Ck7s6rRh
個人製作の観点からはカプセル化はいらんな
テンプレートか抽象タイプと多重ディスパッチあれば継承もいらんしミックスインもいらん

408 :デフォルトの名無しさん:2017/04/21(金) 09:38:24.71 ID:9S9WRWBb
>>405
実装する人が複数いる時、自分が作ったクラスのメンバ変数やメンバ関数を利用して
その人の担当クラスを実装する他人が自分のクラスの利用者だろう。
自分が作ったクラスも他人が作ったクラスも変更するのは作った人だけだ。

実装を一人で行える規模ではカプセル化の必要を感じないという話なら分かる。
でも前提なしでカプセル化は不要と主張したら大規模ソフトウェアも含まれる。
もしかして大規模ソフトウェアで必要かどうか全然考えてなかったの?

409 :デフォルトの名無しさん:2017/04/21(金) 09:46:56.85 ID:cmecYv9F
だからホリデープログラマーと話しても無駄やて

410 :デフォルトの名無しさん:2017/04/21(金) 09:59:20.07 ID:WJo/zINx
むしろここで仕事の話をする方がおかしいけどな

411 :デフォルトの名無しさん:2017/04/21(金) 10:01:25.18 ID:WJo/zINx
>>408
担当のチェンジは無しなの?

412 :デフォルトの名無しさん:2017/04/21(金) 10:22:27.45 ID:YTf7CJ3G
>>405
話が止まるからまずは全量を語ってくれ

413 :デフォルトの名無しさん:2017/04/21(金) 10:43:25.71 ID:+U39WrXp
カプセル化されていると、メンバ変数とアクセサは分離され、外部のクラス利用者(ユーザコード)はもっぱらアクセサを呼ぶことになる。
仮にメンバ変数の実装の詳細を変更することになっても、アクセサを変更しない限り、ユーザコードは変更する必要はない。
間接層の導入による変更の局所化やね。

メリットと煩わしさの比較は人により異なりうるが、少なくとも必要なケースは少なからずあると思うが。

414 :デフォルトの名無しさん:2017/04/21(金) 10:54:13.27 ID:uAFMuOM4
せっかくカプセル化してもアクセッサなんか作ったら不自由になる。
変数を廃止したり形式の変更をしたりしにくくなる。

415 :デフォルトの名無しさん:2017/04/21(金) 11:10:28.55 ID:rPWpf+kQ
>>408
じゃあ利用者ってのはクラス使用者(そのクラスには絶対に手を加えない)のことでいいの?

416 :デフォルトの名無しさん:2017/04/21(金) 12:01:38.24 ID:YTf7CJ3G
>>415
そうだよ
javaで言うならStringクラスの利用者はStringクラスの内容を変更しないだろ

いちいち立ち止まらずまずは全量を語ってくれ

417 :デフォルトの名無しさん:2017/04/21(金) 12:12:59.55 ID:T1EM2She
【全量】全体の重量。全体の容積。

418 :デフォルトの名無しさん:2017/04/21(金) 12:20:09.36 ID:YTf7CJ3G
>>417
ありがとう

419 :デフォルトの名無しさん:2017/04/21(金) 12:41:44.49 ID:rPWpf+kQ
>>416
ほうほう
だったら仮にそのクラス自体に手を入れることになった場合は
隠蔽対象者ではないということでおk?

420 :デフォルトの名無しさん:2017/04/21(金) 12:49:54.80 ID:YTf7CJ3G
>>419
うだうだ言ってねーで早く語れ

421 :デフォルトの名無しさん:2017/04/21(金) 12:52:42.74 ID:3x8HXz+G
相手にしない方がいいよ時間と労力の無駄
ID:YTf7CJ3Gが楽しんでやっているならとめないけど

422 ::2017/04/21(金) 13:05:41.49 ID:KFYgHFHL
何十年前の話なのかわからなくなるな

423 :デフォルトの名無しさん:2017/04/21(金) 13:27:43.71 ID:T1EM2She
>>422
いつ何度でも話していいことだと思うが
会話ってそういうものだと思う

人の色恋沙汰なんて4000年前に語りつくされているが
今なお人の心をとらえて離さないだろ

オブジェクト指向にとってカプセル化とは
それくらいの魅力があるものだってこと

会話っていうのは昔々誰々がすでにいったことだから
言っちゃいけない、話しちゃいけないなんてもんじゃない

会話に入りたいって素直に言うべき、カプセル化やめるべきって
ちゃんというべき

424 :デフォルトの名無しさん:2017/04/21(金) 13:46:02.03 ID:YTf7CJ3G
>>421
ありがとう
うんこタイムの暇潰しなので大丈夫だよ

>>423
べき論はよくわからん
そんなことよりも不要である理由を早く『明確』にしてくれ

425 :デフォルトの名無しさん:2017/04/21(金) 13:51:29.39 ID:cmecYv9F
>>410
仕事の話ではなくオブジェクト指向の話だろ?
おれは1人で好きに作ってるからカプセル化なんていらねー!といわれても会話にならないよ

426 :デフォルトの名無しさん:2017/04/21(金) 14:26:24.80 ID:uAFMuOM4
>>425
それはそうだが、誰とどういうレベルで会話するのかってことだろう。
その前にホリデープログラマがどうたらってレスあるから。

427 :デフォルトの名無しさん:2017/04/21(金) 14:50:09.12 ID:T1EM2She
>>424
お前が明確にするんだよ、カプセル化やめるべきだって言うんだよ
お前の仕事だよ

428 :デフォルトの名無しさん:2017/04/21(金) 14:51:20.94 ID:T1EM2She
この業界趣味でやってる人の方が技術力高かったりするからね
サンデープログラマを馬鹿にしちゃいけない

429 :デフォルトの名無しさん:2017/04/21(金) 15:30:29.00 ID:YTf7CJ3G
>>427
俺は必要だと思ってるから無理だな
不要である理由を明確にするのはおまえだ

430 :デフォルトの名無しさん:2017/04/21(金) 15:33:45.46 ID:I/U40a25
データのカプセル化なんてプログラム上どこまで触って(参照/代入)いいかの線引きを決まりごとからシステム的に制限したかの違いなだけでしょ
c言語のFILE構造体の中身を参照する事はないでしょ。stdio.hに定義されていても
それは暗黙的な決まりごとだからだし、それをアクセス修飾子で明示したのがカプセル化って言葉なだけで昔からの決まりごととしては変わらない

431 :デフォルトの名無しさん:2017/04/21(金) 15:42:27.29 ID:T1EM2She
>>429
どうして必要だと思ってるのか全量を言えよ、じゃないと理解できない

432 :デフォルトの名無しさん:2017/04/21(金) 15:46:08.76 ID:T1EM2She
>>430
その決まりが要らないものだったんじゃないかっていうのが
カプセル化害悪論の骨子なんだよ

暗黙的なものは暗黙的なままでよかったんじゃないか?
なぜ明示する必要があったのか、それによってプログラムが
複雑になることを受け入れるのか、プログラムがブラックボックス化することに
歯止めをかけてクリーンなオブジェクト指向を取り戻そうというのが
カプセル化害悪論のモチベーション

433 :デフォルトの名無しさん:2017/04/21(金) 15:49:33.07 ID:YTf7CJ3G
>>431
聞いてるのはこっちだ
はぐらかすな

434 :デフォルトの名無しさん:2017/04/21(金) 15:51:44.08 ID:T1EM2She
>>433
聞き返したのは俺だ、ちゃんと全量を示せ、逃げるな

435 :デフォルトの名無しさん:2017/04/21(金) 15:55:05.36 ID:YTf7CJ3G
質問に対する答えが質問になる程度の考えしか持たぬならもういいわ

436 :デフォルトの名無しさん:2017/04/21(金) 15:55:47.07 ID:T1EM2She
>>435
捨て台詞まで吐いて逃げるのな?

437 :デフォルトの名無しさん:2017/04/21(金) 15:56:28.58 ID:T1EM2She
もういいわて、お前は漫才師か!

438 :デフォルトの名無しさん:2017/04/21(金) 15:57:50.64 ID:YTf7CJ3G
そだね

439 :デフォルトの名無しさん:2017/04/21(金) 15:59:01.00 ID:T1EM2She
はい逃げた、結局カプセル化を支持するやつって中身のないその場限りの
見栄を張って問い詰められたら逃げるだけの俄かなんだよな

440 :デフォルトの名無しさん:2017/04/21(金) 16:01:17.62 ID:YTf7CJ3G
そだね

441 :デフォルトの名無しさん:2017/04/21(金) 16:01:35.09 ID:I/U40a25
>>432
カプセル化害悪論ってのは一理あるし正しいと思うけどね
性善説と性悪説みたいなところだから正解はでないと思うし
ただ、このスレのカプセル化反対の意見はそんなレベルの話じゃない、そもそも議題のカプセル化の認識ズレの話なんじゃないのかな

442 :デフォルトの名無しさん:2017/04/21(金) 16:08:41.18 ID:rPWpf+kQ
>>424
それは説明したじゃん
402がすべてだよ

443 :デフォルトの名無しさん:2017/04/21(金) 16:14:29.43 ID:9S9WRWBb
>>441
カプセル化反対の二人はカプセル化の利害を全然理解していないよね。
害があるからいらないではなく、わからないからいらないと言っている。

444 :デフォルトの名無しさん:2017/04/21(金) 16:20:27.91 ID:rPWpf+kQ
>>443
んでメリットの説明ってあったっけ?

445 :デフォルトの名無しさん:2017/04/21(金) 16:20:44.14 ID:YTf7CJ3G
>>442
明確になってねーよ
仮にアレで全てだというなら『まず』とか『ここまで』などと言うな

446 :デフォルトの名無しさん:2017/04/21(金) 16:22:11.78 ID:jkmg2197
カプセル化害悪派 <------- 結合度ビーーーーム
死亡

447 :デフォルトの名無しさん:2017/04/21(金) 16:35:15.00 ID:9S9WRWBb
>>444
例えば>>403がそうだ。
自分だけが使い仕様変更があったら変更するつもりのメンバ変数やメンバ関数は
勝手に他人に参照されたり呼びだされると変更できなくなって困る。

448 :デフォルトの名無しさん:2017/04/21(金) 16:41:52.97 ID:uAFMuOM4
どうでもいいけどメリデメって略すの嫌い

449 :デフォルトの名無しさん:2017/04/21(金) 16:43:18.10 ID:jkmg2197
カプセル化害悪論って、どっかで聞きかじった継承害悪論とごっちゃになってるんじゃないのか?

450 ::2017/04/21(金) 16:49:15.74 ID:KFYgHFHL
>>423
どちらでも無いと思うよ。少なくともどちらかへの「べき」ではない。
隠したいものは隠せばいいし、機械へのポカヨケを埋め込むのも今もうすでに実行不可なメモリみたいなどこのハーバードアーキテクチャだよみたいなの再発明してんじゃん。

451 :デフォルトの名無しさん:2017/04/21(金) 17:12:45.41 ID:9S9WRWBb
>>449
>>216はごっちゃにしているね。

実装継承は20年前に「継承より委譲」と言われていた。
その後のEJB2の複雑さの反動でPOJOブームが起きた。
でもカプセル化害悪論なんて聞いたことがない。

452 :デフォルトの名無しさん:2017/04/21(金) 17:31:41.72 ID:jkmg2197
>>199みたいな、ここまでがっちり結合したコードを良しとする人が、数万行程度コードを書いたらどんなことになるのか見てみたいわ

453 :デフォルトの名無しさん:2017/04/21(金) 18:00:15.36 ID:T1EM2She
>>452
おめーのコード出してもらおうか
俺はそれを複雑すぎるとさんざんにこき下ろすから
他人のコードにいちゃもんつけて自分のコードは出しませんなんて
そんなのありえないだろ、ベッドで女のパンツ脱がして
自分はスリーピースをぴっちり着込んでるようなもの
どちらが変態化は言うまでもないよね?

454 :デフォルトの名無しさん:2017/04/21(金) 18:03:14.83 ID:T1EM2She
>>451
やはりな、継承はオブジェクト指向に必要ないよな
POJOはたしかに話題にはなったが、まだJavaBeansの呪縛から
脱しきれてない過剰カプセル化によって逆に脆くなった
設計ばかりが出回った

いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
聞いたことがあるというべきだし、すぐれた設計だと
後世に伝えていくべき

455 :デフォルトの名無しさん:2017/04/21(金) 18:04:56.46 ID:YTf7CJ3G
>>453
おまえはおまえのコード以外を認めないんだから黙ってろ

456 :デフォルトの名無しさん:2017/04/21(金) 18:05:19.93 ID:T1EM2She
>>455
……

457 :デフォルトの名無しさん:2017/04/21(金) 18:07:31.03 ID:jkmg2197
>>453
別に俺が出すまでもなく、世の中にはそこそこSOLIDを目指したなかなかのコードが死ぬほど公開されてるんだが

> 俺はそれを複雑すぎるとさんざんにこき下ろすから
それらが読めないとしたら、それは複雑すぎる場合もあるだろうが、大抵は君のスキル不足だろうね
試しにgitfubから有名どころの1万行以上のプロダクトを選択してこきおろしてみたら?

458 :デフォルトの名無しさん:2017/04/21(金) 18:11:31.05 ID:YTf7CJ3G
>>454
>いままでは聞いたことがなかっただろうが
もうお前は聞いたんだからこれからはカプセル化害悪論を
>聞いたことがあるというべきだし、すぐれた設計だと
>後世に伝えていくべき

一切論じられてないよ
悪いんだけどどこらで論じてたのか教えてくれる?

459 :デフォルトの名無しさん:2017/04/21(金) 18:11:49.39 ID:T1EM2She
>>457
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ

460 :デフォルトの名無しさん:2017/04/21(金) 18:12:34.04 ID:jkmg2197
>>453
選ぶの面倒とかいいそうだから、俺が選んでやろう
Javaで実装された超有名プロダクト
https://github.com/kohsuke/jenkins
ほら、駄目だししてみ?

461 :デフォルトの名無しさん:2017/04/21(金) 18:13:54.37 ID:T1EM2She
>>458
>>322 この辺とかすごくいい議論ができてるしとても有益でためになると思う

462 :デフォルトの名無しさん:2017/04/21(金) 18:14:43.96 ID:T1EM2She
>>460
お前は俺のコードにいちゃもんつけたから
俺はお前のコードにいちゃもんつける
それてフィフティフィフティだ
さあ出してもらおうか、お前の全力を見せろ
他人のふんどしで相撲取ろうとするな卑怯者

463 :デフォルトの名無しさん:2017/04/21(金) 18:15:18.80 ID:T1EM2She
とうぜんキャットドア問題を解決するコードだ

464 :デフォルトの名無しさん:2017/04/21(金) 18:16:17.62 ID:T1EM2She
結局キャットドア問題を解決できたの俺だけじゃん
カプセル化を導入してたらできてなかったと思う
俺は歴史の生き証人

465 :デフォルトの名無しさん:2017/04/21(金) 18:17:40.73 ID:jkmg2197
>>462,463
俺には難しすぎて読めませんって白状しろよ

466 :デフォルトの名無しさん:2017/04/21(金) 18:17:51.34 ID:T1EM2She
キャットドア問題をオブジェクト指向で解決してください
権威や数の力は不要だ、オブジェクト指向をわかっているなら
自力で解決できるはずだ

467 :デフォルトの名無しさん:2017/04/21(金) 18:18:26.45 ID:YTf7CJ3G
>>461
悪いんだけど根拠のない言い合いに意味はないよ
根拠を示してくれる?

468 :デフォルトの名無しさん:2017/04/21(金) 18:18:45.77 ID:jkmg2197
>>464
そもそも、キャットドア問題とか知らんし
他人のコード書いてほしけりゃ、仕様示せ

469 :デフォルトの名無しさん:2017/04/21(金) 18:19:13.64 ID:T1EM2She
>>465
で、キャットドア問題を解決するオブジェクト指向のお前が書いたコードは?
俺は書いたよ、お前にいちゃもんつけられたけど
だから、俺はお前が書いたコードをボコボコに貶してやる所存だけど
お前はその覚悟もできてるし受けて立つ実力もあるんだよな
じゃあコードを書いてもらおうか

470 :デフォルトの名無しさん:2017/04/21(金) 18:20:45.36 ID:T1EM2She
>>468
このスレにいて知らないはありえない
すれを検索すればすぐにでてくる >>6

471 :デフォルトの名無しさん:2017/04/21(金) 18:21:06.06 ID:T1EM2She
仕様にいちゃもんつけて逃げたりしてw

472 :デフォルトの名無しさん:2017/04/21(金) 18:21:25.26 ID:jkmg2197
>>466
>>199程度のコードなら、誰がどう書いても複雑にはならんだろ
俺の>>199の批判ポイントはSOLIDだ

OCPはダメダメらしいが、S,L,I,Dも駄目なら批判しなよ

473 :デフォルトの名無しさん:2017/04/21(金) 18:21:43.58 ID:T1EM2She
この手の手合いは他人を否定するけど自分では何も作れない木偶の坊と相場が決まってるからな

474 :デフォルトの名無しさん:2017/04/21(金) 18:22:17.82 ID:T1EM2She
さて、どんなコード書くんだろうな、楽しみだわ

475 :デフォルトの名無しさん:2017/04/21(金) 18:23:03.71 ID:T1EM2She
>>472
>>199は俺のコードだからパクっちゃだめだぞ、カンニングは卑怯な行為だからな
あくまで仕様を読んで作るんだぞ

476 :デフォルトの名無しさん:2017/04/21(金) 18:23:31.45 ID:jkmg2197
>>470
なんだ、>>199と全然違うじゃんか
俺は>>199の範囲で>>199のコードが糞だと断言するわwww

477 :デフォルトの名無しさん:2017/04/21(金) 18:24:37.49 ID:T1EM2She
他人を否定すればするほど自分のハードルがあがるけど大丈夫なのかな
結局自分のコード書けないパターンをちゃくちゃくと歩んでるようだけど大丈夫なのかな
逃げ出しそうだぞ、大丈夫なのかな

478 :デフォルトの名無しさん:2017/04/21(金) 18:26:54.78 ID:YTf7CJ3G
>>477
カプセル化害悪論の根拠を示してくれるかな?

479 :デフォルトの名無しさん:2017/04/21(金) 18:27:35.87 ID:T1EM2She
>>478
……

480 :デフォルトの名無しさん:2017/04/21(金) 18:28:40.65 ID:YTf7CJ3G
>>479
あ、根拠ないんだね
了解

481 :デフォルトの名無しさん:2017/04/21(金) 18:29:00.98 ID:T1EM2She
……

482 :デフォルトの名無しさん:2017/04/21(金) 18:29:47.23 ID:T1EM2She
黙ってろって言われたから黙らざるを得ないのに
それで了解とか自己完結しすぎだと思う、病んでるよ彼は病んでるよ

483 :デフォルトの名無しさん:2017/04/21(金) 18:30:19.40 ID:YTf7CJ3G
>>482
じゃあ黙り続けろよ

484 :デフォルトの名無しさん:2017/04/21(金) 18:30:38.43 ID:T1EM2She
>>483
……

485 :デフォルトの名無しさん:2017/04/21(金) 18:30:56.12 ID:T1EM2She
俺のことは寡黙な人と呼んでくれ

486 :デフォルトの名無しさん:2017/04/21(金) 18:31:20.37 ID:YTf7CJ3G
>>485
黙ってねーじゃねーか

487 :デフォルトの名無しさん:2017/04/21(金) 18:32:01.93 ID:T1EM2She
>>486
クソレスすんなハゲ

488 :デフォルトの名無しさん:2017/04/21(金) 18:33:35.27 ID:YTf7CJ3G
>>487
ごめんね
ハゲでごめんね^^

489 :デフォルトの名無しさん:2017/04/21(金) 18:36:02.42 ID:T1EM2She
ハゲもプログラム書けんの?
書けるんだったらオブジェクト指向でキャットドア問題に調整してほしい

490 ::2017/04/21(金) 18:39:02.82 ID:KFYgHFHL
あのドアってこういう話の発端から出てきた問題だったんだな。
オブジェクト指向で、ってそういう事か、なるほど。
ナンセンスだな。

何を以ってドアと成立するか定義できてるようで出来てない。
定義1を死守したければ、俺なら定義1は定義0の子クラスにして、定義2は定義1を継承せずに定義0から作るわ。
定義0は最終的にObjectに収斂する。

クラス設計を破壊せずに性質を追加ってのが矛盾してる。
ワイン樽と泥水の問題。

491 :デフォルトの名無しさん:2017/04/21(金) 18:42:27.87 ID:T1EM2She
↑こうやって仕様に文句を付けて
コードから逃げる人間は飽きるほど見てきた

オブジェクト指向のコードをかける人間はいないのか

492 ::2017/04/21(金) 18:45:08.24 ID:KFYgHFHL
>>491
俺どっかで書いたぞ

493 :デフォルトの名無しさん:2017/04/21(金) 18:46:48.77 ID:T1EM2She
>>492
それどこよ? どれよ? どこなのよ? どこーーー!!

494 :デフォルトの名無しさん:2017/04/21(金) 18:47:06.08 ID:T1EM2She
取り乱してしまいまして

495 ::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

496 ::2017/04/21(金) 18:53:00.35 ID:KFYgHFHL
何でわざわざ関数作ったのに放棄してクロージャ変数にしてるか見たら、カプセル化がオブジェクト指向の専売でもなけりゃ普遍的に便利なものか気づくだろ。

497 :デフォルトの名無しさん:2017/04/21(金) 18:59:03.34 ID:T1EM2She
>>496
クロージャがカプセル化じゃないとしたら
カプセル化害悪論には賛成していただけるよね?

498 ::2017/04/21(金) 19:05:27.23 ID:dftFol4E
>>497
クロージャはカプセル化で、カプセル化害悪論には大反対だ。
カプセル化されてるから、ドアは責任を持ってイベントに対して好きなことを好きなだけできるし、他人はそれに関与せずにイベントの投げ合いで済む。
鍵のないドアだってあるんだから。

499 ::2017/04/21(金) 19:06:54.30 ID:dftFol4E
見せたくないものを隠すんだけじゃない。
見て不快なものが目に入らないようにするためにも使えるんだよ。
NHKの入らないテレビみたいなもんだ。

500 :デフォルトの名無しさん:2017/04/21(金) 19:27:31.37 ID:rPWpf+kQ
>>499
具体的に誰に対してやってるの?

501 :デフォルトの名無しさん:2017/04/21(金) 19:29:06.55 ID:T1EM2She
>>498
カプセル化害悪論に反対しているとのことだけれども
もしクロージャがカプセル化ではないと仮定したら
カプセル化害悪論に反対する理由もなくなると思うんだよ

クロージャってどちらかというとローカル変数じゃない?
クロージャオブジェクトを使うところって関数内に限られると思うんだよ
そう考えるなら結局クロージャってローカル変数ってことになるわけじゃん?
だからクロージャを使ってもカプセル化害悪論には反しないんだよ

502 ::2017/04/21(金) 20:03:29.23 ID:qsriX73g
>>500
自分かも知れないし、他人かもしれないけど、それを考えたくない場面でそれが目に入らないようにしてる。
その関数以外書いてるときに、その関数なんて考えたくないじゃん。

>>501
だからクロージャは一つのカプセル化だって言ってるんよ。
ローカル変数って言葉が良くないが、ローカル変数には違いない。ただ、お前が思ってるローカル変数よりも限定的で、そして並行的だよ。
関数内に限られるわけではない。mallocして何かに帰そうが勝手だよ。
クロージャの中でいくつかのコールバックに渡したりするならなおさら。
つまるところ、オブジェクト指向のインスタンスのメンバ変数とあまり変わらん。

503 :デフォルトの名無しさん:2017/04/21(金) 20:07:05.07 ID:rPWpf+kQ
>>502
はぁ?
ちゃんと設計書は書いてる前提でいいんだよね?

504 ::2017/04/21(金) 20:17:17.21 ID:qsriX73g
>>503
うん。書いてるから何?
書いてるから触ってはいけないとわかるはずだ、なら、無意味かつ実務知らなすぎだな。
書いてて触ってはいけないならば、触れることができてはいけないんだよ。本来は。
AppleのMacOSのUIのデザイン規約くらいの時代から書いてた話。
感電するよって書いてたら覆いをしなくたって良いなんて機械はありえないのと同じ。

505 :デフォルトの名無しさん:2017/04/21(金) 20:22:47.97 ID:YTf7CJ3G
包丁は料理にのみ使われるものだから傷害事件で扱われる刃物は包丁以外であるって理屈

506 :デフォルトの名無しさん:2017/04/21(金) 20:32:03.02 ID:rPWpf+kQ
>>504
じゃ、君の想定してる環境って

本来なら設計書を記述してから修正すべきなのに
それがやりにくい現場ってことでいいのかな?

カプセル化は設計書を記述する手順を踏んだとき役に立たない?

507 :デフォルトの名無しさん:2017/04/21(金) 20:45:20.00 ID:YTf7CJ3G
車のブレーキだけを踏んでたら全然進まないのでプレーキを踏んでもちゃんと進むように修理する工場だな

508 :デフォルトの名無しさん:2017/04/21(金) 20:51:25.16 ID:uAFMuOM4
カプセル化の意義を誤解するものはfriendの意義も誤解する

509 ::2017/04/21(金) 21:04:20.97 ID:qsriX73g
>>506
本来なら設計書を記述するどころか設計変更申請出して承認を経て設計書と設計変更書を出して、実装を変更して設計変更書から起こされた上がってきたテスト仕様書でテストして完了するけど、何もやりにくくないでしょ。

カプセル化は役に立つよ。担保となる元の設計書で使ってる部品の設計書を出来る限り見ずに済むし、
なんなら部品ごと新しく変えてもIFさえあってれば良い証左になるんだから。

>>507
プレーキとやらの定義が、踏めば進むというものであるならそう治すべく修理なり改修なりするわな。
このパンチメタルで穴が空いてる部品は共有部品で、AT車ならフットレスト、MT車ならクラッチペダルにつける部品の首がよく腐るから設計変更するなら、
押してクラッチが切れるかもしれない部品であり、押しても何も起こらない部品を同時に設計変更してる事になるが。
お前らのドアってこのパンチメタルの板くらいフワフワした定義。

510 :デフォルトの名無しさん:2017/04/21(金) 21:09:39.74 ID:rPWpf+kQ
>>509
設計書書いてるんだよね?

だったら今回の開発でそのメソッドを呼び出す奴は決まってる
今後増える予定を想定することの記述も設計書にはないでしょ?

この状態でprivateとpublicになんの意味があるの?

511 :デフォルトの名無しさん:2017/04/21(金) 21:11:56.33 ID:YTf7CJ3G
>>509
全面的に同意
ふわっふわしまくってるせいでカプセル化が害だとか言うバカみたいな考えなしの意見が出てくるんだと思う

512 ::2017/04/21(金) 21:16:51.77 ID:qsriX73g
>>510
呼び出すやつは決まってる、今後呼び出し方が変わる予定も無い。
ならばそいつはそれがインターフェイスで良いと思うけど、インターフェイスが無いわけではない。そいつがそのものであるだけで。
その上で、疎通にはこれを使おうね、これは使ってくれるなよ、と言う設計は無為味だし、むしろそうならばモジュラーにせずにそれごと機械に埋めてしまえとなる。
そうでは無くて、壊れたらこれだけ変えられるようにしとこう、とか、これだけを改良できるようにしよう、とか、
不具合が出たときに特定しやくすしとこうとなると、ある意味不自由を強制する形で決まった形で疎通させるのは当然でしょ。
お前のパソコンがノートパソコンならタッチパッドは前者、USBマウスは後者だよ。

513 :デフォルトの名無しさん:2017/04/21(金) 21:25:56.38 ID:rPWpf+kQ
>>512
何?次の開発を想定してるの?
よくわからないんだけど?

問題があったら設計書を修正してレビューしてソース修正する流れでいいんだよね?

514 :デフォルトの名無しさん:2017/04/21(金) 21:29:21.44 ID:JwbSy4qm
ここまでの流れで面白いのは>>414の視点だけ
カプセル化がどうの
その是非がどうのとはさんざん繰り返されがちだが

アクセッサ自体が意外と臭いよねって観点まで到達できる人は少ない
また、そこから先の議論についてもあまり見かけない

515 :デフォルトの名無しさん:2017/04/21(金) 21:31:37.27 ID:cmecYv9F
>>514
そもそもアクセサなんてものはモダン言語では自動生成なので論外

516 :デフォルトの名無しさん:2017/04/21(金) 21:33:08.50 ID:YTf7CJ3G
>>513
いつもよくわかってないな

517 :デフォルトの名無しさん:2017/04/21(金) 21:34:14.81 ID:JwbSy4qm
その自動生成ってのを嬉しがる精神性が問題
アクセッサなんか書きにくいほうが健全
きみにはまだ伝わらないと思うし
これ以上言葉費やす予定もない

518 ::2017/04/21(金) 21:35:03.27 ID:AJ6tejAv
>>513
一般的に開発ってこんなもんだろ。
物理的な製造業から何まで、本来は。

問題があったら、設計変更の起案からだよ。
設計変更より作り直したほうが安くつくとか考えないといかんだろ。
ソース修正した後に、何を担保にしてその修正が妥当か、どういうテストが妥当かを定義するときに、組み合わせ爆発が起こらんようにIF定義するんじゃん。

>>514
アクセサのあるprivateなメンバなんか、ちょっと運が良ければチェックロジックなんか入ってるかも?運が悪ければ違う値まで変わっちゃうかも?みたいな、余計に面倒くさい奴だしな。

519 :デフォルトの名無しさん:2017/04/21(金) 21:40:55.19 ID:rPWpf+kQ
>>518
修正した設計書通りでしょ?
これがすべてに優先されるんでいいんだよね?っていうかそうじゃなかったらびっくりだわ

前のソースは関係ないよ
privateやpublicに意味なんかないよ

520 ::2017/04/21(金) 21:44:00.25 ID:AJ6tejAv
>>519
修正した仕様書の妥当性はどう計測して、修正したソースの妥当性はどう計測するの?
インアウトが確実に2つずつなら、ステートマシンでも組み合わせ数は知れてるだろうが、
インアウトの数が担保できなければそんなもの検証しようがない。

521 ::2017/04/21(金) 21:46:20.92 ID:AJ6tejAv
逆に言うわ。publicなものの組み合わせを検証する必要が本当に正しいと証明するためにはある。それはnCmで増える。
だから、組み合わせを減らしたい。

522 :デフォルトの名無しさん:2017/04/21(金) 21:47:22.88 ID:cmecYv9F
>>517
いーやわかってないのはおまえ
アクセサの必要性が低いなんてことは歴史的背景ふまえググれば中学生でもわかること
ではなぜ事実上、必須になっているか
そこまで考えてはじめて俺と同じ土俵に立てる
出直せ

523 ::2017/04/21(金) 21:51:18.83 ID:AJ6tejAv
>>522
アクセサは自動生成されるべきじゃないし、される言語も少なくないか?アクセサ作ったらメンバが生えるのはあるだろうけと。

524 :デフォルトの名無しさん:2017/04/21(金) 21:51:19.37 ID:TFy/T03e
publicフィールド = 何の制限もかけられないアクセッサだよ


つまりいずれにしろアクセッサ相当のものを使っているわけで、
問題はアクセッサがいるかどうか?ではなく、
制限をかける必要があるかどうか?

で考えたほうが良い。

525 ::2017/04/21(金) 21:52:38.91 ID:AJ6tejAv
>>521
意味わからん文になってた。証明するためには全パターンを網羅する必要がある、だな。

526 :デフォルトの名無しさん:2017/04/21(金) 21:58:52.01 ID:cmecYv9F
>>523
されるべきなんだよ
何故なら90%のメンバ変数はアクセサなんて必要としないから
残り10%のために手書きなんてバカらしいだろう

527 :デフォルトの名無しさん:2017/04/21(金) 21:59:11.05 ID:rPWpf+kQ
>>520
設計書通りに動くことを確認するよ

これができなくなっちゃうって言ってる?

528 ::2017/04/21(金) 22:07:30.53 ID:AJ6tejAv
>>526
メンバ変数を見ればいいなら、メンバ変数見れば良くない?
アクセサがない限り、見れない書けない方が健全だとは思うが。

>>527
似てるようで違う。
設計書が正しいかが組み合わせ全てを用いないと証明できないし、設計書通りかどうかも同様に証明できない。
インが4本なら16通りだけど、10本だと1024通りだよ。

529 :デフォルトの名無しさん:2017/04/21(金) 22:11:46.98 ID:TFy/T03e
設計書が正しければ、正しいプログラムができるはずだ!

530 :デフォルトの名無しさん:2017/04/21(金) 22:15:10.16 ID:TFy/T03e
設計書が正しいことをきちんとテストする必要がある。

つまり、設計書のテスト仕様書が必要だ。

そしてそのテスト仕様書通りに設計書が
正しいかをテストする人間も必要になる。

そこで重用なのは、テストの手法である。
設計書が正しいことをどうやってテストするか?
つまり設計書を書いた人間への聞き取り作業である。

設計書に書き漏れがないか?設計書に書かれた言葉に矛盾がないか?
テスト仕様書に従って設計書を見ながら設計者を問い詰める。
これが設計書に対する優れたテスト方法である

531 ::2017/04/21(金) 22:21:07.33 ID:AJ6tejAv
揶揄してるようだが、設計書をテストする設計書にあたるものが、設計変更申請書だよ。
それはヒアリングやら検証実験やら、承認者の首やら、人の手で担保するもの
大規模開発した事ないのかな。

532 :デフォルトの名無しさん:2017/04/21(金) 22:22:18.55 ID:cmecYv9F
>>528
アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要
だからモダン言語にはプロパティというものがある
プロパティに出来てpublic変数に出来ないことを考えればおのずとプロパティでいいよねという結論にたどり着くと思うがね

533 :デフォルトの名無しさん:2017/04/21(金) 22:23:36.50 ID:rPWpf+kQ
うーん
ぶっちゃけそれとカプセル化との関連が不明
もはや何を主張したいのか滅茶苦茶な気がするんだけど

534 :デフォルトの名無しさん:2017/04/21(金) 22:24:22.02 ID:TFy/T03e
> 設計書をテストする設計書にあたるものが

意味わからん。

設計書をテストするものは、設計書のテスト仕様書だ。

つまりその設計には、○○の場合の処理は抜けていないか?
○○の場合に不整合は起きないか?
などというものが書かれいいるもので無ければ、
設計書のテスト仕様書とはよべない。

535 :デフォルトの名無しさん:2017/04/21(金) 22:25:20.57 ID:rPWpf+kQ
>>520の発言内容はカプセル化と関係ないよね?

536 :デフォルトの名無しさん:2017/04/21(金) 22:26:41.05 ID:TFy/T03e
>>532
> アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要

アクセッサはアクセス制限ではなく、アクセスした後に入れようとした値が
正常値かどうかを判断するもの。
型だけでは表現できない特殊なルールを記述する所
アクセス修飾子は単にアクセスできるかどうかしか記述できない。

537 :デフォルトの名無しさん:2017/04/21(金) 22:32:34.16 ID:cmecYv9F
>>536
それは俺にレスするな
>>528の疑問に答えただけだから>>528にいえよ

俺の主張はgetter、setterの是非なんてものは時代遅れもいいところでその解がプロパティだろってことだけだ

538 ::2017/04/21(金) 22:32:51.15 ID:AJ6tejAv
>>532
プロパティはメンバ関数だよ。
C#ならIL見ればわかるけど、確かアンスコついた変数出来てる。
プロパティ自体もフツーに関数。
何で見えない変数が必要なのか、ってのは、副作用があるプロパティを書くことが出来る限り不必要にならない。
Queueみたいなもののgetのアクセサが、デキューして返すみたいなコードだと、デキューせずに先頭を見る方法が無くなる。

>>534
段取りがおかしい。「設計書のテストの仕様書」が成立するためには、「設計書の設計書」が必要。
なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。
「xxの処理は漏れていないか」は「xxの処理が必要だと定義されている」から書ける。
そのための要件は、すり合わせと設計変更申請のレビューと相手方、担当者の連名の捺印で担保する。

>>535
あるよ。
組み合わせが妥当な手段ではこれ以上ないと言う事が、数が少なくなればなるほど簡単になる。

539 :デフォルトの名無しさん:2017/04/21(金) 22:34:09.19 ID:TFy/T03e
>>538
> なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。

設計書を書く → その設計書のテストを書く
何の問題もないじゃないか

540 ::2017/04/21(金) 22:34:35.69 ID:AJ6tejAv
>>537
getter,setterとプロパティってシンタックスシュガー以上の違いある?Kotlinとか、getterとsetterを暗黙のプロパティに変換してくれるが。

541 ::2017/04/21(金) 22:35:44.20 ID:AJ6tejAv
>>539
おまえふざけんなよw

542 ::2017/04/21(金) 22:37:04.70 ID:AJ6tejAv
実装してからのテスト作成って何の意味があるのか意味がわからん。

543 :デフォルトの名無しさん:2017/04/21(金) 22:42:23.85 ID:TFy/T03e
>>542
確認作業だろ?

そもそも似たようなことは検収作業でやってるだろ

544 :デフォルトの名無しさん:2017/04/21(金) 22:43:24.15 ID:rPWpf+kQ
カプセル化は不要でおk?

545 :デフォルトの名無しさん:2017/04/21(金) 22:44:14.67 ID:YTf7CJ3G
>>544
カプセル化は必要でおk

546 :デフォルトの名無しさん:2017/04/21(金) 22:45:28.27 ID:cmecYv9F
>>538
んなことはわかってるっつーの
だからなんだよ
getter setterなんていらねーよという話から始まってる議論になんの関係がある

547 :デフォルトの名無しさん:2017/04/21(金) 22:49:35.08 ID:rPWpf+kQ
>>545
じゃあどうして>>506からの流れでカプセル化必要派は壊れてしまうん?

548 :デフォルトの名無しさん:2017/04/21(金) 22:51:43.93 ID:YTf7CJ3G
>>547
そうか
理解できないから壊れた判定して逃げるんだな

549 :デフォルトの名無しさん:2017/04/21(金) 22:52:25.01 ID:1EW2mi9U
おまえら相変わらず低レベルな会話してんなww

550 :デフォルトの名無しさん: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もなぜか効かない設定

551 :デフォルトの名無しさん:2017/04/21(金) 22:56:49.22 ID:YTf7CJ3G
>>549
ぜひ収拾つけてくれ
俺にはどーもできん

552 :デフォルトの名無しさん:2017/04/21(金) 22:57:14.58 ID:cQz9sGMN
至高の言語はswiftだよ
swiftが全ての正解

553 :デフォルトの名無しさん:2017/04/21(金) 23:05:20.32 ID:IMFbV+tE
>>552
#ifdefのくせになまいきな

554 :デフォルトの名無しさん:2017/04/21(金) 23:07:41.24 ID:rPWpf+kQ
>>548
じゃあ、設計書をかく前提の開発でカプセル化が必要な理由を説明してよ

555 :デフォルトの名無しさん:2017/04/21(金) 23:15:04.82 ID:IMFbV+tE
実際に不正な操作がされていないということを保証できるから

設計書ベースだと、オブジェクト使うときは
規約をしっかり読んで、それに抵触しないよう用心してコーディングし、
変なことが起こった時
設計書の記述みて、コード上でオブジェクトの使用箇所全部洗って、
操作の規約が守られてるかどうか逐一人間がチェックして、
それではじめてprivateの一言と同じ成果となるのだ

やってられんしそもそも間違えるし

556 :デフォルトの名無しさん:2017/04/21(金) 23:16:10.52 ID:YTf7CJ3G
利用者はちゃんと設計書を確認しながら使うとは限らないって何度も言えば、、、

557 :デフォルトの名無しさん:2017/04/21(金) 23:16:16.72 ID:fRfyQmKB
>>378
たとえば、インスタンス変数aに依存&結構コストのかかる計算で決まる値bがあったとき
bをインスタンス変数bにキャッシュしておくほうが得だよね?
publicにしたaの変更をどうやってフックするの?

558 :デフォルトの名無しさん:2017/04/21(金) 23:22:50.81 ID:rPWpf+kQ
>>555
バカなんだね
君はもうレスしなくていいよ

559 :デフォルトの名無しさん:2017/04/21(金) 23:24:54.21 ID:1EW2mi9U
>>551
普通の人間には無理w
ID:rPWpf+kQは頭の出来が異次元すぎるwww

560 :デフォルトの名無しさん:2017/04/21(金) 23:26:01.68 ID:JwbSy4qm
バカじゃない人間なら
機械語とバイナリエディタでOS作れてもおかしくない

561 :デフォルトの名無しさん:2017/04/21(金) 23:27:08.71 ID:IMFbV+tE
ただの煽りかげんなり
ほんとに信じて言ってるのかと思ってた

562 :デフォルトの名無しさん:2017/04/21(金) 23:28:45.45 ID:YTf7CJ3G
>>559
そーだよなぁ
ただ喚くだけだしね

563 :デフォルトの名無しさん:2017/04/21(金) 23:34:32.77 ID:V+qA1SkC
>>393
dllやクラスファイルの形で、コードの無いクラスもあるんやで?
クラスやメソッドは紙やWebのみってのが。

564 :デフォルトの名無しさん:2017/04/21(金) 23:38:07.22 ID:rPWpf+kQ
>>563
それとカプセル化になんの関係があるの?
よく考えて発言してねバカなんだから

565 :デフォルトの名無しさん:2017/04/21(金) 23:48:31.04 ID:go/6WchZ
>>557
ずれたコメントさせてもらうが、俺ならそのbを計算した都度出力して、自らはキャッシュしない方策を考えるな。

566 :デフォルトの名無しさん:2017/04/21(金) 23:52:18.75 ID:YTf7CJ3G
>>564
よく考えて発言してね
まぁ自分がバカと認識してるだけマシだけど

dllで提供されたものが他のものに依存してて単体で動かないとか、動くけど他のdllで得るはずの値を利用すること前提だとしたらその前提を知らない奴はうまく使えない
内部の処理を隠蔽し独立した動きを提供すればいいだけなんだよ

567 :デフォルトの名無しさん:2017/04/21(金) 23:53:01.61 ID:V+qA1SkC
ん?
カプセル化でprivateしてないと勝手にフィールド書き込んでしまう恐れがある。
コード無いからprivateにする意味ある。
そんな例。

あ、publicなフィールドを紙やWebに書かなければいいと言うのはなしね。
ツールが抽出するんで。
手書きじゃ無いんで。

568 :デフォルトの名無しさん:2017/04/21(金) 23:54:06.38 ID:Ck7s6rRh
エンジニアガイジさあ…… 住処が荒廃したからってここに雑魚狩りに来るのやめなよ

569 :デフォルトの名無しさん:2017/04/22(土) 00:12:26.79 ID:EzjUI0a0
日を跨いだら突然おとなしくなったなぁ

570 :デフォルトの名無しさん:2017/04/22(土) 00:28:58.48 ID:OS/5Qg75
>>554
設計で呼び出し元に制限を規定するのであれば、試験仕様書には制限外の呼び出しはNGの試験が用意される
上記を満たす実装はカプセル化と呼ばれるのでは?

571 :デフォルトの名無しさん:2017/04/22(土) 01:06:43.76 ID:+5rvIbLJ
>>570
呼ばない

572 :デフォルトの名無しさん:2017/04/22(土) 02:31:18.17 ID:IBUJYaHp
>>569
なんかわからんけど、このバカも睡眠という概念がなさそうだな。

573 :デフォルトの名無しさん:2017/04/22(土) 09:50:00.49 ID:69jc9pki
>>565
ずれるにしてもほどがある

574 ::2017/04/22(土) 11:07:46.29 ID:HbmQ/gQM
>>568
うーん、ノセられてしもたわ。そもそも論で焼け野原にするのは好ましくはないな。
気をつけよう

575 :デフォルトの名無しさん:2017/04/27(木) 12:52:25.26 ID:FdhNErTM
部品として使う場合、知識が要求されるのが、ちと時代おくれかなー

576 :デフォルトの名無しさん:2017/05/02(火) 18:17:11.49 ID:VYotzEOG
カプセル化、継承、オブジェクト指向設計論に熱が入るやつは
そろそろ自分が動的言語童貞だと熱弁していることに早く気がついたほうがいい

577 :デフォルトの名無しさん:2017/05/02(火) 18:21:39.30 ID:Bg5rWx47
>>576
動的言語が得意な人は、オブジェクト指向にとって大事なことは何だと思うの?

578 :デフォルトの名無しさん:2017/05/02(火) 19:36:25.52 ID:S4n1GgbR
Objective-Cって動的言語だったのか

579 :デフォルトの名無しさん:2017/05/02(火) 19:36:57.13 ID:S4n1GgbR
てっきりオブジェクト指向言語かと思ってた...ん?

580 :デフォルトの名無しさん:2017/05/06(土) 04:26:04.66 ID:gDC1nU6T
それにしても(Javaの)クラスのインスタンス化の勉強がすごく楽しい。

581 :デフォルトの名無しさん:2017/05/06(土) 09:08:09.40 ID:QDs+whcb
はい

582 :デフォルトの名無しさん:2017/05/06(土) 09:48:33.69 ID:ZTeBEUxt
局所的すぎてわろ

583 :デフォルトの名無しさん:2017/05/18(木) 13:53:51.24 ID:V9vRGfQu
マジでクラスの分け方教えてくれどう分ければいいんだよ
分けたとしてもどのクラスにどうデータ持たせて
クラス間の受け渡しとかどうすんだよ全部ゲットセットでpublicにしてええんか

584 :デフォルトの名無しさん:2017/05/18(木) 15:26:21.38 ID:F9Zp5ygI
>>583
データホルダー
計算役
データ管理役
UI仲介役

抽象的だがこんな分け方だろう

585 :デフォルトの名無しさん:2017/05/18(木) 18:10:53.86 ID:zzewDZCb
小人さんだと思え。「おまえはこれをやる小人さんだ!」って決めろ。

586 :デフォルトの名無しさん:2017/05/18(木) 18:14:11.48 ID:pcJKb7uP
>>583
ゲットもセットも要らない
全部パブリックフィールドでダイジョブです
カプセル化はオブジェクト指向に不要な概念と言っていいでしょう

587 :デフォルトの名無しさん:2017/05/18(木) 19:11:55.79 ID:me+sOo3Z
>>583
クラス分けで悩むならグローバル変数なくしてやりすぎなくらいメソッドを細分化してみたらいいよ

588 :デフォルトの名無しさん:2017/05/18(木) 19:53:26.01 ID:F9Zp5ygI
>>587
なるほど

589 :デフォルトの名無しさん:2017/05/18(木) 23:04:55.06 ID:yt/el+BP
>>583
世の中の仕組みと一緒だ。
社長が部下に指示を出す。
部下は結果を返す。
社長は、別の会社と連携してサービスを広げていく。

全ては機能を有していて、機能同士が連携してより大きな機能を作っていくだけだ。

590 :デフォルトの名無しさん:2017/05/19(金) 02:05:14.71 ID:879cm/wV
>>583
日本語的な表現でクラス分けをやるとしたら
「いくつも仕事をしていないこと」というのが目安だろうか

例: 「入力値のバリデーションやる」「設定ファイル読んでパラメータ保持」
怪しい例: 「ユーザー設定をDBから読んでパラメータに基づきUIをイジくって表示する」

数値的な目安が欲しいなら、パブリックメソッドが7以上あったら
そのクラスは複数の仕事を抱えている可能性があるんで、分割を検討する
まあ共通で使うクラスが太ってしまうことはよくあるけど
7ってのは平均的な人間がチラ見でパっと暗記できる事柄のリミット値

591 :デフォルトの名無しさん:2017/05/19(金) 19:43:17.99 ID:7xgwPeWo
>>583
MVCモデルとかアーキテクチャで調べる
依存性の注入で調べる
完全コンストラクタで調べる

この辺り守ってれば自ずと決まる

592 :デフォルトの名無しさん:2017/05/19(金) 20:11:31.04 ID:LqS/uk9i
オブジェクト指向って「学び」がないんだよな
文法が全て同じになって処理のパターンみたいなのが
すべて「名前」で隠蔽されて見えてこない。
処理の委託元のコード追ってもたらい回しにされてる感じで
「実際の処理」がどこにあるのか埋もれてしまってる状態になる。

593 :デフォルトの名無しさん:2017/05/19(金) 21:11:32.92 ID:A6bTtmgj
どうやって隠すか
ライブラリ作成側になると学びは多いよ

594 :デフォルトの名無しさん:2017/05/19(金) 22:24:14.23 ID:2Tw6P143
>>592
スタックトレースを見るんだ

595 :デフォルトの名無しさん:2017/05/20(土) 06:03:34.30 ID:5T5O2UEX
大きなシステムとか組んだ事ないんだろ

596 :デフォルトの名無しさん:2017/05/20(土) 18:54:10.07 ID:urI3JAo7
まあ実際の処理を隠蔽するのがまさに1つの目的だし
たらい回しというか参照辿って芋づるで引っ張れる設計じゃないし、むしろそこがオブジェクト指向のキモだからな

597 :デフォルトの名無しさん:2017/05/20(土) 19:17:55.25 ID:mYqGvY+G
実際の処理が見れないと困るケースがもしあれば
設計が既に破綻してるって話だわな

598 :デフォルトの名無しさん:2017/05/20(土) 20:09:39.79 ID:1WQ4/ic9
役員が下っ端社員の細かい作業手順を知る必要ないからな。
ちゃんと結果報告が上がってくれば作業手順は他の人間に影響を与えてなければ関係無い。

599 :デフォルトの名無しさん:2017/05/20(土) 20:38:10.12 ID:POVmnKPN
オブジェクト指向は総活躍社会

600 :デフォルトの名無しさん:2017/05/21(日) 01:27:28.98 ID:Fqssqcja
>>597
図面的な意味で設計どうこうじゃなくて「なんかバグ出てるのはわかるんだけど
誰が調べても原因がわからん」系の状況じゃね?

継承四連打キメてて3段目で特定のタイミングのみ変数上書きワロスみたいな……

601 :デフォルトの名無しさん:2017/05/21(日) 04:39:36.10 ID:bMGEt1tu
>>597
無茶いうな

602 :デフォルトの名無しさん:2017/05/21(日) 10:57:27.44 ID:8IHB32RP
>>600
597じゃないけどそういうのは設計が破綻していると言うと思う
図面の設計て意味じゃなくて作成者のプログラミング設計って意味で

603 :デフォルトの名無しさん:2017/05/21(日) 12:54:25.54 ID:W3P4J6B5
世の中のソースコードの90%の多段継承は既に破綻してる、もしくは今後するけどな
つまり仕組みが糞

604 :デフォルトの名無しさん:2017/05/21(日) 17:51:03.66 ID:/ema5D/U
>>600
結局、オブジェクト指向ってただ作るだけなら得意なんだけど
正しく作っているか確認することは苦手なんだよね

そりゃあ設計はあるだろうし、設計通りに作られていれば問題ない。
でも設計通りに作られているのかの検証は、より困難になっている。

605 :デフォルトの名無しさん:2017/05/22(月) 12:24:20.53 ID:D5FtIlcH
なんか"経理部に領収書出して「清算お願いします」ってシステム"に
延々「経理部が不正やってないとも限らないよね!検証できないよね!」って
無根拠にただ喚いてる奴がいるみたいになってて相手のしようがないんだが、おまえ。

606 :デフォルトの名無しさん:2017/05/22(月) 12:36:09.78 ID:396ysVMZ
>>605
アホ

607 :デフォルトの名無しさん:2017/05/22(月) 19:27:44.11 ID:VfSiR++X
>>586
カプセル化が一番重要と思ってたんですが違うんですか?

608 :デフォルトの名無しさん:2017/05/22(月) 19:30:22.25 ID:+aWzImQa
ソース付のライブラリ使えば?

609 :デフォルトの名無しさん:2017/05/22(月) 20:40:23.17 ID:OXuVg63m
>>607
カプセル化が修正の閉鎖をもたらし
インターフェースが拡張の開放をもたらす
両方いる

610 :デフォルトの名無しさん:2017/05/22(月) 22:48:06.26 ID:rXkCxzW6
やっぱりどっちもいらない

611 :デフォルトの名無しさん:2017/05/24(水) 19:52:46.15 ID:E7SQQ2ii
>>607
ゲッタセッタが生えてるプライベートフィールドはパブリックと変わらないってことだろう
要するにそれはカプセル化とは言わない
それやるぐらいならむしろパブリックの方がゲッタセッタの裏で余計なことしてない保証になる

612 :デフォルトの名無しさん:2017/05/24(水) 20:02:53.29 ID:MizSfTrk
>>607
俺も重要だと思ってるけどその話題は荒れるので出さないようにしてる

613 :デフォルトの名無しさん:2017/05/24(水) 20:51:58.45 ID:0TwgkzQZ
カプセル化の話だとデータの隠蔽のことばかりになってしまうのは残念じゃのう

614 :デフォルトの名無しさん:2017/05/24(水) 22:22:46.76 ID:mgEFkV8x
メソッドオーバーライドやインターフェース実装(具体例はJavaのinterface)も一応カプセル化の範疇だろうが
どっちかってと「継承」とか「クラス図」とか「デザパタ」の文脈で話す場合が多いかも

615 :デフォルトの名無しさん:2017/05/24(水) 23:27:44.78 ID:krzOkTvb
>>614←こいつわかってなさそう

616 :デフォルトの名無しさん:2017/05/25(木) 00:11:42.62 ID:W6ilo8po
詳細を隠し、結合度を弱め、変更に強くする、だっけか?
ただ、まあ面倒い

C#の新しいプロパティ構文がJavaでも使えればいいのにな

617 :デフォルトの名無しさん:2017/05/25(木) 07:20:20.62 ID:06hv3Ht1
哲学やると頭腐る

618 :デフォルトの名無しさん:2017/05/25(木) 07:29:05.76 ID:iVz5yu8w
最初から?

619 :デフォルトの名無しさん:2017/05/25(木) 14:20:37.34 ID:R5hiuhFH
>>611
データの整形はいずれにしても必要なわけで問題はどこで整形するか
クラス外で何カ所も整形の処理書くよりプロパティ内に書いた方がいいよね

620 :デフォルトの名無しさん:2017/05/25(木) 21:00:55.82 ID:a5WTl5cb
>>619
ゲッタセッタで公開されたプライベートフィールドと、書式化された文字列を返すプロパティって全然別物じゃんアホなの

621 :デフォルトの名無しさん:2017/05/25(木) 22:16:33.15 ID:06hv3Ht1
>>611
SetterGetterの殻に閉じこもってプログラミングする安心感は異常

そんな保障してなんの役に立つ
どのみちオブジェクトを関数の引数にしたら、どこで何されるかわかったもんじゃない

publicにしたら処理をフックすることもできない
へんな値が設定されたときに例外をだすこともできないし
Audio.volumeでボリューム設定なんてこともできないだろう

622 :デフォルトの名無しさん:2017/05/26(金) 12:49:01.87 ID:nbqvOpds
セッタゲッタ作って役に立ったこともあるだろうが、無駄にコードが増えただけのこともあるだろう
無条件にやるのはただのバカ。フックいれることが予想される場合にするのはいい

623 :デフォルトの名無しさん:2017/05/26(金) 14:05:46.16 ID:tID9m1OJ
>>622
Yes

624 :デフォルトの名無しさん:2017/05/26(金) 15:13:04.21 ID:FvwfjnU+
そのクラスのユーザが自分だけじゃない場合は、とりあえず全部privateにして、getter/setter作っといた方がいいね

625 :デフォルトの名無しさん:2017/05/26(金) 16:21:29.95 ID:Heb9aC5z
getter,setterを通じて変数に触れるのであればそれはもはやprivateとは言えないと思ってる

626 :デフォルトの名無しさん:2017/05/26(金) 16:22:11.52 ID:Heb9aC5z
getterはまだ良いけどsetterは要らないなぁ

627 :デフォルトの名無しさん:2017/05/26(金) 16:37:50.24 ID:FvwfjnU+
>>625
> getter,setterを通じて変数に触れるのであればそれはもはやprivateとは言えないと思ってる
言いたいことはわからなくもないが、クライアントコードとそのクラスの接点がsetter/getterであると
保証されていれば、内部構造の変更は自由になるというのが異なる。

628 :デフォルトの名無しさん:2017/05/26(金) 18:31:35.52 ID:Heb9aC5z
確かにね
言ってることはよくわかる
だとしてもsetterは用途が限られるように感じてる

それならインスタンス生成時に必要な情報を全部ぶち込んじゃえばいいんじゃね?と最近考えてる

629 :デフォルトの名無しさん:2017/05/26(金) 19:19:04.64 ID:grHVRT/B
class1
{
public int setInt;
public string setStr;
}

class2
{
public int setInt { set; get; }
public string setStr { set; get; }
}

この2つの違い教えて
外のクラスから参照・変更するだけなら同じ扱い?

630 :デフォルトの名無しさん:2017/05/27(土) 10:49:30.96 ID:ieplBCy2
>>626
後でconfigの類を入れるとか、setLoggerだとかで
必要になる場面がたまにあるかも

なおPythonでそれやろうとしてプロパティデコレータ使おうとしたら「setだけのデコレータはない」というので
またPythonの俺様仕様か……って閉口した

631 :デフォルトの名無しさん:2017/05/27(土) 10:59:35.13 ID:u9alIOxt
setterだけってことは

obj.x = 1 #=> これは出来る
obj.x #=> 例外

になって欲しいってことか?イラネ

632 :デフォルトの名無しさん:2017/05/27(土) 11:03:59.72 ID:HaHIN1I5
メンバを個別にセットゲットする需要ってそんなにないだろう?

633 :デフォルトの名無しさん:2017/05/27(土) 11:16:48.16 ID:ieplBCy2
>>631
obj.config = user_config

みたいなのだ
setconfig(user_config)でもよろしかろうが、readwriteとreadは機能としてあるけどwriteはない
なんて片手落ちはあんまり想像してなかった
「正しいやり方はwriteイラね」とかマニュアルに書けってよ

634 :デフォルトの名無しさん:2017/05/27(土) 11:58:55.24 ID:0+MwcC+M
getter,setterはメソッドなのでクラス中で処理してクラスとして必要な形で出し入れできる
直接さわることとは別物だよ

635 :デフォルトの名無しさん:2017/05/27(土) 12:19:45.90 ID:HaHIN1I5
>>634
それはみんな分かってるんじゃないかな
>>583あたりからの流れで、全部のフィールドにゲットセット持たせることの是非を言ってるんだと思う。

フィールド(メンバ変数)が複数あったとして、ゲットセットする需要というか意味があるのは
ごく一部なんじゃないか。

636 :デフォルトの名無しさん:2017/05/27(土) 12:38:09.02 ID:ieplBCy2
理想: getter/setterはメソッドとすべき
setterで引数のチェック、getterでoutはコレであってるかのチェックはもれなくやるべし

現実: やらなくてもだいたい例外が飛ぶか動かないかするからわかる

637 :デフォルトの名無しさん:2017/05/27(土) 12:45:31.51 ID:5/vhXFvj
ないとバカが騒ぐから作っておけばいい
こんなつまらん事でわざわざバカにエサを与える必要はない

638 :デフォルトの名無しさん:2017/05/27(土) 17:30:05.68 ID:N4GV+Pp+
ゲッタセッタにフックさせる「かもしれない」をどう受け取るかによるから不毛と言えば不毛
柔軟に拡張できると受け取れば良しとなるし、不要な可能性を残すと受け取れば悪しとなる

個人的には単純にゲッタセッタで命名しといてくれるとインテリセンスでプロパティ探す時楽だからあった方がいい
ただゲッタセッタで命名しときながら裏で全然関係なかったり重い処理してる糞コード書く奴が一定数いるのも現実

639 :デフォルトの名無しさん:2017/05/27(土) 17:46:00.50 ID:3Q4GI2w6
クラス設計が下手くそなオブジェクト指向初心者なんだけど、ためになる読み物とかないですかね?
cはある程度書ける

640 :デフォルトの名無しさん:2017/05/27(土) 19:33:03.59 ID:g5q+CjXh
構造化プログラミングって何?

641 :デフォルトの名無しさん:2017/05/27(土) 19:54:27.21 ID:SDTaiU/Z
>>639
うまいやつに自分が作ったモデル添削してもらえ
一瞬で上級者になるぞ

本はしらん本よみまくったけど結局それだけだとだめだった

642 :デフォルトの名無しさん:2017/05/27(土) 20:24:02.87 ID:4M5qtD6v
>>640
ダイクストラ知らないとかゆとりかよ

643 :デフォルトの名無しさん:2017/05/27(土) 20:57:24.04 ID:H74RUeqi
老害的罵倒例

644 :デフォルトの名無しさん:2017/05/27(土) 21:35:03.31 ID:583uXQeo
>>639
変な意見だけどHaskellを勉強する。
割とマジで。
互いに疎とか、モナドとか高階関数は依存関係解消のヒントになる。

645 :デフォルトの名無しさん:2017/05/29(月) 03:13:17.41 ID:vyxh58aI
>>642
自分の言葉で説明して欲しいです。

646 :デフォルトの名無しさん:2017/05/29(月) 08:38:09.71 ID:U7XwlEVB
>>645
Wikipediaとか読んで自分でそれをできるようになったがいんじゃない?

647 :デフォルトの名無しさん:2017/05/29(月) 08:44:08.38 ID:U7XwlEVB
構造化プログラミングとは
関数、if、whileを使ってプログラムを書くこと

誤解を恐れず言うならswitch、forは邪道です

648 :デフォルトの名無しさん:2017/05/29(月) 11:07:58.25 ID:TgEUVyWp
はい次

649 :デフォルトの名無しさん:2017/05/29(月) 12:09:15.00 ID:BkgkdtpP
>>648
次はお前の番だよ

650 :デフォルトの名無しさん:2017/05/29(月) 12:10:47.18 ID:BkgkdtpP
おらあああ!!さっさと説明してみろや!

651 :デフォルトの名無しさん:2017/05/29(月) 12:11:45.18 ID:vyxh58aI
>>647
wiki読んだけど、それぐらいの意図しか汲み取れなかった。

オブジェクト指向では、ポリモーフィズムとか使えるけど、それも結局はクラスでifしてるだけであって、たいして変わらないじゃんと思った。

652 :デフォルトの名無しさん:2017/05/29(月) 12:18:49.21 ID:CxTrZaFu
ポリモーフィズムとifが同等って初めて知った

653 :デフォルトの名無しさん:2017/05/29(月) 12:24:48.88 ID:KD+R0FhF
分かるだろ普通w

654 :デフォルトの名無しさん:2017/05/29(月) 12:34:49.38 ID:CxTrZaFu
何を基準に普通と言ってるかは知らないけど同じ扱いをしても振る舞いが異なる事だと思ってたからなぁ

ここを見てるとどれだけ自分の頭が固いかよくわかっておもしろい

655 :デフォルトの名無しさん:2017/05/29(月) 19:29:07.89 ID:w9I7HLjv
一回、アセンブラからやらせて
自分で自分が書いたスパゲッティをメンテするところからやらせねぇと
なんで生まれてどんなメリットを目指したかわかんねぇんじゃねぇの
ゆとりには

656 :デフォルトの名無しさん:2017/05/29(月) 19:42:05.10 ID:CxTrZaFu
知らなくても組めるように発展してんだから意図なんか後から知ればいいんだよ

657 :デフォルトの名無しさん:2017/05/29(月) 20:16:08.98 ID:KNNrZWoY
いつまで経ってもオブジェクト指向の意図が理解できない変な人が湧き続けるスレで言うことか。

658 :デフォルトの名無しさん:2017/05/29(月) 22:18:26.47 ID:A34reMmc
オブジェクト指向の意図ってなんだよw
こんなものまで擬人化しないと気がすまんのかお前らw
キモいにも程があるwww

659 :デフォルトの名無しさん:2017/05/29(月) 22:22:54.39 ID:nT+AAD4u
オッ

660 :デフォルトの名無しさん:2017/05/29(月) 22:25:41.12 ID:w9I7HLjv
ここまで国語力ない奴はじめてみた。

661 :デフォルトの名無しさん:2017/05/30(火) 02:01:38.87 ID:KOCwrIWS
>>652
同等じゃないよ

ポリモーフィズムはそもそも参照先が違う
演算によって処理を分けるif文とは全く違う

662 :デフォルトの名無しさん:2017/05/30(火) 02:16:15.25 ID:734VgA5Q
>>651
呼び出す側が適宜、相手のインスタンスに「こういう動作して」って派生クラスぶっこむ場合が多いな
まぁ派生元 - 派生先でifしてるって捉え方もできようが
if - elseが下に7コ8コ並んで見難いのよりはマシだろう

663 :デフォルトの名無しさん:2017/05/30(火) 19:10:33.85 ID:cuCpV+Ml
>>658
Objectの言葉の意味の通りじゃん

664 :デフォルトの名無しさん:2017/05/31(水) 17:32:41.97 ID:lwNSc7pn
オブジェクト指向開発の理解度を測るために民間団体の主催するJAVA検定を受けようと思うのですが、そもそもここの問題はオブジェクト指向となっているでしょうか

http://www.sikaku.gr.jp/js/jv/img/sample/1/jv1.pdf

過去に構造化プログラムとかクソ味噌言われていたので、オブジェクト指向に造詣の深い皆さんに評価して頂きたいです

665 :デフォルトの名無しさん:2017/05/31(水) 18:37:16.96 ID:vzRkDbrn
>>664
やめとけ

666 :デフォルトの名無しさん:2017/05/31(水) 18:46:16.77 ID:lqV8qj25
理解度測るならフリーで仕事すればいい
稼いだ金額が理解度

667 :デフォルトの名無しさん:2017/06/01(木) 03:12:10.50 ID:TLZ7U8Co
>>664
実務でやるなら、4番のシーケンス図よろしく「N」なんて打ち込ませねぇ
そもそもあんなクソみたいな手数を踏ませるはイカれてるっていうか、ユーザーは怠惰なんス
一手で済ます
たぶんログイン画面でセッション(あるいは何らかの認証情報)を持たすのが前提だあな

っていうか「Fuckyou」とか「let me die」って打ち込んだ時どうすんだね
この図だと未定義だから何してもいいよね、俺だったら「Fuckyou」ってタイプされたら水龍敬ランド出すし
「let me die」ってタイプされたらガルパンのまほお姉さまのエロ同人誌でも表示してやるわさ
……冗談やで?

というくらいなんかアレかも

668 :デフォルトの名無しさん:2017/06/01(木) 03:35:10.17 ID:TLZ7U8Co
そしてまさかのNはユーザーの氏名でした、か(今アレって思って見直したら) orz ごめん手抜きした
まあいいや、見直すとして……ああうんお呼びでないか

シーケンス図を(マジメに)見る限り

・初めに二回ポップアップ出す(or二発画面遷移をせよってこと、メソッドが二発あるので)
・ユーザーがNっていれたら、初めに出たのとの同じポップアップを2発やる(displayFirstMess/displayPromptMessをもう一度ぶっぱしてるから)
・imputMessageでユーザーが入力をいれたら
 まずユーザー一覧を表示するのか、「検索方法を指定してください」と出すのかして(displayFirstMessはどうもでっかく二分岐してるのかもしれん、あるいはまた「検索方法を指定してください。」と出すのか)
 そのあとでallDisplayでドカっと下に長い表示を出すのか
 この辺要確認、たぶん書き手はそんなの想像してないと思う
 たぶんGoogle検索のようなのを想定してるはずなので
・ユーザーは表示された従業員名とID突き合わせて入力欄にID打ち込んでEってタイプする
 ここも確認が必要、クリックじゃねぇの?

ああうんこれメインフレーム時代のやり方やで

669 :デフォルトの名無しさん:2017/06/01(木) 03:36:55.80 ID:TLZ7U8Co
あーうん、let me dieって言われたらまほ姉がおっさんにピーされる機能は実装が必要だな
俺以外望んでないけど未定義だからいいよね(実務じゃしないよ、冗談だから)

670 :デフォルトの名無しさん:2017/06/02(金) 01:49:27.48 ID:w5TyDgot
今Haskellとの比較にPython/Rubyに追加で究極的なオブジェクト指向言語であるsmalltalkでコマンド作るべくgnu-smalltalk勉強中なんだが、条件分岐やループまでオブジェクトへのメッセージなんで、
squeak/PharoみたいなGUIなsmalltalkじゃない事でシステムブラウザ(動的クラスリファレンス?)無しじゃ相当厳しい。

Ubuntu Linuxでsudo apt install gnu-smalltalkしただけじゃgst-browser起動しなかったから、
tar玉落としてコンパイル段階から環境構築してやっと動いた。

んで思ったんだが、やっぱオブジェクト指向ってクラス覚えないと何も出来ないんじゃね?
中途半端なオブジェクト指向言語って構造化プログラミングの文法に助けられてて、
その辺誤魔化せてるだけのような気がして来た。

671 :デフォルトの名無しさん:2017/06/02(金) 07:47:26.08 ID:vc1fSB5M
>>670
システムブラウザまで使うならなぜGNU Smalltalkみたいな変わり種Smalltalkにこだわるのかわからんけど(何かPharoやSqueakじゃ駄目な事情が?)
クラス(というか組み込みのオブジェクト)の使い方を覚えないと何も出来ないというのはかなり正しい

ただそんなこともあってSmalltalk環境は相当早い段階から組み込みの(クラスを含む)オブジェクトに対する問い合わせ
つまりイントロスペクション機能やそれをサポートする(人間の短期記憶に負担をかけないようにする)
マルチウインドウシステムが発達したわけ

だから、繰り返すけどそれらの機構を大胆に削ったのウリのGNU Smalltalkで
「Smalltalk(やそれが体現するOO)が何か」を論ずるのはちょっと違うかもと老婆心ながら

672 :デフォルトの名無しさん:2017/06/02(金) 07:58:55.45 ID:StUXAGh/
Smalltalkがウンコなだけだよ
アランケイにも捨てられたゴミ

673 :デフォルトの名無しさん:2017/06/02(金) 08:32:54.40 ID:uW9UgDbU
>>671
> 何かPharoやSqueakじゃ駄目な事情が?

すみません。ちゃんと理由が書いてありましたね。^^;
>>670
> コマンド作るべく

ただ最終的にGNU Smalltalkを使うにしても、まずはSqueakやPharoから入るのがいいかとは思います

>672
> アランケイにも捨てられたゴミ

アラン・ケイが Smalltalk を見捨てた発言をするのは宮崎駿の引退宣言みたいなもので
最初は1976年ごろからはじまって、10年ぶり5度目とかの恒例です

674 :デフォルトの名無しさん:2017/06/02(金) 09:09:40.41 ID:SS0iDM0a
ほい(おそらくガセ)

http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

675 :デフォルトの名無しさん:2017/06/02(金) 09:10:16.04 ID:DxIdV4KE
SmalltalkはIDEがなきゃCよりも書きにくく、
IDEを使うためにはヘンテコなOSモドキの使用を強制され、
それを我慢して使っても他の言語より書きやすいわけでもなく
マイナー言語なのでライブラリも少ない

まさにゴミ

676 :デフォルトの名無しさん:2017/06/02(金) 09:36:01.61 ID:uW9UgDbU
>>675

まあそう言わんと

ただヘンテコなゴミだと簡単に切り捨てるより、いろいろ調べて学びを得た方が面白いですよ

同時期に登場した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

677 :デフォルトの名無しさん:2017/06/02(金) 10:52:54.67 ID:PwRFjZu6
>>673
いあ、昔squeakやってたし、当時はクラスブラウザと自由自在Squeakあれば十分なくらい独学しやすい言語だと思ってた。
当時はJavaのクラスリファレンス(とら本)も分厚いのを上下巻2冊で売ってたし、クラスたくさん覚えて行くのが当たり前と思ってたからね。

HaskellもLispも、関数覚えておけば便利だけど、覚えてない知らない場合も自分で自作しやすい。
そう言う意味じゃCとかの構造化プログラミングも関数やクラスを基本にするんじゃなくて、Goto使わなくて済む構文によってスパゲティコードを無くすっていう自作し易さを目指す進化だったんよね。

678 :デフォルトの名無しさん:2017/06/02(金) 11:34:30.40 ID:PwRFjZu6
何というか、オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化で、自作のし易さを加速させる、根源的な生産性を上げる進化じゃ無い気がして来たのよな。

679 :デフォルトの名無しさん:2017/06/02(金) 11:53:23.75 ID:ybQLwqcw
>>677
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でのやり方になります

覚えておくよりはその都度オブジェクトたちに尋ねるという彼らとの対話の妙をぜひお試しあれかし

680 :デフォルトの名無しさん:2017/06/02(金) 12:43:16.45 ID:ybQLwqcw
>>678
> オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化

出来合いの(組み込みの)機能といっても、元は自作なんですよ(少なくともSmalltalkにおいては)
それらを簡単に実装できるという精神はHaskell、ひいてはFPに通じるところはあると思いますよ

それにHaskellにしてもパターンマッチや型クラスを含む型システムなどの便利な組み込みの機能の助けなしに、あるいは
リストなどのモナドの拡充なしに自作のしやすさの加速ができるわけでもないような気がしますが…違いますかね

681 :デフォルトの名無しさん:2017/06/02(金) 12:44:30.15 ID:AZK4Ab0s
>>677
オブジェクト指向は、複雑さ、巨大さとどう戦うかというのが進化の方向
HaskellやLispでデカくて複雑なプログラム書いてみたら、オブジェクト指向にも有用な部分があることを理解できるんじゃない?
ちょっとしたコードの書きやすさだけで言語の良し悪しは決まらないよ

682 :デフォルトの名無しさん:2017/06/02(金) 13:19:41.98 ID:E2RwPTWY
Objective-Cにも動的にクラスに「おまえなにできるの?」って聞くメッセージあるし
基本的にあの辺りはインターネットみたいな動作しっぱなしの世界で
クラスってノードを動作中に抜き差しするみたいな感覚を指向してるからなぁ。

683 :デフォルトの名無しさん:2017/06/02(金) 13:25:35.15 ID:4h5vYSNt
インタフェース以外の継承はすべて糞

684 :デフォルトの名無しさん:2017/06/02(金) 13:27:17.37 ID:PwRFjZu6
>>679
その都度オブジェクトたちに尋ねるのが、まさにsmalltalkがオブジェクト指向の最たるものの所以で、当時も今もそこについては変わらないんですけどね。
さすがにgnu-smalltalkでは一覧性に難ありな所が^^;

逆です。
その便利な機能のみで、入出力とかはともかく、自分がこう動いて欲しいと望む機能を実現できる。
そこに関してsmalltalkとFPに通じる所があるのも同意します。
ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。

smalltalkって制御構造もメッセージで実現してるけど、Haskellと同じで構造化プログラミングを模倣してるだけで、やや普通のオブジェクト指向言語より構造化プログラミングから逸脱してる気もしますし、確かに生産性は高いんですけど。

ただ、既存の関数やメソッドを一切使わず新しい機能を実現する手間は、その基本的な便利機能の充実度から、Haskellのが生産性は高いかと。
探すより作った方が早い場面もありますし。
(いあ、smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが)

685 :デフォルトの名無しさん:2017/06/02(金) 13:33:45.72 ID:PwRFjZu6
>>681
昔はGUI部分も同じ言語で書いてたからオブジェクト指向が有用だったですが、今はGUI部分はHTMLなりXAMLで書くことも増えて来ましたし、複雑な部分はDSLに任せて分担作業が、複雑巨大なプログラムに対する解の様に思います。

686 :デフォルトの名無しさん:2017/06/02(金) 13:46:34.00 ID:Uh1XLH/T
遅延結合って、実行時に型を調べて処理を分岐してるだけでしょ?

687 :デフォルトの名無しさん:2017/06/02(金) 13:57:11.97 ID:ybQLwqcw
>>684
> さすがにgnu-smalltalkでは一覧性に難ありな所が^^;
> ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。

具体的にはどういったところがでしょうか? 後学のため教えていたければ幸いです

> smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが

SmalltalkがOSモドキと忌み嫌われつつもイメージベースで居続けるのはこの利便性を捨てないためです
ユーザー定義のものも組み込みのものも区別せずにオブジェクトストアに保持し、OODBのように探せます

688 :デフォルトの名無しさん:2017/06/02(金) 14:05:56.39 ID:ybQLwqcw
>>686
実行時についてはそうなのですが、それを設計や運用時にも徹底する(それをサポートできるシステムであること)がミソです
決定をできるだけ先送りにして固定化しない、ぎりぎり直前でも(場合によっては事後でも)差し替え可能に保ちます
基本的な考え方はこちらに書かれていますのでよかったら読んでみてください

「ソフトウェア工学」は矛盾語法か? - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html

アラン・ケイもよく言っていますが、これができるのはおそらくLISPとSmalltalkくらいかと

689 :デフォルトの名無しさん:2017/06/02(金) 15:12:57.10 ID:PwRFjZu6
>>687
あれ。
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点だけど、総合点で上回る的な。
でも規模が大きくなると型付言語が欲しくなる。。。

690 :デフォルトの名無しさん:2017/06/02(金) 17:01:43.90 ID:ybQLwqcw
>>689
> シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、
> Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。

つまりHaskellでは組み込みの関数をいっさい知らなくとも(使わなくても)ログの整形作業が自作できるのですか?
それは驚きですね(反語的に)

691 :デフォルトの名無しさん:2017/06/02(金) 17:24:22.28 ID:PwRFjZu6
出来ますね。
結局ライブラリ使った方が早いんですが、学習しながら作ると言う意味では即戦力です。

だからなんだと言われればそれまでですが、GUIとかのライブラリがポトペタで作れたりしないので開発環境としてはまだまだですが、言語としての学習コストは低いと思ってます。

692 :デフォルトの名無しさん:2017/06/02(金) 17:35:52.70 ID:ybQLwqcw
>>691
そんなことが可能な言語がこの世に存在するとはにわかには信じられません
実際に動作するコードを見せてもらうことは出来ますか?

693 :デフォルトの名無しさん:2017/06/02(金) 17:38:49.65 ID:PwRFjZu6
あ、さすがに入出力関数は使いますよ?
でも、その中間の整形処理は一切組み込み関数知らなくても作れますし、その行為自体もそんなに手間じゃ無いです。
Cとかでもある意味整形処理は全部自作出来るわけですが、手間が全然違います。

smalltalkもそう言う意味では少ない知識で自前で作れると思いますが、ロジック部分に関してだけは、Haskellのがより少ない知識で済んでると思います。
GUIまで含めるとライブラリの塊と言うかライブラリそのものなsmalltalkのが生産性は高いんですが。。。

それこそsmalltalkそのものがOSとして普及しないとあんまり意味がないと言うか。。。

694 :デフォルトの名無しさん:2017/06/02(金) 17:44:01.62 ID:PwRFjZu6
>>692
もう出勤1時間前なので流石に今日は作れませんが、何かコードを提示して、組み込み関数を自作して行きましょうか。

上でも書いたですが、制御構造と最低限の入出力関数があれば作れはします。
手間の問題というだけです。

695 :デフォルトの名無しさん:2017/06/02(金) 18:57:35.54 ID:ybQLwqcw
>>694
> 今日は作れませんが、何かコードを提示して、組み込み関数を自作して行きましょうか。

おもしろそうですねぜひお願いします


> それこそsmalltalkそのものがOSとして普及しないとあんまり意味がないと言うか。。。

Dockerとかありますし、ホストOS内でOSモドキを動かすことにマシンパワーや心理的障壁は下がってきていると思いますので
「意味がない」と言うことはないと思いますよ

696 :デフォルトの名無しさん:2017/06/03(土) 02:39:21.79 ID:uXpVhTjv
中規模以上の範囲におけるDRY原則を
実現するための手段が
オブジェクト指向じゃないの?
そういう意味ではオブジェクト指向が
なくてもプログラミング出来る。
しかし重複部分を無くすには
オブジェクト指向しかないでしょ?

697 :デフォルトの名無しさん:2017/06/03(土) 15:57:20.13 ID:59j26kfv
>>695
たしかに、昔に比べれば仮想化が当たり前になりましたしそうかも知れませんね。
急ごしらえですが、昼間寝てしまったので3時から急ごしらえで作りました。
使い勝手悪いので、行番号振ったりと改良の余地ありです。

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の4つということになりますね。

698 :デフォルトの名無しさん:2017/06/03(土) 16:19:39.76 ID:59j26kfv
まずunlines

unlines [] = []
unlines (xs:xss) = xs ++ "\n" ++ unlines xss

ちなみに、++も自作出来ます。
(全ての中沖演算子はカッコで囲めば2引数の関数になります)

(++) xs [] = xs
(++) [] ys = ys
(++) (x:xs) ys = x:(++) xs ys

699 :デフォルトの名無しさん:2017/06/03(土) 16:42:14.38 ID:59j26kfv
次にfilter

filter _ [] = []
filter f (x:xs) | f x == True = x:filter f xs
filter f (x:xs) | f x == False = filter f xs

700 :デフォルトの名無しさん:2017/06/03(土) 17:03:05.77 ID:59j26kfv
isInfixOf

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

701 :デフォルトの名無しさん:2017/06/03(土) 19:06:03.31 ID:59j26kfv
最後にlines
変なところでハマってました・・・。

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

702 :デフォルトの名無しさん:2017/06/03(土) 19:54:54.78 ID:rGTJ2+S3
そういうのはブログでやっていただいて・・・

703 :デフォルトの名無しさん:2017/06/03(土) 21:44:39.04 ID:3br47TQ3
たぶん2chしか書くところないんだよ
かわいそうに

704 :デフォルトの名無しさん:2017/06/03(土) 21:46:14.14 ID:ZuJ0I9j5
もともと糞スレだし

193 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)