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

**デフォルトの名無しさん** · 2017/09/26(火) 07:20:38.98

前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113
オブジェクト指向システムの設計 173
http://mevius.2ch.net/test/read.cgi/tech/1502182334/

類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714

**デフォルトの名無しさん** · 2017/10/17(火) 21:02:26.86

依存しあってんじゃねーよ

**デフォルトの名無しさん** · 2017/10/17(火) 21:19:29.37

>>638
senderを自分で生成する方法
http://bbs.wankuma.com/index.cgi?mode=al2&;namber=85371

**デフォルトの名無しさん** · 2017/10/17(火) 21:56:16.29

>>640
お、おう。。それもJittaさんか…

面白い捉え方だと思うけど
Object Orientedという言葉が出てきた歴史を調べれば
「目的指向」が誤訳なのが分かるよ
https://en.wikipedia.org/wiki/Object-oriented_programming#History

**デフォルトの名無しさん** · 2017/10/17(火) 22:34:25.19

>>641
Jittaさんが言ってることの方がガセネタですね
じゃあそれを根拠にわんくまに怒鳴り込もうと思います
ありがとうございます

あ · 2017/10/17(火) 22:41:00.56

まあ英語でObject orientedだと、大体は対象志向みたいな意味合いだけどな。
Objectって単語は、モノと言うよりも「認識できる何か」「動作や感情の対象」を指す。
動詞になると顕著で、「俺はこれに文句があるんだが」ぐらいキツい意味。
「I object to waiting」みたいな。

Ob + ject 。前に向かって投げたやつ。客観的に見ることができる物、が語源。
逆に、中に投げ入れるモノがinject。下に投げたものがsubject(自我、主観)。

あ · 2017/10/17(火) 22:46:44.09

>>636
単なる「モノ」はだいたいbody、matter、substance。
physical bodyとか使う。
天体の「体」もbody。heavenly-body。

**デフォルトの名無しさん** · 2017/10/17(火) 22:54:02.93

>>644
素晴らしい「モノ」
優れている「モノ」
高品質な「モノ」
高機能な「モノ」

のモノはどれになるの？

**デフォルトの名無しさん** · 2017/10/17(火) 22:55:17.94

食べモノ、飲みモノ
も追加しよう

**デフォルトの名無しさん** · 2017/10/17(火) 22:55:26.36

thingは？

**デフォルトの名無しさん** · 2017/10/17(火) 22:55:57.78

>>643
つまりJittaさんが大正解ってこと？

**デフォルトの名無しさん** · 2017/10/17(火) 22:59:32.89

目的を指向するってメチャクチャ当たり前だなw　殊更言葉にするのが恥ずかしいくらい

**デフォルトの名無しさん** · 2017/10/17(火) 23:08:10.96

責務指向でいいじゃん？

**デフォルトの名無しさん** · 2017/10/17(火) 23:20:41.75

役割って感じ？
objectではないけどしっくり来る

**デフォルトの名無しさん** · 2017/10/17(火) 23:31:17.25

責務駆動設計とか言うよね

**デフォルトの名無しさん** · 2017/10/17(火) 23:35:58.51

せやかて駆動設計

**デフォルトの名無しさん** · 2017/10/17(火) 23:36:27.01

責務はいつも一つ！

**デフォルトの名無しさん** · 2017/10/17(火) 23:38:24.92

>>654
いいね！

**デフォルトの名無しさん** · 2017/10/17(火) 23:47:01.89

Functional ProgrammingのFunctionにだって責務あるし
POAのProcessやDOAのDataにだって責務は有る

他と違って「オブジェクト」という抽象概念を中心に物事を考えるからオブジェクト指向という名前
んでオブジェクトってのは↓
a data structure that can contain functions as well as data, variables, and other data structures
https://www.merriam-webster.com/dictionary/object

**デフォルトの名無しさん** · 2017/10/17(火) 23:58:04.35

