オブジェクト指向システムの設計 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/

**デフォルトの名無しさん** · 2016/12/31(土) 15:09:26.22

>>209
おまえもな

**デフォルトの名無しさん** · 2016/12/31(土) 16:41:13.08

>>210
消えろ
ぶっ飛ばされんうちにな

**デフォルトの名無しさん** · 2016/12/31(土) 17:32:21.84

>>211
おまえもな

**デフォルトの名無しさん** · 2016/12/31(土) 17:32:59.43

>>211
あんまり調子こいてると手続き型にするぞ？

**デフォルトの名無しさん** · 2016/12/31(土) 17:37:54.48

もういいから

**デフォルトの名無しさん** · 2016/12/31(土) 17:40:02.54

工数気にするのって完全受注型で自分とこで商品開発できないようなところだろうなと思うわ

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

採算度外視で開発とかないわ

**デフォルトの名無しさん** · 2017/01/06(金) 17:03:12.17

オブジェクト指向の良書教えて

**デフォルトの名無しさん** · 2017/01/06(金) 17:25:52.39

>>217
http://echo.2ch.net/test/read.cgi/tech/1467992113/

**デフォルトの名無しさん** · 2017/01/06(金) 20:45:05.38

ループかよ

**デフォルトの名無しさん** · 2017/01/07(土) 11:22:42.01

>>204
手続き型でもできる。
というよりオブジェクトみたいに状態に注目するより
メッセージやメソッド、関数に注目するほうが自然な場合もある。
まあオブジェクト脳だとそういった処理をまとめたクラスを作るんだろうけど。

**デフォルトの名無しさん** · 2017/01/07(土) 12:04:44.28

>>220
具体例は？

**デフォルトの名無しさん** · 2017/01/07(土) 13:39:47.70

　サ　ー　ビ　ス　ク　ラ　ス

**デフォルトの名無しさん** · 2017/01/07(土) 21:45:21.54

>>220
> 手続き型でもできる

それはとても興味深い指摘です。後学のため、
これぞ手続き型の（つまり「そこまでやったらもはやOOP」とは言わせない、そういった小細工のない）
コードで実演してみてもらうことはできますか？

**デフォルトの名無しさん** · 2017/01/07(土) 23:48:37.74

そもそもオブジェクト指向にメリットなんかないのにやり方がわからないとかさっさと廃業しろ

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

デストラクタは OOP でないと難しいね
え？ポインタの存在自体が邪道ですか？そうかもしれないですかね‥

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

デストラクタってOOP以前からあるしOOPと直結する関係性もない
それになぜいきなりポインタ？もはや何が言いたいのか判らない

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

そう難しく考える必要はなく物事をシンプルに考えていくと自然とOOPにたどり着くんだけどね
OOPに拒否感を持つ人はその当たり前の感覚を持っていないアスペなんじゃないかな
子供の頃いじめられたりしなかったか？

機械的な命令並べてgotoするより意味的な命令並べてifとかloopとか使ったほうが簡単だな
同じ処理をなんども書くより関数にしたほうが簡単だな
引数が多くて煩わしいから一緒に使う変数をまとめて構造体にしたほうが簡単だな
この構造体は特定の関数以外から変更されたらそれらの実行の前提条件が崩れるからそれら以外からメンバに触れないようにアクセス制御したほうが間違えなくていいな
それらの関数を構造体と同じ箇所で定義すれば管理しやすいな
メンバ変数みたいにドット演算子でそれらの関数にアクセスできれば楽だな
………

こういう感覚は別にOOPを知らなくてもコーディングを簡単に安全にしたいという欲求があれば自然とたどり着くものなんだけど
感覚がおかしいのかガチで気が付かなかったのか
たどり着けないかわいそうな子も世の中には少なからずいるんだね

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

なんていうかね
棍棒だと重いし動物殺しにくいけど木の棒の先っぽに鋭い石括りつけたら軽くてめっちゃ殺せるんだけどウホホwww
正直この程度の発想でしかないんだよ
OOPってそんなに高尚で難しいものじゃない
それをわざわざ難しい概念だと錯覚して悩むのは時間の無駄じゃないか？
OOPとはなにかOOPの存在意義はなんて哲学者みたいなことを考えてないでさ
自分の感覚に従ってOOPってよくわからんけど手続き型より楽だわウホホwwwって気楽にコーディングすればいいんだよ

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

なんで人格攻撃に移るの?
自分の中で辻褄が合ってないから反論できないのに他人を叩くことでそれを解消しようとするのは間違ってる
お前は技術者を廃業しろ

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

ワイ「関数型最強ウホホｗｗｗ」

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

勝ち負けだったのか