オブジェクト指向システムの設計 172 [無断転載禁止]©2ch.net

uy ◆e6.oHu1j.o · 2016/07/09(土) 00:35:13.95

前スレ
オブジェクト指向システムの設計 171 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1465636703/

**デフォルトの名無しさん** · 2017/01/08(日) 23:40:45.17

>>256
そのうちわかるよ

**デフォルトの名無しさん** · 2017/01/08(日) 23:49:40.92

でたｗ
「そのうち」としか答えない相手から聞き出せることはもう無い

**デフォルトの名無しさん** · 2017/01/08(日) 23:58:45.01

>>254
要するに編集方針の違いでしかないんだよ。
出来るやつが書けばどれでもどうとでもなる。
それだけ。
それよりOAOO/DRY/メトリックス(トポロジー)の方が重要。

**デフォルトの名無しさん** · 2017/01/09(月) 00:35:10.65

ソースのどこに記述するか?って方式の話でしかないよね
ボタン1を押したときの処理Aはオブジェクト指向で記述しようがそれ以外で記述しようが
ソースのどこかに記述しなければならない
オブジェクト指向ってのはつまるところその様式美

別にどこだっていいじゃん( ´∀｀)ｂ

**デフォルトの名無しさん** · 2017/01/09(月) 01:00:59.79

そしてウンポコPのペチプァみたいなゴミ屑コードができあがる

**デフォルトの名無しさん** · 2017/01/09(月) 07:16:32.07

そのボタン1は、UIコントロールの基底クラスを継承するというOOPで作られてるとは思うけど
まぁだからといって使う側がOOPに従わなきゃならん、ということにはならないな

ボタン1を使いながら「OOPなんて不要！」と言ってるとしたらアホだとは思うが

**デフォルトの名無しさん** · 2017/01/09(月) 07:18:15.57

>>262
話の主旨もわからず回答とかおめでてーな

**デフォルトの名無しさん** · 2017/01/09(月) 10:27:05.05

イベントハンドラの引数に押されたボタンのid渡すコード見るたびに
せっかくのオブジェクト指向が台無しになってる感はある。

**デフォルトの名無しさん** · 2017/01/10(火) 22:51:34.90

クソコードハラスメントって概念を提唱したい
書いた本人が意図する、しないにかかわらず、相手が不快に思い、
相手が自身の尊厳を傷つけられたと感じるようなクソコードを指します。

糞レベル1. 汚いコードだなぁと思う
糞レベル2. 汚すぎて読むのためらう
糞レベル3. どうしたらこうなっちゃうのか理解不能
糞レベル4. なぜこれを人に見せたのか理解不能

**デフォルトの名無しさん** · 2017/01/11(水) 00:22:47.67

大概書いた奴は既に現場にいないという現実

某糞PHPの糞保守案件でガチで撲殺してやりたいコードあったわ

**デフォルトの名無しさん** · 2017/01/11(水) 00:55:08.27

自社で保守する仕事なら綺麗に書くけど
同業他社が保守するなら難解な方がいいだろ
足を引っ張って競争が優位になる

**デフォルトの名無しさん** · 2017/01/11(水) 00:58:40.69

無駄

**デフォルトの名無しさん** · 2017/01/11(水) 00:58:42.43

>>267
こんなんだから凋落してくんだよジャップランド土人が

**デフォルトの名無しさん** · 2017/01/11(水) 01:03:37.68

アベノミクスで不景気だしどこも余裕がない
毎日残業で安月給じゃそりゃ人格も歪んでくる

**デフォルトの名無しさん** · 2017/01/11(水) 01:06:16.95

>>265
その全てをパスしているが動かないコードと
その全てを満たしているが動くコードの
どちらを持っていくかと言われたら迷わず糞を持っていく俺

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

>>271
動くなんて大前提だよ
そんなんだから脳みそまで糞まみれなんだよボケナス
殺すぞ

**デフォルトの名無しさん** · 2017/01/11(水) 06:50:15.75

>>272
動いた上でさらに付加する価値だろ?
そんなの省かれるに決まってるだろ
いい加減テメェのこだわりは重要じゃねぇって気付けよ

**デフォルトの名無しさん** · 2017/01/11(水) 12:29:20.79

結論が出た様です
>>265のセンスのない造語の使用は却下されました
妥当な結果でしょう

**デフォルトの名無しさん** · 2017/01/11(水) 22:20:40.95

仕様が無いのになぜ動いていると言えるのか。