Object oriented languageは
・カプセル化、継承、多態性をサポートするもの
・JavaやC++、Rubyなど

Object based languageは
・継承・多態性をサポートしないもの
・VBなど

orientedはbasedと似たような意味で、basedよりも多くの条件を規定する。

Object based languageを「オブジェクトを基本にした言語」と解釈するならば
Object oriented languageは「オブジェクトを本位にした言語」と解釈するのが妥当な気がする。

「本位」は中心にして基本にするという意味なので「基本」を強めてる感じ。

**デフォルトの名無しさん** · 2017/10/17(火) 23:58:36.63

>>656
やっぱそうだよね、オブジェクトを中心にするっていうのがオブジェクト指向だよね

**デフォルトの名無しさん** · 2017/10/18(水) 00:03:46.63

>>657
オブジェクトじゃわからない
Objectはなんて訳すのが適切なのか

**デフォルトの名無しさん** · 2017/10/18(水) 00:22:48.20

>>659
>>641の歴史を見てほしい、翻訳してほしい、よろしくお願いします

**デフォルトの名無しさん** · 2017/10/18(水) 00:36:43.88

ピッタリの訳語がないから
新しく作るか (例経済)
既存の言葉に新しい意味を持たせるか (例自由)

ちなみに中国語訳では「対象」らしい

あ · 2017/10/18(水) 00:58:52.74

>>645
good one,
better one,
high-quality one,
とかでは？モノと言うよりは、何か指しとるでしょ、その言い回しで言うときには、モノは。

>>647
事象、作品、道具、衣服などなど、それだけでは存在に意味が存在しない類のやつ。転じて、流行りとか、大事な事を指したりする。

**デフォルトの名無しさん** · 2017/10/18(水) 07:54:38.23

抽象的な部分は合ってるな

**デフォルトの名無しさん** · 2017/10/18(水) 07:56:46.88

orientedも指向より主導の方がいいと何かの本で書いてたな

**デフォルトの名無しさん** · 2017/10/18(水) 08:07:11.64

主体とか本位とかでもいいかもね
役割主体、役割本位

**デフォルトの名無しさん** · 2017/10/18(水) 08:13:24.82

>>659
「モノ」「箱」「塊」とかなんでもいいような気がしてきた
どうせ実際に使う時は「社員」とか「敵機」とかになるんだし

**デフォルトの名無しさん** · 2017/10/18(水) 14:09:11.49

人間の方の理解のために「”もの“になにかやらせる」
「”もの“を複製して別な”もの“のパーツとして使う」
これわかりやすいっしょ？
どんどん再利用パーツ増えて複雑になってったらこうじゃないとキツイっしょ。
で提唱されたってのに、すぐにベテランプログラマーさんは
「この名前さあ、タイプすんのめんどくさいから「あ」「い」「う」でよくね？」と他人にわからない暗号にしたがったり
「オブジェクト指向ってさぁ、オブジェクト単位に分けるんっしょ？この再利用しない中身もさぁ
ぜんぶ用途別に名前つけてパーツに分類整理しなきゃ！」とかやりなさる…

あ · 2017/10/18(水) 19:20:47.11

そうなると、クラスって何だ、インスタンスって何だ、コピーなら、コピー元も何かの役割を果たしてたんだろ？みたいな明後日の事言われるからな。

プレスの金型と、それで作り出した製品くらいの言い方の方が伝わる。
たまに金型に便利な治具ついてることもあるし、付けることもできて、それはプレスせずに金型から直接使えますが、
その治具にメモとかつけると皆から見えたり、誰かに剥がされたりするので、必要がなければ製品に付けたほうがいいですよ、
何回プレスしたかのカウンタとかは治具につけたら良いですね。みたいに説明した事ある。

スーパークラスとかサブクラスも、同じように、互換品の金型と互換品とかそういう説明できるから、物理な型で説明すると割とわかってくれる。

