OOP 2

お、何、その人すごいね。
やたら「日本では」「日本だけでは」を強調するのが鼻にかかるけど。
外国の一般的企業の実践例、風潮を知った上で言っているのなら、
それなりの信憑性あるソースなり、体験談を語って欲しいところ。
EAAを真面目に考えようとしている人は凄い共感もてるわ。

>>950
その記事読んだ、大笑いした後に、マジか！！　と考えてしまった。
COBOLは強い影響力があるんだな〜

片手間にやってる試験なのに、真面目にになる方がアホだよ。
大人だったら流せよな。愚民代表がそんなに楽しいのかね。よーわからん。

>>954
問題提起なんだから。大人だったら分かるよな。
2chで「試験問題が糞過ぎる件wwww」ってスレ立てるのとは違うんだよ。

>>952
「SI業界」という言い方だと全世界的にそうなのか、という話になるから、
筆者が実体験としても分かる範囲である「日本の」と限定してるだけだろ。

余計なこと書いて悪かった。
単純に日本は、日本ではって言葉が多すぎるのが鼻についただけだ。

実際ググって出てくる英語の掲示板とか見ても
レベルは日本と似たり寄ったりでがっかりすることが多い




あきらめたら終わり
満足してしまっても終わり

>>948
組むだけなら、それが正解。
しかし保守を考えたらOCPが適応しやすいOOになる。

あとは規模でも違ってくる。
小規模や社内向けアプリなら、大半のアプリはOO以外でも大丈夫。

まっ、最近はここの住人みたいに技術が無い人間が多いから
OO以外が無難。

「保守」というと、ソフトを書くという本題と関係ない、みたいに思う奴が多そうだが、
つまり、要求の変化に対応するための改良ということであって、開発とは不可分。

書き捨てでいいならそれでもいいんだが、そんなのちょっとしたスクリプトくらいのもんだな。

>>960
OO の場合
要求の変化 -> 処理の変化 -> ラッパライブラリの差し換え
なら対応できるけど,
要求の変化 -> 処理の変化 -> 末端ライブラリの根本的見直し -> 全滅
じゃ、ねえの？

>>960
ここいうスレを大規模開発のスキルのある人が牛耳る。
しかも、ソフト開発というのはこういうものだという決めつけ
を付けて。だけどまてよ、OOを採用するにしても、
個人レベルもあれば、小企業の社内向けのものもある。
こういうものは、共同開発自体が必要無いものが多い。
保守というが、一度納入されたアプリの変更はありえない、
というものが大半。これではOOの利点の多くが要件に
ないということになる。こういうケースでもOOPは使われて
いるのであって、ある程度はそのことも念頭に入れた議論
が必要ではないか。

>>962
おまえはもう少し要点をまとめる書き方を勉強しろ。

それで全滅しない言語教えてくれ

>>960
その通りだな。
>ソフトを書くという本題と関係ない、みたいに思う奴が多そうだが、
俺が思うには多分理解出来ないだろう、本を読んでもこればかりは
経験を積まないと技術者として物にならない。
みんな書籍からの知識をひけらかしたいだけだろうな。

>>961
>要求の変化 -> 処理の変化 -> 末端ライブラリの根本的見直し -> 全滅
>じゃ、ねえの？
960じゃないが、それは保守じゃなくリプレースな。

>>962
>ある程度はそのことも念頭に入れた議論
>が必要ではないか。
そうだな、だがみんな経験が無いから議論出来ないんだよ。

しかし、OOを理解してない奴は保守以外にOOを何に使っているんだ？
あとは共通部品やライブラリーぐらいか？
それだと開発の一部だけOOを適用すれば済む話だしな。
まっ本人がOOと思っているだけでOOじゃ無いかもしれんがｗ

そもそも多態がない言語なんて、開発自体が辛いと思うようになった

>>965
そうですね。
本人がOOと思ってるだけでOOではないのかもしれません

>>967
>本人がOOと思ってるだけでOOではないのかもしれません
まっ簡単に見分けることは出来るがな。
実行時のオブジェクト数が１０００以下なら、まずOOじゃない。
OOが出来ない奴はオブジェクトを関数みたいな作りにするからな。

>>962
> 個人レベルもあれば、小企業の社内向けのものもある。
> こういうものは、共同開発自体が必要無いものが多い。

開発という行為は、三日前の自分と現在の自分との共同開発だと考えることもできる。
個人レベルでも、少人数開発でも、OOのメリットはあると思うよ。

> 一度納入されたアプリの変更はありえない

「アジャイル」という開発手法があってだな。

なんだかんだいって、みんな最後はC言語に戻ってくるのさ。

>>970
夢がないこと言わないでw

Cだとやっぱり機能が足りない。
C++は無駄な拡張しすぎ。
難しいね。

C++はPerl6みたいなもんだわ
付け焼刃のOOPもどきじゃ駄目だよ

どこと付け焼刃といってるのか
C++はCにSimulaの機能を追加しようとした正統な言語だよ。
その後のマルチパラダイム路線がきついが。

そこでObjecti...おや、誰か来たようだ

>>968
わかる、オブジェクト指向が出来ない人間は
１つのクラスに一つのインスタンスしか作らないからな。
会社に大勢いるよ。