**デフォルトの名無しさん** · 2017/01/11(水) 22:53:40.84

動いてるとも動いてないとも言えない
これが波動関数ってやつさ

**デフォルトの名無しさん** · 2017/01/11(水) 23:44:57.82

>>275
仕様がない＝動作が正＝動いている

**デフォルトの名無しさん** · 2017/01/11(水) 23:53:04.21

仕様がないつまり未定義
つまり何が起こってもおかしくない
パルプンテ状態

**デフォルトの名無しさん** · 2017/01/12(木) 08:29:14.43

Cの悪口はやめろ

**デフォルトの名無しさん** · 2017/01/14(土) 20:38:16.71

初期化以降はリードオンリーとするフィールドint barがある場合
class Foo {
private int bar;
public Foo(int bar) {this.bar = bar;}
public int getBar() {return bar;} // ゲッターだけ公開
}
↑こうするより↓こうしたほうが色々気持ちよくない？
class Foo {
public final int bar; // C#ではfinalのかわりにreadonly
public Foo(int bar) {this.bar = bar;}
}
どうよ？

**デフォルトの名無しさん** · 2017/01/14(土) 21:48:54.83

>>280
C#ならプロパティ使えばよくね

**デフォルトの名無しさん** · 2017/01/14(土) 21:56:28.41

>>281
Java脳だから仕方ない

**デフォルトの名無しさん** · 2017/01/14(土) 23:11:55.85

C#は、自動プロパティの初期化もできるようになったしな

**デフォルトの名無しさん** · 2017/01/15(日) 09:41:20.06

OOPでフィールドを丸出しなんてはしたないことはやめてください

**デフォルトの名無しさん** · 2017/01/15(日) 19:09:57.72

>>284
それに対する俺の考えはこう
・あるものが不変で良いなら不変にしておきたい
・不変であるのならメソッドを経由しなくていい
・フィールドをpublicにしておける言語がある理由もそこらへんじゃないのかなっ
どう？
「OOPで～」に対する返事にはなってないかもしれないけど

**デフォルトの名無しさん** · 2017/01/15(日) 19:25:01.82

フィールドは実装
実装を晒しては行けない

**デフォルトの名無しさん** · 2017/01/15(日) 19:43:31.26

オブジェクト指向的にはプロパティへのアクセスはメッセージに限定してカプセル化としたいんじゃないかなぁ?
って思う

**285** · 2017/01/15(日) 20:03:27.72

元の主張はいったん置いとくけど

>>286 >>287
そういうOOPLがあったらいいのにね（あるかどうかは知らない）
それはそれでスッキリすると思うよ

あとクラス図なんかにフィールド含まれてるのすら嫌だもん
>>286的理由で
インタフェースで考えていたいレベルに実装が飛び出てるのが嫌だしダメだと思う

**デフォルトの名無しさん** · 2017/01/15(日) 20:05:23.89

そういうOOPLってのは
フィールドをpublicに出来ない言語って意味ね

**デフォルトの名無しさん** · 2017/01/15(日) 23:28:22.35

ま、はしかみたいなものだね
OOの美学みたいな考えがあるんだろうけど
よくよく考えると大した概念ではないし、本質的でもない
多くのOOPはマルチメソッドをサポートしていないので
二つのオブジェクトに跨る処理をどちらに書こうかという
問題にぶち当たるし、得てしてそういった複数のオブジェクトに跨がる処理が
そのプログラムの本質的な部分であったりもするからね
プログラムの簡単な部分に関しては簡単に書ける、それがOOP

**デフォルトの名無しさん** · 2017/01/15(日) 23:55:46.52

OOはどちらかといえばデータ構造に基づいた設計手法で
(あ、クラスはデータじゃなくて機能って言う人もいるだろうが
データに対する機能を提供している側面があるので・・)
空間に基づいた設計手法といえるが
当然、時間に基づいた考え方というのもあり得て
プログラムの本質が手続きであり、命令を上から順番に実行していくものだとするなら
こちらのほうが本題かもしれなく、少なくとも何がどの順で実行されるか
良くわからないという事態だけは避けなければならない
あまり自律的なオブジェクトを設計してはダメってこと
AがBのメソッドを呼んで、その中で今度はBがAのメソッドを呼び出す・・・
ということは避けなければならない
なぜならAがBのメソッドを呼び出したとき、Aは処理の途中であり
その状態でBがAのメソッドを呼び出すのは危険だから
デッドロックの危険性もある
オブジェクト同士がメッセージをパッシングし合い、まるで生態系のように振る舞い
結果として何らかの機能が提供されるというのは、機能の観点からは遠回りであるし
何がどの順で実行されるかよくわからないという意味で、手続き的には厄介だ
俺たちは何かのシミュレーションがしたいというわけではない
AとBをコミュニケートされるなら、それらの親にあたる部分が仲介すればよく
AとBが直接コミュニケートする必要はない
そうすれば手順が明確になる
オブジェクトとは良きパーツであるべき

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