**デフォルトの名無しさん** · 2017/10/18(水) 22:26:09.70

適切な訳語、的確なメタファって大事やね

あ · 2017/10/18(水) 23:14:36.30

プロトタイプベースな言語だと、コピーのメタファの方が的確になったり、まぁ難しいわ、もう自分が知ってる物を、1から人に教える順番を考えるのは。

**デフォルトの名無しさん** · 2017/10/19(木) 00:15:22.98

自分がちゃんと理解してないものは人に説明できないって言うしね

**デフォルトの名無しさん** · 2017/10/19(木) 07:18:30.10

ガウディ本読んでから議論して欲しいね。

あ · 2017/10/19(木) 08:25:03.58

>>671
わかるわ。耳が痛い。教育することになって逆に知る事も多かったしな。
若手の新アイディアは、素直に教えてもらってる。
たまに俺が相槌しか話してないうちに「出直します」って言うから、どうやらテディベアとしても活用されてる模様。

**デフォルトの名無しさん** · 2017/10/19(木) 08:44:29.39

>>673
気持ち悪い

**デフォルトの名無しさん** · 2017/10/19(木) 08:45:50.14

自分の行動を素直にと修飾するところが完全に淫乱テディベア

**デフォルトの名無しさん** · 2017/10/19(木) 20:46:11.30

オブジェクト指向を理解させたければ
まずはオブジェクトを理解させることからはじめないと

クラスやプロトタイプは二の次でいいし
責務や役割は別レイヤーの話

**デフォルトの名無しさん** · 2017/10/20(金) 06:47:53.32

DDDって結構やってるもん？

**デフォルトの名無しさん** · 2017/10/20(金) 07:15:39.98

ディスプレーディスパッチドライバ。

**デフォルトの名無しさん** · 2017/10/20(金) 07:46:42.44

>>677
IT後進国の日本ではまだほとんど導入されてないね
非正規化DB 、非レイヤー化、貧血ドメイン、トランザクションスクリプトが主流

**デフォルトの名無しさん** · 2017/10/20(金) 08:25:54.77

韓国に学べ！

**デフォルトの名無しさん** · 2017/10/20(金) 08:30:05.48

>>677
3Dゲームはよくやる

**デフォルトの名無しさん** · 2017/10/20(金) 08:43:33.27

>>677
結構やってるでしょ
エヴァンス本から何年経ったやら…

**デフォルトの名無しさん** · 2017/10/20(金) 08:54:44.62

>>679
>>682
完全に対立してるな。

個人的には比較的昔からある企業は前者で、若くて成功してる部類の企業は後者かな？と思うけど。

実際DDDやってるぜー、て現場はどういう特性なんだろ。

**デフォルトの名無しさん** · 2017/10/20(金) 18:29:33.31

要件定義や設計時にDDDの考え方を(一部)導入してるのと
実装含めて厳格にDDD導入してるのとで違うよね

前者は多いけど後者は少ない
>>679は実装者の視点
>>682は要件定義・設計者の視点
おそらく

**デフォルトの名無しさん** · 2017/10/20(金) 20:39:31.31

たとえば>>26をDDDでやるとどんな感じになるの？
DCIでやったときとの違いも知りたい

**デフォルトの名無しさん** · 2017/10/20(金) 22:19:22.96

>>685
まず本人を召還して質問攻めにする

**デフォルトの名無しさん** · 2017/10/21(土) 01:13:21.31

アンドロイドアプリ開発って稼げるんかな？

**デフォルトの名無しさん** · 2017/10/21(土) 01:50:48.55

レッドオーシャン

**デフォルトの名無しさん** · 2017/10/21(土) 11:03:31.78

>>687
業務アプリを受託で開発するのが主戦場
iOSと同時開発必須

自分で直接販売するのはバクチだね
アプリ数多いといってもニッチはまだまだ足りてない

2017/10/22(日) 16:21:52.81

