オブジェクト指向システムの設計 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(日) 10:35:35.87

> 物事をシンプルに考えていくと自然とOOPにたどり着く

逆だろうね
物事を自分のおつむの程度にしかとらえられない人間がようやくたどり着いたのが>>227が書てるOOPもどき
この程度の理解の人間がOOPを真に理解してそのメリットを引き出せているとはとうてい思えない

**デフォルトの名無しさん** · 2017/01/08(日) 10:35:39.50

>>229
残念ながらこれもOOPがらみでよく見られる光景
追い詰められてならまだしもわりと最初のほうからこれだもんね
さらにそれにしたってそれすらを長文でぐだぐだと…推して知るべし

**デフォルトの名無しさん** · 2017/01/08(日) 11:28:11.39

2chの長文すら読めないオジサンって、普段技術書読まないんですかあ？

**デフォルトの名無しさん** · 2017/01/08(日) 11:45:15.83

技術書ってクソばかりじゃないですか

**デフォルトの名無しさん** · 2017/01/08(日) 12:53:03.81

>>226
デストラクタはOOPと同時ですよ

**デフォルトの名無しさん** · 2017/01/08(日) 13:04:04.65

protectedっていつ使うんですかぁ？中途半端じゃないですかぁ？

**デフォルトの名無しさん** · 2017/01/08(日) 13:07:40.60

継承やUTで簡単に使えるようにするため
privateは全てprotectedにしろと言われたことあったわ

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

継承っていう仕組みがクソ。疎結合とはなんだったのかって気分にしてくれる。

**デフォルトの名無しさん** · 2017/01/08(日) 13:34:11.82

OOPのメリットとして吹聴される要素の8割はクソ。
カプセル化はクソ（めんどくさい）
継承はクソ（親子のねっとりしたつながりがキモイ）
多態は野ぐそ（多態のための汎化、インタフェース抽出とか勘違いも甚だしい。保守性に逆行している）
俺OOP使ってこんな曲芸できます案件多すぎクソ。

**デフォルトの名無しさん** · 2017/01/08(日) 13:38:11.45

葡萄に手が届かない狐さんのたわごと

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

>>239
車輪的再発明すきそう

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

OOPみたいな簡単な仕組みも理解できない人って可哀想
もっと体動かすだけとか根性あればなんとかなる仕事に転職しないの？

**デフォルトの名無しさん** · 2017/01/08(日) 14:17:09.32

OOPは本当に簡単で短絡的な思考のすえたどり着く結論だからね
オブジェクトに操作が内包されているというのは
まるで利権主義で、縦割り行政で、日本的といえる
自分の仕事しかしないし、利権はぜった他人に渡さない
利権という物質的なオブジェクトにすべてが紐づいていて整理されている

まぁ実用面では便利な部分もあるんだが
外でOOPサイコーとかいうと人格を疑われかねない
本音と建て前でこっそり使うものだ

**デフォルトの名無しさん** · 2017/01/08(日) 15:26:35.22

OOPを無くした人類はどこへ向かうのか

**236** · 2017/01/08(日) 15:47:12.81

オブジェクト指向を用いるメリット
｢ラクして、楽しく、良いもの｣を作れる

スッキリJavaより抜粋

**デフォルトの名無しさん** · 2017/01/08(日) 16:12:47.12

｢ラクして、楽しく、良いもの｣を作れる
オブジェクト指向登場後のソフトウェア業界は
さぞかし良い世界になったんだろなあ

**デフォルトの名無しさん** · 2017/01/08(日) 16:19:04.51

とてつもなく良い世界にはなってる。

**デフォルトの名無しさん** · 2017/01/08(日) 16:46:50.39

簡単になりすぎて捌ける規模が大きくなったから
逆に要求が膨れ上がって結局辛い世になってる気もするが
まあCOBOLとかやらされるよかマシかな

**デフォルトの名無しさん** · 2017/01/08(日) 16:51:03.49

オブジェクト志向言語使っててもアホが考えた社内規約とやらとヘボいフレームワークで全く楽にならねえw

**デフォルトの名無しさん** · 2017/01/08(日) 17:26:00.28

>>249
あーわかる
なぜか規約もフレームワークも手続型っぽいんだよな

**デフォルトの名無しさん** · 2017/01/08(日) 19:34:42.91

オブジェクト指向の利点って明確にならないね

**デフォルトの名無しさん** · 2017/01/08(日) 21:51:12.89

そういやこのスレって、どんな話題で始まったんだっけ？
「オブジェクト指向の利点を明確にする」
だったっけ？

**デフォルトの名無しさん** · 2017/01/08(日) 22:30:47.12

>>252
まずメリットが明確にならないとやる意味もわからなくてさ

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

>>251
俺も最近正直そう思うようになった

最初の頃：おぶじぇくとしこう？
途中：OOP！ポリモ！デザパタ本！OOSC本！
その後：関数型？関数と変数だったら変数散らかるんじゃないんけ！
そののち：意外と関数型記述性ある！不思議と短く書けるなんやこれ！
しばらくして：いや？非OOPでも意外と書けた！
　OOP-OOPLというより大事なんは単にモジュール性や！直交性や！
　徹底してインタフェースと実装のシンプルさを保つことや！
今：そんでOOPのメリットって何なんやろな？

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

そういう本質的に重要な事を記述しやすいってところだろ？

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

>>255
え?
全然意味わかんない

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

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