private Integer id;
private String domain;

String getAccountId() {
return domain + "-" + id.toString() + ;
}

こんな感じで、ゲッタの方が処理挟まないといけんくなったとき、ラクダからちゃう？
でもやっぱaccountId定義してコンストラクタ初期化すれば
やっぱフィールドおっ広げいいかとも思っちゃったり

**デフォルトの名無しさん** · 2017/01/16(月) 06:36:24.60

リフレクションでめんどくさいからやめろよ

**デフォルトの名無しさん** · 2017/01/16(月) 10:25:44.18

>>292
それはじめると君の同僚たちもそれに倣って、
結果、画面にもSQLにも業務ロジックにも、至る所に文字列操作が書かれるぞ
連結してaccountId作ったり、accountIdを文字数や正規表現でidとdomainにバラしたり…

**デフォルトの名無しさん** · 2017/01/16(月) 23:15:52.19

class User {
private Integer id;
private String domain;

String getAccountId() {
return domain + "-" + id.toString() + ;
}
}

ならええやろ
user.getAccountId()や

至る所で
String aid = user.getDomain() + "-" + user.getId();
こんなんされるよりまし

**デフォルトの名無しさん** · 2017/01/16(月) 23:43:04.52

それだと至る所でハイフンでsplitされるって話だろ
AccountId値型を作ろう

**デフォルトの名無しさん** · 2017/03/25(土) 12:41:38.33

instanceおじさんをレイオフする会を発足します

**デフォルトの名無しさん** · 2017/03/26(日) 09:22:55.90

本来であればフィールドメンバと引数とわずかばかりのシステムメソッドで処理を完結するのがベストなのだが、
それしようとすると、やりたいことをやるために必要な情報がなかったりして
親の親から引数を渡し直さないとけなくなったりしてそうこうしてるうちに
結局グローバル変数やシングルトン(instance)で便利になったと喜んでしまう性。

**デフォルトの名無しさん** · 2017/03/26(日) 22:59:55.37

>>295
現時点でCallerには「domain-id」の文字列以外必要ないなら、それでOK
Callerもid or domainが単独で必要ならgetIdやgetDomainもつける

IDだけじゃなくて、たとえばなんかのログインフォームのようにメールアドレスもサポートするならクラス側で承ける
文字列返すかAcccontDataクラスでも作るかは
idの形式があと3つ4つあるか（ついったと顔ブックとなんちゃらinアカでもログインOKみたいな、ならクラス）
or メルアドのみで数年やれるか（なら文字列でサクっと実装しちまえよ）による

**デフォルトの名無しさん** · 2017/04/20(木) 23:17:36.80

ワインと豆腐には旅をさせちゃあいけない
という山岡さんの名言がある

俺は変数にも旅はさせてはいけないと思う
つまり、変数はprivateにのみしておいて
それを外に参照させたり渡したりしないうちは安泰だということ

**デフォルトの名無しさん** · 2017/04/21(金) 03:45:03.38

漫画を引用する様な見識の狭い奴の言う事を誰が本気で聞くのか
語りたい事があるなら自分自身の言葉で語れ

**デフォルトの名無しさん** · 2017/04/21(金) 12:33:54.90

旅をするのは変数ではなく値なんだけどね

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

グロバール変数やめました
シングルトンもやめました
結果、
オブジェクトをたらい回しにしまくりんぐ地獄

**デフォルトの名無しさん** · 2017/04/23(日) 15:03:38.82

郵便物が来たってメモはたらい回しでいいけど、
郵便物自体はたらい回しするなよ。

**デフォルトの名無しさん** · 2017/04/23(日) 15:28:16.71

それは郵便物オブジェクトが人間オブジェクトにメッセージパッシングして言ってんの？

**デフォルトの名無しさん** · 2017/04/23(日) 15:45:39.68

郵便物オブジェクトは何もしないだろ。
メッセージをパッシングしているのはメッセンジャーさ。

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

メッセンジャーヴォーイズはどこで何をしてるんだい？？

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