>>592
別に複数あっていいと思うが
社員給与を振り込む
給与の分類か属性かで

2017/10/22(日) 19:45:01.88

>>592
給与は社員に与えられるものだから
「社員に対して」は要らなくね？

**デフォルトの名無しさん** · 2017/10/22(日) 20:06:35.35

役員やパート・アルバイト等、社員以外のケースがあるんじゃね？

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

>>592
お金を移動させる

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

>>592
目的語でひとくくりにするとわかりにくいけど
日本語では名詞が述語をどう修飾するかは格で区別されるから
格を考えればよいかと

1.「振り込む」が述語ならば振込先は口座なので「社員の口座に」としたほうが良いかと
振り込む(社員の口座に:与格, 給料を:対格)

2.「社員に」を使うなら述語は「支払う」かな
支払う(社員に:与格, 給料を:対格)

3. 対格しか使いたくないんですということならば「社員の」という属格で対格を修飾するしかないんじゃないかな
振り込む(社員の給料を:対格)

**デフォルトの名無しさん** · 2017/10/22(日) 22:33:46.62

文章だけで表現しなけりゃいいだろｗ

**デフォルトの名無しさん** · 2017/10/22(日) 22:52:37.75

すっごい不評な法令検索つくって賞もらっている大学教授
法令データベース「e-Gov法令検索」リニューアルにあたり、同法情報研究センターの協力教員である名古屋大学情報基盤センター（センター長：森健策）の外山勝彦（とやまかつひこ）

**デフォルトの名無しさん** · 2017/10/24(火) 06:59:53.59

DDDと言えば20項目の責務単位でドメインクラス作ったら一つのグラフ作るのに20個のクラスがデータベースに問い合わせちゃってパフォーマンスやばい

有識者のみなさんはどうやってるの?

**デフォルトの名無しさん** · 2017/10/24(火) 07:10:47.55

DDDならドメイン層とインフラ層のレイヤーは分けろ

つまりドメインのクラスが個々に
直接SQL文でDB叩いたりしない

**デフォルトの名無しさん** · 2017/10/24(火) 07:28:15.97

>>698
例えばドメインクラス「作業時間」にhogeプロジェクトの作業時間を問い合わせた時、作業時間クラスがDBクラス使って作業時間を教えてくれるんじゃないの?

この辺解らないとパフォーマンスの問題でアクティブレコードに走っちゃいそうです

**デフォルトの名無しさん** · 2017/10/24(火) 07:38:44.12

>>699
たとえばソシャゲみたいなWebアプリをイメージしてみよう
一個アイテムを見るたびにDBアクセスしてたら重いから
画面を遷移するときにまとめてローディングするよな？

だからそういう風にインフラ層で
ある程度まとめてデータ取ってきて
ドメイン層の内部ではDBに直接触らないようにする

**デフォルトの名無しさん** · 2017/10/24(火) 08:58:46.53

>>700
それはレイヤ分けるメリットでなくて
レイヤ分けるデメリットをカバーする方法じゃないの

**デフォルトの名無しさん** · 2017/10/24(火) 12:12:03.52

>>700
あらかじめオブジェクトにぶち込むのかな
油断するとメモリ食いそう

**デフォルトの名無しさん** · 2017/10/24(火) 12:12:39.91

>>697
集約の単位が間違ってんじゃないの

**デフォルトの名無しさん** · 2017/10/24(火) 12:15:40.46

>>703
昔は画面単位にデータ取ってたけどトランザクションスクリプトアンチパターンになるから作業時間とか予算とかドメインでクラス分けたんだ

それぞれのクラスがデータベースに問い合わせるからウッホという状態に

**デフォルトの名無しさん** · 2017/10/24(火) 17:47:57.40

>>697
基本は集約一つにリポジトリ一つ
レポーティング用途の場合はドメインモデルやリポジトリを経由せずに
DBレイヤーに直接問い合わせるのも有り

