オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
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 Object oriented languageは
・カプセル化、継承、多態性をサポートするもの
・JavaやC++、Rubyなど
Object based languageは
・継承・多態性をサポートしないもの
・VBなど
orientedはbasedと似たような意味で、basedよりも多くの条件を規定する。
Object based languageを「オブジェクトを基本にした言語」と解釈するならば
Object oriented languageは「オブジェクトを本位にした言語」と解釈するのが妥当な気がする。
「本位」は中心にして基本にするという意味なので「基本」を強めてる感じ。 >>656
やっぱそうだよね、オブジェクトを中心にするっていうのがオブジェクト指向だよね >>657
オブジェクトじゃわからない
Objectはなんて訳すのが適切なのか >>659
>>641の歴史を見てほしい、翻訳してほしい、よろしくお願いします ピッタリの訳語がないから
新しく作るか (例 経済)
既存の言葉に新しい意味を持たせるか (例 自由)
ちなみに中国語訳では「対象」らしい >>645
good one,
better one,
high-quality one,
とかでは？モノと言うよりは、何か指しとるでしょ、その言い回しで言うときには、モノは。
>>647
事象、作品、道具、衣服などなど、それだけでは存在に意味が存在しない類のやつ。転じて、流行りとか、大事な事を指したりする。 orientedも指向より主導の方がいいと何かの本で書いてたな 主体とか本位とかでもいいかもね
役割主体、役割本位 >>659
「モノ」「箱」「塊」とかなんでもいいような気がしてきた
どうせ実際に使う時は「社員」とか「敵機」とかになるんだし 人間の方の理解のために「”もの“になにかやらせる」
「”もの“を複製して別な”もの“のパーツとして使う」
これわかりやすいっしょ？
どんどん再利用パーツ増えて複雑になってったらこうじゃないとキツイっしょ。
で提唱されたってのに、すぐにベテランプログラマーさんは
「この名前さあ、タイプすんのめんどくさいから「あ」「い」「う」でよくね？」と他人にわからない暗号にしたがったり
「オブジェクト指向ってさぁ、オブジェクト単位に分けるんっしょ？この再利用しない中身もさぁ
ぜんぶ用途別に名前つけてパーツに分類整理しなきゃ！」とかやりなさる… そうなると、クラスって何だ、インスタンスって何だ、コピーなら、コピー元も何かの役割を果たしてたんだろ？みたいな明後日の事言われるからな。
プレスの金型と、それで作り出した製品くらいの言い方の方が伝わる。
たまに金型に便利な治具ついてることもあるし、付けることもできて、それはプレスせずに金型から直接使えますが、
その治具にメモとかつけると皆から見えたり、誰かに剥がされたりするので、必要がなければ製品に付けたほうがいいですよ、
何回プレスしたかのカウンタとかは治具につけたら良いですね。みたいに説明した事ある。
スーパークラスとかサブクラスも、同じように、互換品の金型と互換品とかそういう説明できるから、物理な型で説明すると割とわかってくれる。 プロトタイプベースな言語だと、コピーのメタファの方が的確になったり、まぁ難しいわ、もう自分が知ってる物を、1から人に教える順番を考えるのは。 自分がちゃんと理解してないものは人に説明できないって言うしね >>671
わかるわ。耳が痛い。教育することになって逆に知る事も多かったしな。
若手の新アイディアは、素直に教えてもらってる。
たまに俺が相槌しか話してないうちに「出直します」って言うから、どうやらテディベアとしても活用されてる模様。 自分の行動を素直にと修飾するところが完全に淫乱テディベア オブジェクト指向を理解させたければ
まずはオブジェクトを理解させることからはじめないと
クラスやプロトタイプは二の次でいいし
責務や役割は別レイヤーの話 >>677
IT後進国の日本ではまだほとんど導入されてないね
非正規化DB 、非レイヤー化、貧血ドメイン、トランザクションスクリプトが主流 >>677
結構やってるでしょ
エヴァンス本から何年経ったやら… >>679
>>682
完全に対立してるな。
個人的には比較的昔からある企業は前者で、若くて成功してる部類の企業は後者かな？と思うけど。
実際DDDやってるぜー、て現場はどういう特性なんだろ。 要件定義や設計時にDDDの考え方を(一部)導入してるのと
実装含めて厳格にDDD導入してるのとで違うよね
前者は多いけど後者は少ない
>>679は実装者の視点
>>682は要件定義・設計者の視点
おそらく たとえば>>26をDDDでやるとどんな感じになるの？
DCIでやったときとの違いも知りたい >>687
業務アプリを受託で開発するのが主戦場
iOSと同時開発必須
自分で直接販売するのはバクチだね
アプリ数多いといってもニッチはまだまだ足りてない >>592
別に複数あっていいと思うが
社員給与を振り込む
給与の分類か属性かで >>592
給与は社員に与えられるものだから
「社員に対して」は要らなくね？ 役員やパート・アルバイト等、社員以外のケースがあるんじゃね？ >>592
目的語でひとくくりにするとわかりにくいけど
日本語では名詞が述語をどう修飾するかは格で区別されるから
格を考えればよいかと
1.「振り込む」が述語ならば振込先は口座なので「社員の口座に」としたほうが良いかと
振り込む(社員の口座に:与格, 給料を:対格)
2.「社員に」を使うなら述語は「支払う」かな
支払う(社員に:与格, 給料を:対格)
3. 対格しか使いたくないんですということならば「社員の」という属格で対格を修飾するしかないんじゃないかな
振り込む(社員の給料を:対格) すっごい不評な法令検索つくって賞もらっている大学教授
法令データベース「e-Gov法令検索」リニューアルにあたり、同法情報研究センターの協力教員である名古屋大学情報基盤センター（センター長：森健策）の外山勝彦（とやまかつひこ） DDDと言えば20項目の責務単位でドメインクラス作ったら一つのグラフ作るのに20個のクラスがデータベースに問い合わせちゃってパフォーマンスやばい
有識者のみなさんはどうやってるの? DDDならドメイン層とインフラ層のレイヤーは分けろ
つまりドメインのクラスが個々に
直接SQL文でDB叩いたりしない >>698
例えばドメインクラス「作業時間」にhogeプロジェクトの作業時間を問い合わせた時、作業時間クラスがDBクラス使って作業時間を教えてくれるんじゃないの?
この辺解らないとパフォーマンスの問題でアクティブレコードに走っちゃいそうです >>699
たとえばソシャゲみたいなWebアプリをイメージしてみよう
一個アイテムを見るたびにDBアクセスしてたら重いから
画面を遷移するときにまとめてローディングするよな？
だからそういう風にインフラ層で
ある程度まとめてデータ取ってきて
ドメイン層の内部ではDBに直接触らないようにする >>700
それはレイヤ分けるメリットでなくて
レイヤ分けるデメリットをカバーする方法じゃないの >>700
あらかじめオブジェクトにぶち込むのかな
油断するとメモリ食いそう >>703
昔は画面単位にデータ取ってたけどトランザクションスクリプトアンチパターンになるから作業時間とか予算とかドメインでクラス分けたんだ
それぞれのクラスがデータベースに問い合わせるからウッホという状態に >>697
基本は集約一つにリポジトリ一つ
レポーティング用途の場合はドメインモデルやリポジトリを経由せずに
DBレイヤーに直接問い合わせるのも有り
ドメインモデルを経由しなければ
ドメインロジックが分散する可能性があるのでトレードオフを判断したり
それを避ける工夫が必要だったりする
Patterns, Principles, and Practices of Domain-Driven Designって本で
一つの章使ってレポーティングの実装パターンを紹介してるので読むといいと思う ドメイン駆動と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とドメインオブジェクトのマッピングを手書きするってのはそれはそれでめんどくさい >>707
AutoMapperってやつそんな賢いの? 逆にDDDこそORMだろ
集約をそのまま永続化したいんだから >>709
どうかな
さっきも書いたようにDDDに忠実にドメインモデルを構築するとpublicプロパティが無くなって完全コンストラクタでインスタンスを構築しなければならない
DTOのようにフラットな構造にならない点でもORMで扱いにくい そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ
RDBは個々のオブジェクトではなく集合としてのビジネスルールを表現するのに適している
単なるデータストアではない
1ヶ月の間に正当な休暇を間に挟まず3営業日連続で欠勤した従業員にはペナルティを与えるといった業務ルールがあったらSQLで解決するほうがスマート どのORM使ってるの？
いまどきORMのために可視性を変えたりしないでしょ >>712
> そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ
DDDだろうとトランザクションスクリプトだろうとDBの役割は変わらないよ
ドメインモデルから見てあたかも単なるオブジェクトの置き場であるかのように振る舞うっていうのは、
そう振る舞うように作ってるからそうなるのであって、DBから見たら、アプリがDDDで作られてるかどうかなんてわからない >>712
じつはそういう考え方もアリだと思う
SQLやPrologでビジネスルール書くのもアリ
でも現実的にはDDDの
インフラ層にDBを隔離するやり方が無難だと思う
SQLでビジネスロジックを表現すると
シンプルな例だと分かりやすく感じても
実務レベルの複雑なルールでは非常に難解になる
OOでチマチマ差分を書いていく方が分かりやすい
これはなんでOOが主流なのかの理由でもあると思う >>712
ひっかけっぽい例だな
SQLかじったレベルじゃそれは書けない
普通にアプリでやったほうが柔軟性高そうだ >>712
RDBMS主体でやるプロジェクトもあるだろ
ただ古臭くて不便なことが多いからか
アプリケーション側でやるのがほとんど
技術者の数も違うからかな 期待のデータベーススペシャリスト持ちが開発してくれたプログラム
1クラス1メソッドにSQLをぎっちり書いていてくれた
流石データベーススペシャリストだと思った そんなんアーキテクチャ検討時に認識合わせしとけよ
単なる指示ミス >>719
チームリーダーは電気寄りのC使い
JAVAの実装にはノータッチ データベーススペシャリストがSQLしか知らんのは仕方ない
ソフ開持ってなきゃね オブジェクト指向のスペシャリストとは言ってないからな メンバー集める時はくだらん資格のことより影響を受けた本とか聞いた方がいい オブジェクトにメソッドでリクエスト飛ばすと答が返ってくるならそれはそれでいいような… >>719
>>718みたいな奴が指示する立場なわけないだろw DBスキルつけても負の遺産と有害な社内規約のせいで役に立たないことが多いね
データアクセス層でオブジェクトにマップしたらもう二度と中は見たくない >>720
javaはともかくJAVAって書かれると
あっ・・・（察し）ってなるから気をつけて スクリプトの方はjava表記多いけど
Javaの方は書籍とかもJAVA表記多いよねぇ ネット校正員多いけど
そんな表記は本質に全然関係ない JAVAが得意とかJAVASCRIPT経験5年とか書いてるの見て
まともなコード書けるやつだと思えるの？ そんなことで何か判断してる気になってるオマ、恥ずかしいぜｗ java - コマンド。
Java - 言語。
JAVA - 茶。 >>723
VBの絵本でプログラムを覚えました
非常に解りやすく良書だと思います
御社のお役に立ちたいです 憂鬱なCプログラマのためのオブジェクト指向入門かなー 読みにくくなるとかでクラス禁止になった
で、大卒正社員PMがクラス作った俺を高卒非正規はスキルが無いと滅茶苦茶言ってる
帳票の抽象クラスとそれを継承した3帳票のクラス作っただけなのに
つかボタンイベントで作られるメソッド以外禁止にする勢い 前任者がボタンイベントのメソッドに処理をつらつら書いて完成させた成功体験が悪かったみたい
全部のメソッドに同じ処理をコピペしてるから修正の影響範囲がわけわからん >>740
カスなチームでまともな自分アピールならマ板でやれよ >>740-741
そうは言っても仕事で
オブジェクト指向のメリットって
説明できんやろ？
やれるもんならやってみいや 結局、ここで人を馬鹿にしてる奴等もいざ自分が説明する立場になったら
何もできんということは覚えておいたらええよ >>744
同じコードをどこにコピペしたかわからんなるぐらいなら
クラスで一括にしたいなぁ >>747
俺じゃなくて大卒正社員PM様に説明して差し上げろ >>741
そいつここに呼んでこい
精神崩壊するまで論破して追い込んでやるよ 作っておしまいなソフトは多いし
規模が大きくないか、仕様が変わらないようなところなのかもしれないし
個別に修正するときはコピペした方が影響の範囲は小さくなるし
一か所見れば処理がわかるってんならコードの見通しもいいし
ソースコード見ない段階であれこれ言うのはちょっとちょっとちょっと >>751
作ってお終いなら俺は文句言わないよ
改造とバグ修正を投げられたから困ってるんだ
関心が分散しまくってる
高卒非正規の脳じゃオーバーロードだ 無職じゃないって
つかクラス化した場合の有効性をコストで可視化しろって
もうバグ満載でリリースしてデスマーチコースだ
IT業界らしくなってきた ■ このスレッドは過去ログ倉庫に格納されています