staticおじさんは今日も元気でした

**デフォルトの名無しさん** · 2017/04/23(日) 22:31:23.91

>>308
言葉に気をつけろよ
キャットドア問題の前にお前らはボロ雑巾のように敗れ去っているのだから

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

勝ち負けだったのか

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

>>310
負けは認めるんだな

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

ごめんやけど最近来たから勝負してたところを見たことない
どんな勝負だったの？

**デフォルトの名無しさん** · 2017/04/24(月) 00:08:36.40

あとキャットドアって初めて聞いたんだけど何なの？

**デフォルトの名無しさん** · 2017/04/24(月) 00:13:48.70

>>キャットドア問題
ググってもAmazonしか出てこない、、、

**デフォルトの名無しさん** · 2017/04/24(月) 00:51:34.45

google「オブジェクト指向　キャットドア問題」
で出るな

**デフォルトの名無しさん** · 2017/04/24(月) 01:00:29.18

>>315
まじか！
ありがとう、見てみるよ

**デフォルトの名無しさん** · 2017/04/24(月) 01:02:48.58

なんか別のスレがヒットするだけなんだけどあってる？
http://itest.2ch.net/test/read.cgi/tech/1491118238/

**デフォルトの名無しさん** · 2017/04/24(月) 06:42:37.83

キャットドア問題って何だよ
博識な俺様でも知らんぞ

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

それを流行らせようとして必死なやつをどっかのスレで見たわ
放置推奨

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

なんだ
騒ぎ立ててるヤツが居るだけなのね

なんかおもしろい議論があるのかと思って期待してたのにな

**デフォルトの名無しさん** · 2017/04/24(月) 21:31:35.57

結局、キャットドア問題解決できなかったしね

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

>>315
オブジェクト指向 "キャットドア問題"
9 件（0.37 秒）

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

キャットドア問題が何を問題にしているのかわからない
合力できるようにDoorOpenerCompositionを定義すれば済む話では？