ドメインモデルを経由しなければ
ドメインロジックが分散する可能性があるのでトレードオフを判断したり
それを避ける工夫が必要だったりする

Patterns, Principles, and Practices of Domain-Driven Designって本で
一つの章使ってレポーティングの実装パターンを紹介してるので読むといいと思う

**デフォルトの名無しさん** · 2017/10/24(火) 19:37:04.66

ドメイン駆動とORMって相性悪くない？

class Foo : ValueObject<Foo> { ～ }
class Bar : ValueObject<Bar> { ～ }
class Baz : ValueObject<Baz> { ～ }

class Hoge : Entity<Hoge> {
private final Foo _foo;
private final Bar _bar;
public Hoge(Foo foo, Bar bar) {
Assert.notNull(foo);
Assert.notNull(bar);
_foo = foo;
_bar = bar;
}
public Baz queryBaz() {
// なんか計算する
return new Baz(...);
}
public Hoge doSomething() {
// なんか計算する
return new Hoge(..., _bar); // なんか計算した結果fooが変化する。_barはそのまま
}
}

ORMってこういうガチンコDDD的なオブジェクトってうまくマッピングしてくれないじゃん？
だからORM使おうとするとpublicプロパティに汚染されてゲロ吐きそうになる
かといってORMはDTOまでに留めてDTOとドメインオブジェクトのマッピングを手書きするってのはそれはそれでめんどくさい

**デフォルトの名無しさん** · 2017/10/24(火) 19:50:43.93

>>706
AutoMapper

**デフォルトの名無しさん** · 2017/10/24(火) 20:00:23.46

>>707
AutoMapperってやつそんな賢いの?

**デフォルトの名無しさん** · 2017/10/24(火) 20:44:30.93

逆にDDDこそORMだろ
集約をそのまま永続化したいんだから

**デフォルトの名無しさん** · 2017/10/24(火) 21:35:54.97

>>708
使わないなんて考えられない

**デフォルトの名無しさん** · 2017/10/24(火) 21:36:46.21

>>709
どうかな
さっきも書いたようにDDDに忠実にドメインモデルを構築するとpublicプロパティが無くなって完全コンストラクタでインスタンスを構築しなければならない
DTOのようにフラットな構造にならない点でもORMで扱いにくい

**デフォルトの名無しさん** · 2017/10/24(火) 21:46:26.94

そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ
RDBは個々のオブジェクトではなく集合としてのビジネスルールを表現するのに適している
単なるデータストアではない
1ヶ月の間に正当な休暇を間に挟まず3営業日連続で欠勤した従業員にはペナルティを与えるといった業務ルールがあったらSQLで解決するほうがスマート

**デフォルトの名無しさん** · 2017/10/24(火) 21:50:42.54

どのORM使ってるの？
いまどきORMのために可視性を変えたりしないでしょ

**デフォルトの名無しさん** · 2017/10/24(火) 21:58:23.29

>>712
> そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ

DDDだろうとトランザクションスクリプトだろうとDBの役割は変わらないよ
ドメインモデルから見てあたかも単なるオブジェクトの置き場であるかのように振る舞うっていうのは、
そう振る舞うように作ってるからそうなるのであって、DBから見たら、アプリがDDDで作られてるかどうかなんてわからない

**デフォルトの名無しさん** · 2017/10/24(火) 22:02:14.66

>>712
じつはそういう考え方もアリだと思う
SQLやPrologでビジネスルール書くのもアリ

でも現実的にはDDDの
インフラ層にDBを隔離するやり方が無難だと思う

SQLでビジネスロジックを表現すると
シンプルな例だと分かりやすく感じても
実務レベルの複雑なルールでは非常に難解になる

OOでチマチマ差分を書いていく方が分かりやすい
これはなんでOOが主流なのかの理由でもあると思う