答えがないからみんな俺のがオブジェクト指向、あいつは馬鹿って感じ。

OOが上手く実装さらているかは別にしても
オブジェクトが少ないんだから
プログラムが”オブジェクト”を”指向”して作られていないのは確かだな。

>>977
お前のつくっているプログラムはOOPで作っている構造化プログラムだからｗ

>>978
>>977

C++「Javaがやられたようだな…」
Smalltalk「ククク…奴はOOPL四天王の中でも最弱…」
ObjectCOBOL「構造化ごときに負けるとはOOPLの面汚しよ…」

構造化もOOPの一部分なのになに言ってるんだ・・・

　　　　　　　　　　　　 　 ∩＿
　　　　　　　　　　　　　　〈〈〈　ヽ
　　　　　　＿＿＿_　　　〈⊃　　}
　　　　 ／⌒　　⌒＼　　 |　　 |
　　　／（ ●） 　（●）＼　 !　　 !
　 ／ :::::⌒（__人__）⌒:::::＼|　　 l
　 |　　　　　|r┬-| 　 　 　 | 　／　＜こいつ最高にアホだお
　 ＼ 　 　　｀ ー'´ 　 　 ／／
　　/　＿＿　 　　　　　　/
　　(＿＿＿）　　　　　　/

OO, OO って, 言ってるやつらに鍵って,
「 不必要な状態変数を持ち込みたがる」
のはなぜですか？

ちょっとどのレベルの話しているか分からん。
字義通り取れば、不必要なものを持ち込むのは単なる設計・モデリングミスだろう。
イミュータブルで副作用のないコーディングを目指すべきだというのならば、
理想としては同意する。ただし、業務アプリにおいてそれを実現する方法を俺は知らない。
だから、ステートパターンなんかでワークアラウンドな対応を取る。

>>984
おまえさんみたいのは全然安心
でも, 現場は， 不必要な状態変数を持ち込みたがるやつが多すぎ
で, 結局, class/object に閉じ込められたグローバル変数のてんこ盛り
なんのためのOO ?

質問。

図書館やレンタル店どっちでも良いが
未返却一覧を画面に表示する場合のオブジェクトの種類はどれだけ作成するか。
１．画面オブジェクトのみ。
２．画面オブジェクト＋顧客情報オブジェクトX未返却者数分。
３．画面オブジェクト＋顧客情報オブジェクトX未返却者数分＋商品X未返却商品数分。

>>986
そんなもんbackendが何かにっよって変わるだろ?

>未返却一覧を画面に表示する
これはOO的ではなく、手順的（構造化的）

>>986
それ自体がドメインとなる要素なんであれば、
未返却一覧Repositoryを作る方法もあるって、ファウラー先生がRTしてた。
List<未返却> 未返却 = 未返却一覧Repository.getAll();でおしまい。

種類なのか、前のオブジェクト数1000云々に対抗してるのか不明だけど、
これを実装するとしたら
画面、画面コントローラー、Repository（Service Class）、dao、Domain Object（Entity）が一般的じゃね。

>List<未返却> 未返却 = 未返却一覧Repository.getAll();でおしまい。
ごめん、間違い。
List<貸出商品> 未返却 = 未返却一覧Repository.getAll();でおしまい。

>>987
>そんなもんbackendが何かにっよって変わるだろ?
簡単に書きすぎたか？RDBよりデータ取得して画面に出力ようなイメージだったが。

>>988
>これはOO的ではなく、手順的（構造化的）
手続き型と言いたいのか？それなら
１．RDBよりデータを取得して
２．画面一覧にデータ設定して
３．・・・
見たいのが手続きと言うだが、
>未返却一覧を画面に表示する
は４GL的に宣言として書いていると思うが。

>>989
>未返却一覧Repositoryを作る方法もあるって、ファウラー先生がRTしてた。
なるほど、マーチンはそんなことを言っているのか。
>種類なのか、前のオブジェクト数1000云々に対抗してるのか不明だけど、
オブジェクト数の話で、話を振ってみた。

>画面、画面コントローラー、Repository（Service Class）、dao、Domain Object（Entity）が一般的じゃね。
なるほど、しかしそれはクラスの数では？

OOPで作と２か３になると思うが、OOPが出来ない奴は１で作る方が多い。
普通にRDBからデータを取得してO/Rマッピングしないでそのまま表示する。
実際職場でも、こんな感じで作ってある場合が多い、OOPじゃないが別に
そこまで凝る必要もないような気もするし。

話は変わるけどマーチンのアナリシスパターンは何回読んでも理解出来ない．．．

RDBとOOPの相性の悪さは半端ないぜ

OOPでなんでstatic変数があるのか理解できない

Singletonのためｗ
static変数が無いと結構不便かも。

無いと不便だと思うけど、
無いなら無いで、なんとかなるのかも。

Scalaとか、static無くなして代わりにSingleton用の記法にしちゃったしな。

上位からオブジェクト渡せばstaticいらないのに

正しくは「渡しまくれば」だな。

>>992
Java とか C++ って、
class ParsistentClass extends ParsistentMetaClass {
// define class members
}
とか、かいておいて、あとはライブラリがよきに計らってくれるような仕組みってないの？

おしまい

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。