(new Cat(weight: 5)).can_open(new Door(weight: 4, knob: true)) //=> false
(new Human(weight: 15)).can_open(new Door(weight: 14, knob: true) //=>true
(new Cat(weight: 5)).can_open(new Door(weight: 4, knob: false)) //=> true
(new Cat(weight: 5)).can_open(new Door(weight: 10, knob: false)) //=> false
(new Cat(weight: 4) + new Cat(weight: 3) + new Cat(weight: 5)).can_open(new Door(weight: 10, knob: false)) //=> true

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

staticおじさんは今日も大勝利

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

結局どんな勝負なの？

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

>>325
結局、キャットドア問題解決できなかったしね

あ · 2017/04/25(火) 23:25:27.84

キャットドアとやらが拠り所なのか…

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

if cat door is open
human begining become
and we will we will goto heaven

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

ごめん、それでは理解できない
どんな勝負だったの？
勝利条件やルールは何だったの？

あ · 2017/04/26(水) 00:00:54.76

何かの引用のもじりなんだろうか？
ひどい英語に見えるけどなんか意味あるのかな…

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

>>329
逃げるのか？

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

ネコ用のドアって蚊やハエが入って来ないの？

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

>>331
や、だから俺はそもそも勝負に参加してないっての
参加するにしても勝利条件とルールを聞いても誰も教えてくれないから参戦もできない

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

>>333
マヌケなヤローだ

**デフォルトの名無しさん** · 2017/04/26(水) 07:00:16.63

ああ
これは会話させてくれないやつだ

放置推奨と言われた意味がやっとわかった

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

>>335
いいや、本スレに行って参戦宣言でもすれば即座に着火するよ
みんな内心納得してないからね

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

クラス階層をどう作るか、メソッドをどのオブジェクトに持たせるかっていう、大抵は主目的にならない部分の問題を、
現実世界の物理的な制約、言語学や分類学の観点から「～であるべき」と主張しあうおバカな問題だよ＞キャットドア問題
たまに出現してスレを白けさせる美少女クラス云々と同類。

プログラミングを知らなくても身近なものを抽象化して語ることは誰でもできるから、無駄にレスが稼げる

**デフォルトの名無しさん** · 2017/04/28(金) 12:21:14.12

それは抽象化ではないとだけ言っておこう

**デフォルトの名無しさん** · 2017/04/28(金) 22:22:35.36

>>337
おバカな問題だということが分からないやつがたくさんいるから
似非開発者をフィルタリングするのに便利だよ

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

頭が悪いという事実以外にどこに問題があるのか

**デフォルトの名無しさん** · 2017/04/29(土) 01:10:48.87

まあな、お前らほど優秀な奴らがあの場にいたらキャットドア問題など発生すらしなかったんだろうなｗ

**デフォルトの名無しさん** · 2017/04/29(土) 03:01:54.61

どんなに優秀なやつが居ても無理
自分の考えることが正解で他はダメみたいな考えしてるやつらの口論に出口はない

**デフォルトの名無しさん** · 2017/04/29(土) 14:57:30.88

>>323
俺はこんなコード書きたくないなあ

**デフォルトの名無しさん** · 2017/04/29(土) 18:07:18.04

>>343
お前が書かなくても>>323が書いてお前に保守させるから問題ない

**デフォルトの名無しさん** · 2017/04/29(土) 18:32:37.57

>>344
> お前に保守させるから

無理だろｗ
どうやって、やらせるんだよ。
お前に、他人に何かをやらせる力なんてないだろｗ

**デフォルトの名無しさん** · 2017/04/29(土) 22:20:18.73

>>337
わかるわかる
美少女クラスがどうとかウンコがどうとか
そーいうので必死でレス稼いでる子がいるよな
自転車置き場議論の一端だよな
これならレスできる！って連中が集っちゃう

**デフォルトの名無しさん** · 2017/05/01(月) 21:31:28.52

OOの技術って何って言われたら
整理整頓術、としか言いようがない罠
とりわけコードに対して、オブジェクト(クラス)にぶら下げとけば良いんじゃね？っていう
多態だ継承だっつっても、コードをオブジェクト単位で整理したときに
ちゃんと動くようにするための仕組みでしかないよ
それなのに犬は哺乳類で猫はニャーとか、最近はこういうこと言う人居なくなったけど
かつて本当にバカげたことを言っていたよね
仕事をするうえで整理整頓は重要だけど、作業性の問題であってサイエンスでは無いしな
いやね、まじめな話、作業性さえよければ何だってかまわないでしょ、マジで
だから結局、作業性の問題なんだよ、これは

**デフォルトの名無しさん** · 2017/05/01(月) 21:37:55.53

作業性？

**デフォルトの名無しさん** · 2017/05/01(月) 21:59:16.41

我々生まれもって木構造が好きだから
クラス階層というもんのドキュメント性も何か
心惹いてたんだろうねえ
継承がもたらすポリモの便利さにくわえてね

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

実際、作業性なんだよ
作業性が良いと、仕事が早く終わるし、ミスも減るんだよ
そのために整理する仕事があるんだよ
どこの工場でもやっていることだ
工場に限らず仕事は全てそうではあるがな

逆に物凄く崇高な理論や思想が何かあったとしても
余計に時間がかかってミスも増えるんなら糞くらえだろ
家に帰れなくだけ

**デフォルトの名無しさん** · 2017/05/01(月) 22:12:12.09

まぁソフトウェアの設計といえば
どれだけの時間で処理が完了するか見積もったり
メモリ使用量を算出したり
そういう楽しいのはあるけども
OOはそういうのじゃ無いよね
OO設計は完全に整理整頓術以外の何物でもない
とりわけ、コードを、どこに、書くか、という問題

**デフォルトの名無しさん** · 2017/05/01(月) 22:16:37.40

>>351
普通にメンテナンス性、可読性、
複雑なものをシンプルにする技術とか
言えばよくね？

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

で、それって何？って言われれば
まとめて整理整頓術としか言いようがない

**デフォルトの名無しさん** · 2017/05/01(月) 22:28:24.75

作業性って工場系の用語だと思うんけど定義を教えてくれ
作業のしやすさ＝作業性？
それとも作業効率を高める性質＝作業性？

自分の周りじゃあまり使われない言葉だけど便利そうだな

**デフォルトの名無しさん** · 2017/05/01(月) 22:51:43.47

> 整理整頓術

これも自分の周りじゃ使われない言葉だな

**デフォルトの名無しさん** · 2017/05/01(月) 22:57:39.04

大体において、作業がしやすければ、作業効率は高まるもんなんだよ
ここで、ごく一部の例外とか、そういうのはどうでもよい
基本的な原則といって良いだろう
だから両方の意味でつかわれるし、両方同時に言ってるし
付け加えれば品質の意味も含まれる
作業しやすいほうが品質が上がるのは当たり前だからな

ただ、作業性の意味が分からないってのはちょっとアレじゃねって
俺は思うが
別に工場用語でも何でもないし