**デフォルトの名無しさん** · 2017/10/24(火) 23:18:27.01

>>712

ひっかけっぽい例だな
SQLかじったレベルじゃそれは書けない

普通にアプリでやったほうが柔軟性高そうだ

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

>>712
RDBMS主体でやるプロジェクトもあるだろ
ただ古臭くて不便なことが多いからか
アプリケーション側でやるのがほとんど

技術者の数も違うからかな

**デフォルトの名無しさん** · 2017/10/25(水) 07:21:56.95

期待のデータベーススペシャリスト持ちが開発してくれたプログラム
1クラス1メソッドにSQLをぎっちり書いていてくれた
流石データベーススペシャリストだと思った

**デフォルトの名無しさん** · 2017/10/25(水) 14:49:56.93

そんなんアーキテクチャ検討時に認識合わせしとけよ
単なる指示ミス

**デフォルトの名無しさん** · 2017/10/25(水) 18:41:28.64

>>719
チームリーダーは電気寄りのC使い
JAVAの実装にはノータッチ

**デフォルトの名無しさん** · 2017/10/25(水) 19:15:55.71

データベーススペシャリストがSQLしか知らんのは仕方ない

ソフ開持ってなきゃね

**デフォルトの名無しさん** · 2017/10/25(水) 19:21:45.35

オブジェクト指向のスペシャリストとは言ってないからな

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

メンバー集める時はくだらん資格のことより影響を受けた本とか聞いた方がいい

**デフォルトの名無しさん** · 2017/10/25(水) 19:51:28.91

オブジェクトにメソッドでリクエスト飛ばすと答が返ってくるならそれはそれでいいような…

**デフォルトの名無しさん** · 2017/10/25(水) 22:27:46.82

>>719
>>718みたいな奴が指示する立場なわけないだろw

**デフォルトの名無しさん** · 2017/10/25(水) 22:52:11.24

DBスキルつけても負の遺産と有害な社内規約のせいで役に立たないことが多いね
データアクセス層でオブジェクトにマップしたらもう二度と中は見たくない

**デフォルトの名無しさん** · 2017/10/25(水) 23:16:26.90

>>720
javaはともかくJAVAって書かれると
あっ・・・（察し）ってなるから気をつけて

**デフォルトの名無しさん** · 2017/10/25(水) 23:17:51.80

J(AvA)し

**デフォルトの名無しさん** · 2017/10/26(木) 00:00:20.94

>>727
アスペすぎるだろ
お前が気をつけろ

**デフォルトの名無しさん** · 2017/10/26(木) 01:11:04.35

スクリプトの方はjava表記多いけど
Javaの方は書籍とかもJAVA表記多いよねぇ

**デフォルトの名無しさん** · 2017/10/26(木) 01:17:09.43

ネット校正員多いけど
そんな表記は本質に全然関係ない

**デフォルトの名無しさん** · 2017/10/26(木) 02:05:07.05

JAVAが得意とかJAVASCRIPT経験5年とか書いてるの見て
まともなコード書けるやつだと思えるの？

**デフォルトの名無しさん** · 2017/10/26(木) 03:24:25.76

そんなことで何か判断してる気になってるオマ、恥ずかしいぜｗ

**デフォルトの名無しさん** · 2017/10/26(木) 04:59:02.77

java - コマンド。
Java - 言語。
JAVA - 茶。

**デフォルトの名無しさん** · 2017/10/26(木) 07:20:00.13

>>723
VBの絵本でプログラムを覚えました
非常に解りやすく良書だと思います
御社のお役に立ちたいです

**デフォルトの名無しさん** · 2017/10/26(木) 07:44:35.72

>>735
不採用

**デフォルトの名無しさん** · 2017/10/26(木) 08:27:35.90

>>734
わろちんこ

**デフォルトの名無しさん** · 2017/10/26(木) 12:13:23.62

憂鬱なCプログラマのためのオブジェクト指向入門かなー