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

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

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

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

>>132
うるせー、ハゲ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sql

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

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

**デフォルトの名無しさん** · 2017/04/13(木) 11:36:09.37

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

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

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/04/13(木) 22:59:09.23

キリッ

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

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

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

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

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

**145** · 2017/04/14(金) 01:15:51.93

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

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

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

>>145
Java関係ないやん

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

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

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

**148** · 2017/04/14(金) 01:36:57.02

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

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

もう寝るか

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

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

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

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

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

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

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

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

>>150
はい？

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

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

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

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

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

Cobolですら現役なのに

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

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

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

**デフォルトの名無しさん** · 2017/04/15(土) 00:03:32.65

その通りやで

**デフォルトの名無しさん** · 2017/04/15(土) 00:06:46.85

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

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

されねーしいらねーし

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

javaスレでどうぞ

**デフォルトの名無しさん** · 2017/04/15(土) 00:28:17.04

じゃあ何の話するの？

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

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

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

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

**デフォルトの名無しさん** · 2017/04/15(土) 09:43:01.13

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

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

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

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

**166** · 2017/04/16(日) 02:23:40.59

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/04/16(日) 09:40:21.87

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

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

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

Rubyは俺が知らないw

**デフォルトの名無しさん** · 2017/04/16(日) 09:44:29.62

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/04/16(日) 13:37:47.43

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

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

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

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

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

**デフォルトの名無しさん** · 2017/04/17(月) 09:46:57.33

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

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

>>178
はい？

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/04/17(月) 21:56:46.03

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/04/17(月) 22:26:26.94

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

恣意的な

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

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

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

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

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

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

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

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

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

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

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

複数性が重要事項

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

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

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

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

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

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

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

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

pコードみたいだな

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

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

**デフォルトの名無しさん** · 2017/04/19(水) 13:42:18.93

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>220
それもそうだな

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

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

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

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

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

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

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

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

>>224
ほんとこれ

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

**デフォルトの名無しさん** · 2017/04/19(水) 20:00:55.07

>>225
はい

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

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

**デフォルトの名無しさん** · 2017/04/19(水) 20:02:59.08

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

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

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

**デフォルトの名無しさん** · 2017/04/19(水) 20:07:46.83

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

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

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

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

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