マ板のPGにオブジェクト指向を覚えさせたい！

最近のマ板をみていると、オブジェクト指向を知らない人が多すぎる！

なぜ？　なぜ！？　あれだけUMLが普及しているというのに。
いまどき、オブジェクト指向を使わない開発などないといわれるほど
オブジェクト指向開発は常識だというのに。

デザインパターンを普及させるためにオブジェクト指向を普及させよう。
あなたもオブジェクト指向を普及させて、デスマーチを減らそう！
あなたもオブジェクト指向を普及させて、プログラマの給料を上げよう！
あなたもオブジェクト指向を普及させて、プログラマはSEも兼ねることができることを上司に証明してあげよう！


そして、より多くのプログラマが最高品質のフレームワークを自作できる
スキルを身につけやすくなるようにデザインパターン：アーキテクチャーパターンも普及させよう！！！

オブジェクト指向を普及させるには以外とこの本が役に立つかもしれない。

まずはGoF(Gang of Four)のデザインパターンについてわかりやすく丁寧に解説した
結城浩の本をよんでみよう。

Java言語で学ぶデザインパターン入門
学べるのは、デザインパターンだけじゃない。
http://www.hyuki.com/dp/

うるぜーはーが

オブジェクト指向言語を最も早く習得しゴールにたどり着き易くする言語はJavaといわれている。

Javaが嫌いな人はJavaに似た D言語, C#でもJavaと同じくらいの早さでオブジェクト指向を習得することができる。

C++は？Delphiは？

あなたもUML(Unified Modeling Language)を勉強しましょう。
オブジェクト指向に対する理解が深まります。

5分で絶対に変わるUML！
http://www.atmarkit.co.jp/fjava/devs/01fivemin/fivemin00.html

>>5
C++はお勧めしません。C++はなんでもできる優れた言語ですが
C++言語と他の言語との違いを何知らないで勉強しようとするとオブジェクト指向言語としてのC++を
忘れてしまう恐れがあり、オブジェクト指向よりも
重要でないこと(プリプロセッサ、演算子再定義、ポインタ演算など)にばかり夢中になってしまう恐れがあります。

UML皆でお勉強しよ♪ ３項関連
http://pc5.2ch.net/test/read.cgi/tech/1076446411/
　

>>1

うっさい。
オブジェクト指向の仕事をしようにも、自社のジジイが足を引っ張るので、チームとしてそういう仕事をできない。

>>1はオブ脳

ま　さ　に　　知　　遅　　れ　

>>7
>C++はなんでもできる優れた言語ですが
あなたは、何の変哲もないナイフが
　　1. 大根のカツラむきも (上手にやれば) きれいにできて
　　2. 鉛筆も (上手にやれば) きれいに削れて
　　3. 人も (上手にやれば) 一瞬で殺せる
からといって、それを「優れている」と評価しますか？

>>10
ドン！
http://www.amazon.co.jp/exec/obidos/ASIN/4798104183/250-9837423-7329022

嫁！


オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座 ビー　アージャイル！！！

>>9
ジジイにオブジェクト指向の書籍を紹介してみよう！

そしてオブジェクト指向の考え方はプラトンの時代からすでに知られていたことをも
紹介に付け加えておこう。

そしてジジイに哲学を勉強させよう。そこからオブジェクト指向を素早くジジイに理解させるチャンスが広がる！

> 重要でないこと(プリプロセッサ、演算子再定義、ポインタ演算など)にばかり夢中になってしまう恐れがあります。
はぁ？

実際C++厨ってオブジェクト指向をしっかり理解していない香具師が多い。
だからただのC厨っていわれちゃうんだよ

Java厨はﾌﾟﾙｸﾞﾗﾐﾝｸﾞの基礎すら理解してないけどな

>>12
バカとはさみは使いよう？

優れた人が使えば優れた道具になる物＝優れた道具と言ってもいいんでは？
たとえばよく切れる包丁があったとしても、素人の切り口と料理人の切り口では全然違うわけで。
使う人が低脳なら何使っても低脳

>>15
言語と概念とコンパイラを勘違いする人もいるよね。


オブジェクト指向とかそんなことに限らず、馬鹿は一生馬鹿

>>17
それはチミの脳内にいるJava厨で
実在するJava厨ではありません。

ﾎﾟｲﾝﾀを重要ではない、とか言って逃げちゃう輩と仕事したくねーな。

うん。CPUの動作原理のようにポインタは基礎知識として知っておいたほうがいい。
実際にソフトを作るときは、ドライバやOSを作るときや言語やライブラリ上の
制約がある場合を除いて必要ない。

なお、ここで言っているポインタとはメモリアドレス直指定のことであり、
単にオブジェクトを指し示すものという意味のポインタであれば、
ほとんどの言語で普通に使う。重要でないとか言う話はこれのことじゃないと思うが。

>>20
ポインタはオブジェクト指向において重要だ。
しかしポインタ演算をむやみに押しつけるやつはどうにかしてると思うが。

「オブジェクト指向が普及すればデスマーチが減る」
本気でそんなこと考えているのか？

「オブジェクト指向ができない奴が普及すればデスマーチが増えるだろう」

オブジェクト指向でなくてもデスマったことはない

>>24
違う

>>25
あなたの言う状態が本来の姿だ。いや目指すべき姿というべきか
デスマというのは人災で、多くの場合、政治的な問題を根源としている
手法やパラダイムが、デスマ回避のための力を持つわけがない

結城浩のデザパタ本読んだけど、これってC++にも応用できるの？

例えばSingletonパターンで、GetInstance()内でnewされた領域は、
どのタイミングで開放すればいいの？
あのソースをそのままC++に持ってくると、
アプリ終了までメモリが開放されないんだけど。

教えてエロい人。

結城氏デザパタ本を読まずに、

ttp://www.amazon.co.jp/exec/obidos/ASIN/4797311126/ref=sr_aps_b_1/249-8249487-5979507
これを読みなさい。

C/C++はポインタがあったからここまで広まったんだろうなー

>>27
たぶん一般的な用途では、

Singletonオブジェクトの寿命＝アプリの寿命

でいいはずなので　（・３・）気にしない！

>>28
さっそく明日購入してきます。

>>30
なるほど。
「Effective C++」にある、「メモリプール」みたいなもんですかね。
納得しました。

>>28
勇気本を読むなということはなかれ。

まず最初に結城の

Java言語によるデザインパターン入門

を読み、次にガンマの

　　　　　　↓

オブジェクト指向における再利用のためのデザインパターン

を読めばデザインパターンに関して効率良く理解が深まる。

>>26
> あなたの言う状態が本来の姿だ。いや目指すべき姿というべきか
> デスマというのは人災で、多くの場合、政治的な問題を根源としている
> 手法やパラダイムが、デスマ回避のための力を持つわけがない

そう断定することななかろう。

最後の一行は、
「手法やパラダイムが、デスマ回避のための力を持つとは限らない」
とするのが正論であろう。

家屋に非常口があれば災害が起きたときに助かるが
災害が全く起きなかったらお金の無駄であるかも知れない。

保険に加入すれば何か事故を起こしたときに保険金が下りて助かるが
まったく事故に遭わなければお金の無駄になるかもしれない。

オブジェクト指向開発を行えば大規模開発で何かのバグが多発した、あるいは拡張性問題にぶつかったときに
非常に大きな真価を発揮するが、大規模開発をしない、バグに気づかない、バグがあっても顧客に気づかれなければ
無駄なコストかも知れない。

だが、もし家屋に非常口がなければ非常口があったときにくらべ、即座に逃ることができ死なずに済む。

もし、保険に加入していなければ誤って事故で人を殺したり、保険金とは比べものにならないほどの多額の罰金を支払わされる羽目になろう。

もし、オブジェクト指向開発を怠っていれば大規模開発で、いざ拡張しよう、再利用しよう、発生したバグを処理しようというとき、
潜在的なバグを顧客に暴露されたときに、即座に対応できずプロジェクトの破綻、デスマーチになることは必至であろう。

>>27
Singletonオブジェクトの寿命≠アプリの寿命
な場合は参照カウント法でも使って適時開放しなされ

>>33
まるで「非オブジェクト指向の開発は、非常口や保険の無い開発だ」と言っているようだな。
イメージが先行していて雰囲気だけしか判らん
デスマーチとは「工期と資源のいずれかあるいは両方が妥当な量の50%以下であるプロジェクト」
と定義されているものだぞ。「過大な長時間労働を余儀なくされるプロジェクト」と定義されるものではない
「過大な長時間労働を余儀なくされる」というのは単なるデスマーチにおける事象だ。
提示している例は、品質管理の貧困や不在が原因で、結果として「過大な長時間労働を余儀なくされる」
という状態をデスマーチと呼んでいるように思えるな。
大体「品質管理の貧困や不在」はオブジェクト指向／非オブジェクト指向とは無関係だぞ
まず「オブジェクト指向が非常口や保険になりうる」ことの実証をしてみろ

>>35
デスマーチの定義ってはじめて聞いた・・・ヨードンさんか。

ちなみに私は「OOは単なる考え方の１つ」派です。

オブジェクト指向のメリットって何？
ぐぐっても難しい言葉ばかりでさっぱりわからない。
IF文減らせるだけだと思うのだがどう？
開発効率なんか上がらないし、ソースはわかり辛いし、継承しまくりで
どこがわかりやすいのかわからん。

オブジェクト指向のメリットって何？
ぐぐっても難しい言葉ばかりでさっぱりわからない。
IF文減らせるだけだと思うのだがどう？
開発効率なんか上がらないし、ソースはわかり辛いし、継承しまくりで
どこがわかりやすいのかわからん。

2度書きすまん。

>>37
俺も、心底、それが知りたい。「踊らされている奴」ではない人の回答を待つ

OOPにおいて最も大事な能力は”分類”の能力。
パッと要素を見渡し、観点によってそれぞれを分類する。
小学生の頃、そういったIQを測定するテストやりましたよね。
そうです。
OOPを有効に利用するにはある程度のIQが必要だという事実は否めません。

　オブジェクト指向は構造化設計の延長だと思っている。
　構造化されたもののデータ（Cなら構造体）に着目し、
データとそれに関わるモジュール（入出力・変換等）を
一つのオブジェクトとして纏めて管理する点で効率的。
　しかし、構造化モジュール→オブジェクトにする為にはそれなりの作業量があり、

　オブジェクトにした共通モジュールで開発する事の効率＞オブジェクトに纏める作業量

　でなければ、オブジェクト指向を用いる事はあまり効果的とは言えないと思う。

　つまり、構造化設計では共通モジュールを纏め切れないほどの大規模システムでなければ
　意味なしと思っている。
　※これは共通部分のみオブジェクト指向を用いるってことで限定しています。
　おれの認識ではこんなもんです。。

そんな事無いでしょ。
簡単なアプリ作ったりする時に
気軽に汎用的なクラスを継承したりするでしょ。
それってＯＯＰの恩恵にあやかって事なんじゃないの？

飲み込めたら分かりやすいし便利なんだけどね。

で、結局メリットは何よ？

>>45
例えばコードの再利用とか保守のし易さ。
利点が解らないとか言ってる奴は使った事ないのかい？

>>45
例えばさ、C言語であるイベントが起きたときに、複数の処理を登録しといて、一気に発動させたい
と思ったら関数ポインタ使うじゃん？
関数ポインタ使えば、いくらでも関数は登録可能になるし、登録されるほう（おおもとのほう）は
書き直さなくてもいいわけじゃない。正しい関数へのポインタなら。
でも関数に状態って持たせられないじゃん。状態持たせるなら、関数の外部にグローバル変数か構造体か、
なんかを定義して、そこに状態やらなんやら必要なものを格納しておいたりするわな。
でも（関数の）数が増えると、管理がめんどくさくなるじゃん。
だから、登録するのを関数じゃなくて、クラスにしたら楽になると思わない？
なんかイベントが起きたら、それを登録したオブジェクトに通知してくれて、
通知されたオブジェクトは勝手に動くみたいな。
基底クラスから派生させたクラスなら何でも登録できるわけだし、（つまり基底クラスしか知らないで良いわけだし）
状態も保持できるし、なにしろ見やすい。
それぞれのクラスは、この場合、それぞれのクラスはあるタイミングで同時に発動するわけだけど
それがソケット使うのかもしれないしGUIなのかもしれないし、音なのかもしれない。
それぞれに特化したプログラマさんが互いにまったく干渉せずに実装できるっていう利点もある。

すごく簡単な一例で申し訳ないけど、正しく使えば（設計すれば）、拡張しやすく保守性が高いってのはこういうところの
積み重ねだと思う。
でも、似非オブジェクト指向さんがいるから、意味不明なクラスが大量生産されて
オブジェクト指向？ハァ？ってかんじで、余計わかりにくくなってるんじゃないかな？

>>46
再利用はオブジェクト指向を知っている人じゃないとできない。保守も同じ。
だからオブジェクト指向のメリットとして受け入れられないんだ。

>>47
関数に状態を持たせるってところはいいな。しかし、基底クラスとか派生とか
いう言葉を使うと、アンチオブジェクト指向派は過敏に反応する。
割り込みやら状態遷移が頻繁だと、フレームワークにどういうパターンをつかったら
いいのか迷う。手続き型なら簡単なフロー書いてゴリゴリコーディングに移れるのだが
なかなかコーディングイメージができない人が多い。

＞でも、似非オブジェクト指向さんがいるから、意味不明なクラスが大量生産されて
＞オブジェクト指向？ハァ？ってかんじで、余計わかりにくくなってるんじゃないかな？
今までの開発ではこれでみなうんざりしている。メンバーを勝手にパブリックにする人
とかいて、かなりもめる。そんで、そもそもオブジェクト指向でいいのか？って議論が
起こっている。

俺もメリットわからんくなった。実際オブジェクト指向はクラスの再利用ができなければ
開発効率は悪いと思う。

>>48
オブジェクト指向も、ほどほどが丁度良いんだと思うよ、俺も。
なんかPOD構造でいいのに、必ずゲッターセッターを持たせなきゃ気がすまない奴もいるし
リファクタリングなんかでスイッチ文を消すためだけに全部オブジェクトにしてしまうのとか、やりすぎだろ。
あんなのは実際わかりにくくなるだけでやる価値ねえんじゃねえかとよく思う。
POD構造とかに反論はあるかもしれないけど（例えばアクセッサつければスレッドセーフに出来るとか、変更に強いとか）
絶対起こりえない拡張まで考慮するのは、アフォー以外の何者でもない。

やれデザインパターンだ、やれアジャイルだなんだって、なんかそんな「言葉」を使うことに
優越感じちゃってて、中身がついてきてない。
オブジェクト指向以外は悪、みたいな風潮はどうにかならんかとは思うな。
オブジェクト指向の良い部分はバンバン使っていきたいけど。

>>再利用
オブジェクト指向における再利用って、クラスの再利用というより、設計の再利用だと思うですよ。
汎用的なクラスになればなるほど複雑かつ使いにくくなるし。MFCが良い例かと。
設計を抽象化した再利用のカタログとしてデザインパターンやらなんとかパターンがあるわけで。
そこでModern C++ Designを読みつつジェネリクスで設計（そのもの）を実装するんですよ！！（違

ＵＭＬってなんですか？
デザインパターンてなんですか？
フレームワークってなんですか？

嵐じゃなくて、本気で。分かりやすい言葉で説明してほしい。

実際VB.NETやC#なんかでクラスを作っているし、
MFCモデルまがいなのも結構やったけど。
やっぱクラス設計書というかドキュメントも揃えてないのに暮らすだけ作ってるのとか見ると
逆効果。
結局中みなきゃならん。

ＵＭＬってなんですか？
デザインパターンてなんですか？
フレームワークってなんですか？

嵐じゃなくて、本気で。分かりやすい言葉で説明してほしい。

実際VB.NETやC#なんかでクラスを作っているし、
MFCモデルまがいなのも結構やったけど。
やっぱクラス設計書というかドキュメントも揃えてないのに暮らすだけ作ってるのとか見ると
逆効果。
結局中みなきゃならん。

>>50
UMLは単なる図の書き方。
表記方法。ばらばらだったから統一した絵の描き方。
よってUMLやってるからオブジェクト指向というわけではなし。

デザインパターンは>>49でもいってるが、
設計を抽象化してカタログ化したもの。設計を再利用するためのもの。

フレームワークは、プルグラマが必要な部分だけ書けばOKになるような仕組み。
共通部分なんかを全部隠蔽してあるだけ。一から組むのはダルイから。

オブジェクト嗜好でオブジェクト試行してみる。

感覚的にはSEよりもマの方が身についてるんじゃないかと
思う今日このごろ。
よかれ悪しかれあれこれリアルでライブラリ触ってるからかな。

SEの設計を見ると腑に落ちないことが結構ある。

>>52
説明ありがとうございます（＾＾

＞UMLは単なる図の書き方
って図、って何？どんな図？

フレームワークはわかったんだけど
デザインパターンとフレームワークの違いがわからない・・・。

フレームワークの設計書＝デザインパターンって事？

Javaはいろんなフレームワークがあって難儀。
でもVB.NETだって一緒だよね。
そういうののない開発現場ってのに当たったことがないんだけども。
逆にいつも「こういうフレームワークがあるので」ってそれを覚えて（理解するのに若干時間かかる）
作業するばっかりでなんかちょっとおもしろくない。
でも今後こんな開発現場ばっかりになるんだろうな。

>>54
ヘタレなSEだと逆にSE通すと話が余計にわからなくなる事が多々ある。
あんまりにも直におりてこないので
直接レビューに参加すると解らない事と答えがすっきりとおってかなりやりやすくなった。

窓口に問題有りな事もある。

>>54
それは実装レベルの設計ならば、に限ればそうかもしれないね。
でもオブジェクト指向って、上流工程から下流工程にスムーズに分析設計を流していけるものじゃん（理想としては）
上流工程の設計を渡されたところで、実際そのクラス図から実装できるわけないし。
SEはマに、その上流なクラス図やらなにやらから、実装レベルの設計まで落とせ、って要求してるのかもよ。

関係ないけどデザインパターンは実装のためのパターンだから、SEよりマが覚えるべきだと思う。

オブジェクト指向ってそんなに高度な概念か？
より現実世界に近くてわかりやすいと思うけど。

オブジェクト指向、UML、デザパタも尻尾にすぎない。

>>58
概念自体はすぐ飲み込めるけど
いざコーディングとなるとワケワカメになる。
インスタンスとクラスの違いって何？とか。
そこからさらにポリモーフィズムとかもあるし。漏れもえらい苦労した。

ソースは追いにくいよね。
初めてさわります、って人がその構造を知るまでに時間がかかってしまう。
きちんとドキュメント化してソースみなくてもナニをするのかってのを記してある書物があればいいんだけどね。
ないとこがあるからマジ困る。

半端にするなら本当に効率悪いと思うよ。

けど全員横並びなソースは書きやすいね。
イコール管理しやすいって事かもしれないけど。

インスタンスとクラスの違いがわからないのは、概念飲み込めてね−じゃん（ｗ

>>61
"概念"と言う言葉のとらえ方にもよると思うが。
その概念が現実世界を模写したものとすれば
現実世界とインスタンスやら何やらは乖離してるでしょ。

>>37
if文（というか分岐命令）を減らす
分岐命令で分岐する代わりに、関数へのポインタで分岐する
まあ、ぶっちゃけた話、本質的にはそれだけ

ＵＭＬ：UsecaseMarkupLanguage
間違ってたら注視してね。
アクタ、ユースケース
　○ ___
　＋―（ ）
　∧ ~~~

こんな感じの表。棒人間と楕円で構成される。

オブジェクト指向開発で使われる世界標準的なプログラム設計図。
ユースケース（楕円）は機能やアクセスされる部分
アクタ（棒人間）は何（人等）アクセスする何か

アクタがユースケースにアクセスし何らかの動作を起こさせる。
例：
アクタが名前を入力する。
ユースケースは入力された名前に該当する情報を返す。

先生（アクタ）がある生徒を検索する。
システム（ユースケース）が入力された生徒の該当する情報を画面に表示させる。

>>64
スマソ間違い
ＵＭＬ：UnifieldModelingLanguage

その他

クラス図
　　目（Ａ）
　　↑
目→目（Ｂ）
（Ｃ）

ＣはＢに所有されＢはＡに所有される

Ｃ→Ｂ
多：１

複数の学生が一つの講義に出席する。学生→講義、という関係になる。

その他コンポーネント図などがある。
自分大学で学んだ程度なので基礎程度の知識だけで
詳しくはわかりません。
自分とこのブラウザで検索してみよう。

注意
クラス図はＥＲＤと混同しないようにね。似てるから。でも矢印の向き逆だから・・・

>>64-67
ごめん、いきなり何？

手続き型に慣れてると、ユースケースは普通に書くが、次にいきなりアクティビティ図書いてしまう。
でもオブジェクト指向ならばクラス図を書くのが手順なんだろうな。でも出来ない。

クラス図が書けないと他の図はほとんど書けないものばかり。でもクラス化って難しくないか？
アンチオブジェクト指向派はクラス分けの難しさがあるから使えないと言う。俺も反論できない。

そうか？漏れはクラス図しか描かんが。コーディングの手間を減らそうとか
これを分けておいたら別の機会に使えそうだとか考えてたらクラスが出来あがる。
誰かがある日突然オブジェクト指向的な考えが出来るようになることを
オブジェクト脳の芽生えとか言ってたな。なんかゲーム脳みたいでイメージ良くないけど。

クラス図ってなんですか？

嵐じゃなくて分かりやすい言葉でお願いします。

それからユースケースってなんですか？
アクティビティ図ってなんですか？

ｽﾏｿ。>>64-66
で説明あったな。
なるほど。

クラス図ほしい。クラス化してる所は必ず暮らす図のドキュメントってのはあるもんなん？

>>69
いや、それで普通だと思う。
ユースケースの次に、アクティビティ図よりシーケンス図を使ってユースケースシナリオを書くのが普通。
そこからクラス抽出して、第一段階のクラス図を描くもんだろ。
そうしないと、そもそも顧客との会話が成立しない。
顧客にいきなりユースケースと静的な図を見せてもフローを理解してもらえるかどうか。
分析と設計は混同すべきじゃないと思うね。
実際、最初から実装に近いクラスまで全部抽出しようとするから難しくなる。
最初は誰でも（それこそプログラムを知らなくても）わかるくらい簡単な図を沢山書いて、
そこから徐々に実装に近づけてブレークダウンしていくのが良いやり方だと思う。
そして、必ず、そのクラスはどこから出てきたのかをさかのぼって導出可能にしておくことも大事かと。
プログラマのみの負担になる「実装」って分野だけだったら、クラス図だけでも（流れがわかってれば）
大丈夫かもしれんが、そもそもUML自体、コミュニケーションの道具としての一面もあるんだし
他のプログラマと円滑にUMLの図を用いて作業を進めるなら、クラス図だけというのは無謀。
動的な、流れを示すものがなければ、伝えたいことも伝わらんよ。

>>74
そのユースケースシナリオってのが大問題。UPがコケル元凶。

>>75
ユースケースシナリオと別のなんかを混同してないか？
ユースケースシナリオはあくまで、そのユースケースってどんなもんなのかを示すだけであって
そのまま実装するべきものじゃないぞ。
つーか、現実世界のものをコンピュータで表そうとしてるんだから、自然体のままで実装なんて
無理がありすぎる。

データとメソッドを一緒に持てるのは便利
それ以外は使わない

ttp://www.ogis-ri.co.jp/otc/products/konesa/technical/tutorial/index.html
このページよさげ。試用期間３０日間のうちにこいつでUMLマスターして、あとはJudeで・・・

このまえ、マジでエクセルでUML書いてる人を見ました

手続き型　　　　：計画する→設計しながら実装する→完成
オブジェクト指向：計画する→設計する（繰り返す）→実装する（大抵やり直す）

どう考えてもオブジェクト指向の方が開発期間が長い。

あまりいいプログラムではなかった。あのレベルで金取るな。

>>80
どっちも同じだと思うけどなぁ。
どっちでやってても「うげっ！」っていうような手戻りが発生することはある。

設計を完璧にやろうとしてなかなか実装に移れないというアンチパターン（分析地獄）
にはまりやすい。手続き型の頃はあまりなかったな。

どんなに完璧のつもりでもあとからぽろぽろと修正のフィードバック
いつまでも更新し続けるヘッダファイル。

>>80
>どう考えても
自分の考えが浅い、という可能性は無視ですか？

>>84
クラス設計はグループで検討するからな。それにその可能性を無視できないから
アンチパターンにはまるんだろ？

クラス設計なんて、共通部分だけできる人にやらしときゃいいだろ。
全員がバリバリできる必要なんてないと思う。
最低限、変数のスコープや処理の共通化を意識する程度でいいのでわん？

>>86
全員でとは一言も言ってないが？
確かに最初は共通化を意識というレベルだ。（それさえも結構時間かかるが）
開発していくとだんだんクラス定義変更するの面倒になって
こっそりルール破ったり、他のクラスの関数こぴぺしたりして
いったいオブジェクト指向ってなんなのだろうってなるんだよな。

セッターゲッターも面倒。カプセル化なんじゃそりゃ？ってな感じ。
再利用できるか調べてたら結局新規に作ったほうが早いという落ちもある。

>>86
全員でとは一言も言ってないが？
確かに最初は共通化を意識というレベルだ。（それさえも結構時間かかるが）
開発していくとだんだんクラス定義変更するの面倒になって
こっそりルール破ったり、他のクラスの関数こぴぺしたりして
いったいオブジェクト指向ってなんなのだろうってなるんだよな。

セッターゲッターも面倒。カプセル化なんじゃそりゃ？ってな感じ。
再利用できるか調べてたら結局新規に作ったほうが早いという落ちもある。

設計思想の統一なんて絶対に無理なことを要求してくるんだよな。オブジェクト指向って。
当然統一なんてできないからみな勝手な解釈で作って、再利用できない抽象クラスが無数に
作られて、なんだかオブジェクト指向を使うために無理やり使ってるって感じ。

プログラマ達の脳みそを電極でつなごう

>>90
LinkErrorで落ちるでしょ？

>>89
だからきちんとしているところでは設計を担当する人と、実際に実装する人とがわかれてるんではないのかな
実装するだけなら別に対して難しくないし（ものによっては難しいが、まあ例外として）
設計さえきちんとしてれば、それはそれで問題ないのでは。

>>92
そんな贅沢な開発部聞いたことないよ。どこも人足りなすぎ状態。

理想は一人で作ることだよ

うわーいくらオブジェクト指向の本読んでも、オブジェクト指向のメリットすらわからねー
牛が動物の派生だとか、同じ泣くというメッセージを送ると泣くとかなんでそんな面倒な
ことするんだよー。だいたい動物−牛ってどういうプログラム作ってんだよー。

ある程度の規模を作ることになると大なり小なりオブジェクト指向っぽい感じになってると思うんだが。
クラスが使えなくてもいくらでも作れるしな。

ただ実装コストがあまりに莫大なんで設計が甘く見られてる部分はあるね。まともな設計できる人間は
かなり少ないだろう。そういう人間は論文書いて、こんなん考えたので使ってねとまわりにばら撒いて
いたりするわけで。

すばやくスムーズに開発が終了するならなんでも良いよ。

>>95
実例がないと判らない体で覚えるタイプだな。オレと一緒だｗ
身近にいる人間で使いこなしているヤツはおらんかな？　そいつのソースみせてもらえ。

>>96
いや、実際業務で使っていたし、オブジェクト指向はわかっているつもり。
つもりだから、自分の担当クラスはかなりいい加減（ゲッターセッターなし
メンバーほとんどパブリック）

それが、今回アンチオブジェクト指向（というか単に知らないだけ）の
上司を説得しなければならなくなったのだ。俺本人もOOPに否定的なのに
どうしたらいいのか。

>>95
いつも例えが悪いと思う。そういう参考書。
たとえばRPGの敵。ボスと雑魚では共通する処理があるけど違う処理もあるでしょ。
デスピサロはどんどん変身していく。
スライムは合体してキングスライムになる。
ハエオトコはなにもしない。
コードが多くなると同じ処理がいくつもあると保守が大変。こう言うときに継承させると便利。

>>97
言いくるめるならクラス実装によって１００分の１くらいのコードで済む実例
を見せるのがいいと思うが。

まともに書けるヤツならどんな言語使っても同程度のコードで済ませてくるとは思うが・・・。

言語なにかしらんが、Ｃ＋＋を使いたいならＣ＋＋の便利機能を説明するだけでも
いいと思うがね。

>>98
それＲＰＧゲーを知らなきゃ結局一緒じゃんｗ

>>98
共通する処理はサブルーチン化すればいいだけ。同じ処理がいくつもなんて
手続き型言語でも作らない。だからオブジェクト指向のメリットでは
ないよ。むしろ仮想クラス作る手間が増えるというデメリットの方が大きい。
動物−牛よりははるかにわかりやすい例なのだが、そういう説明ばかりでどの本も
肝心のメリットをはっきり書いてない。

>>99
＞クラス実装によって１００分の１くらいのコードで済む実例
オブジェクト指向の幻想じゃないのか？そんなコードは見たことないし、
むしろ行数が数倍に増えてしまったプログラムの方が多い。

>>100
オブジェクト指向を理解しないで開発して
必要以上にコードが膨らんでしまう例はかなり多いだろうね。
オブジェクト指向に適した事例できちんと応用すればコードは若干減る、ってとこかな。
せいぜいそれぐらい。

ただ、場合によっては開発効率が劇的に向上するから、
使う場所と利点、実装の概要と言語ごとの特性をきちんと説明できる人が
プロジェクトのチームごとに一人いれば、
デスマーチを避けるための強力な武器になり得ると思う。

>>100
そんな時こそオーバライドすりゃいいのでは？
基本クラスにある機能で、似ているがちょいと違う場合は
同じ名称でメソッドをオーバライドして中身の実装を今の実態に
あうようにカスタマイズする。

>>101
すでに出来上がったクラスライブラリがあれば
デスマーチはないよ。どこもそれを持っていないだけ。
プロジェクト予算で、先行してクラスライブラリを作成する予算なんて
どこもくれないからね。

いいなぁ。
俺、UMLとかクラス設計とか当然プログラムもやりてーけど
VBばっか。VBばっかの現場に飛ばされる。
良くてUNIX Cだよ。あー、オブジェクト指向やりてえ。仕事で。

オブジェクト指向はそもそも、ある一定の規模を超えないとその真価を発揮しないんじゃない？
たかだがCで5000行で終わるような（一人ですぐに完結できてしまいそうな）アプリなら
むしろオブジェクト指向はめんどいだけになるかもしらんし。

>>104　かわいそう

望む事があるなら行動してみよう
願いは全部じゃなくても半分以上叶う

>105
そりゃそう、だいたい5K行じゃ子供のおもちゃ

クラス設計は、機能グループ分けをきちんと整理できて
スーパクラスにあるべき機能やInterfaceを明確に定義できる事
class A : public B{
　　//継承のツリーを美しくデザインできること
}
システム、OS、ハードウェア&ドライバ、ビジネスロジック
すべてに精通している必要がある

> システム、OS、ハードウェア&ドライバ、ビジネスロジック
> すべてに精通している必要がある

つまんないネタだなぁ

基礎設計は精通してなきゃならんっつーことで。
設計済みのクラスをプラットフォーム変更する場合とかは利用アプリを
変更することなくクラスのみの変更で済むというメリットが・・・。

やぁ、そんな素敵で大規模なプロジェクトなんてこの世にまだ存在してないぞぅ。

>>102
オーバーライドするためには仮想クラスが必要でしょ。
ドラクエの例ならデスピサロやスライムの前にキャラクター
クラスなりモンスタークラスなりが必要。
その仮想クラスをどう設計するかでまたもめるわけですよ。

会議に参加している人の知識もまちまちで、UML知ってる人やデザインパターン
知ってる人は、知らない人と会話するの大変。知らない俺が割るいのだけどさ。

スーパクラスを設計できる椰子は神だよ。
多すぎず、すべての子クラスに共通かつ絶対に必要な最小限の実装
いや、ルートクラスは実装ゼロもありえるかな
ゲームの例は実際的でイイと思うよ。まずは包括関係をよく整理する。

包括関係 has a
>>110が言っている
デスピサロやスライムはモンスタークラスに含まれる
モンスタークラスはキャラクタークラスに含まれる
キャラクタークラスはHPマネージャクラスに含まれる
全体的なクラスツリーを妄想し理解する能力がないとルートクラスを導き出せない
と思う。はじめにルートクラスありきじゃなんだよね。
これがOOPの敷居を高くしている理由じゃないかな。

virtual の正体は、上書き可能な関数ポインタだよ。
スーパークラスが自分の正体をしらなくてもソイツが
その継承下の専用回線で接続されたvirtualボタンを
押すことによりバックボーンメソッドを実行できるって訳さ。
virtual 使わないバカどもは、クラスはつかいこなせないぜ。

>113 C++に有効　Javaには無効でいいでつか？

Java には virtual じゃなくて abstract があったはず。

C++(virtual) Java(abstract == interface)
ようは仕様(戻り値およびメソッド名称、引数の型)を
策定し継承先でこの策定した形式を強制するひながたということで
いいでつか。

おまいら、他人が書いたオブジェクト指向でクラス使いまくり、
継承しまくりのソースってさくっと理解できる？

単に配列に放り込めばいいのに、変換クラスとか作って
いったん、データのコピーを作って、それを変換クラスに渡して・・・
とか見てると何がやりたいのかｻﾊﾟｰﾘになってしまう。

漏れのような馬鹿がいい気になってvirtual使ってスーパーを作り
それを継承したクラスを多数作ったところで
virtualメソッドの仕様に問題があるのに気づく。
当然継承した多数のクラスのすべてのメソッド仕様を修正することになった。

>117
センスのいい椰子のクラスなら直感が働く。
センス以前にアフォが作ると手続き型よりたちが悪い。

> 策定し継承先でこの策定した形式を強制するひながたということでいいでつか。
ばっちグーです。

なかなか良スレ期待age

そうそう、タイプとか定義して一々型変換かましてるバカ野郎ども。
そのタイプ分けをソースのあっちこっちに書いてるもんだから、
収集つかねぇっつーの。

スーパークラスで virtual 定義しておけば、タイプ分けして分別する
必要もなければ、ソースの整合化が保てるよ。

オブジェクト指向で組んでる奴ってのは
・これが最新のプログラミングだ！
・これが手続き型よりかっこいいんだ！
・俺様が作ったクラスは完璧だぜ。
・なのでクラスのprivateには誰にも触らせねぇぜ！

みたいな幻想を抱いて、自分しか理解できないようなクラスを
構築しているような気がする。

たとえばOOPは
「センダ」「レシーバ」で作る
ごちゃごちゃと沢山のメソッドを並べて呼び出すのはダメ
といいながら、POP3セッションメソッドをならべる。
もっとシンプルにならんかと悩む。OOPは深い。

void CHoge2Dlg::OnPop3()
{
CPop3 pop3;
pop3.setAccount("hoge");
pop3.setPasswd("hogehoge");
pop3.setSvport(110);
pop3.setConHost("hogehost.hoge.co.jp");
pop3.setPop3Stat(TRUE, TRUE, this->m_hWnd, HOGESOCK_ASYNCEVENT_POP3, FD_CLOSE | FD_READ | FD_WRITE);
pop3.sessionPOP3();
}

>>124

「オブジェクト指向」≠「手続き型」

これ、昔は散々叩かれていたんだけど、
いつの間に正当化されてしまったんだ？

ブラックボックス化だけでもすげー便利だけどね。

ライブラリを作るのが楽になってるだろう？

>>126
単に“手続き型”の意味が判ってない阿呆が増えたんでしょ。

>>127
OOの根源的な目標って「再利用」だって聞いたことあるんだけど
ライブラリの再利用って出来ていますか？

オブジェクト指向において、ソースが読みにくいのは、それぞれのクラスが別ファイルに記述されていて
なおかつ、オブジェクト間の通信とかいって、いろいろなところに飛びまくるから読みにくいんだよね
しかし優れた設計から実装に落としたものって、その飛びまくる先を追わなくても何をしているかが一目瞭然なんだよな。
だから、優れた設計があればオブジェクト指向は本当に素晴らしいものだけど、実際のところ
優れた設計を出来る奴なんて一握りの人間しかいないわけで…
理想と現実のギャップを感じる。

>>129
一番出来るやつが作ってるやつは出来てる。
規模が小さい上に期間もキツイけどなんとか使ってるって感じかな。

メイン張ってライブラリ構築まで出来る人間が３人いるところは楽々まわってんじゃないかなぁ。
その３人が協調できてれば・・・。


ライブラリ使って案件片付ける人と、ライブラリ作りながらライブラリを使って案件片付ける人を
用意するのが一番いいんだけどね。ライブラリだけだと実機に合わないこともあるんで・・・。

プログラマー１００人規模でライン２０くらい回してる会社がウラヤマスィ。

>>129
手続き型言語でもライブラリの再利用は普通にあるぞ。OOPの再利用とどう違うのか
わからん。

手続き型の再利用の場合で、仕様がすこしだけ違う場合。
ライブラリの該当functionをこぴぺして
function名をすこし変えて、中身の実装をすこし変えてなんてやる事がある。
保守性は最悪。OOPならば既出のオーバライドで済ませることができる。

void CHoge2Dlg::OnPop3()
{
//接続POP3ホスト名、POP3ポート、アカウント、パスワード　Type2
CPop3 pop3 = CPop3("hogehost.hoge.co.jp", 110, _T("hoge"), _T("hogehoge"));
//非同期通信、ファイルシリアライズスイッチ、コールバックイベントID、処理イベント
pop3.setPop3Stat(TRUE, TRUE, this->m_hWnd, HOGESOCK_ASYNCEVENT_POP3, FD_CLOSE | FD_READ | FD_WRITE);
//POP3セッションマネージャ起動
pop3.sessionPOP3();
}
//非同期通信ステータススイッチもコンストラクタで渡せるようにしておいて
//理想はこんな2行程度でPOP3セッションを自動化する
//このぐらいシンプルならば再利用する人もそんなに悩まないのでは？
void CHoge2Dlg::OnPop3()
{
//接続POP3ホスト名、POP3ポート、アカウント、パスワード、ステータススイッチ Type3
CPop3 pop3 = CPop3("hogehost.hoge.co.jp", 110, _T("hoge"), _T("hogehoge"),
TRUE, TRUE, this->m_hWnd, HOGESOCK_ASYNCEVENT_POP3, FD_CLOSE | FD_READ | FD_WRITE);
//POP3セッションマネージャ起動
pop3.sessionPOP3();
}
//さらに、オーバロードの仕組みを利用して、定型スイッチはデフォルト値としてコンストラクタ内でセットする
//これよりもシンプルになる方法があれば誰か教えてくれ
void CHoge2Dlg::OnPop3()
{
//接続POP3ホスト名、POP3ポート、アカウント、パスワード、呼び出し元のWindows HANDLE Type4
CPop3 pop3 = CPop3("hogehost.hoge.co.jp", 110, _T("hoge"), _T("hogehoge"), this->m_hWnd);
//POP3セッションマネージャ起動
pop3.sessionPOP3();
}
ここまでやると、コンストラクタの引数タイプが違うものが　4つできる事になる。

>>130
手続き型に慣れてしまった俺としては、やはり自分のクラスを疑うより他人の
クラスの動作を疑ってしまうわけで、結局飛びまくる先を追わなければならなく
なる。
優れた設計をできる人がいても、その設計をなぜか崩して実装する人がいる
から困る。

すぐれていないからくずされるんだよ無能

いやいや、実装されたクラス見ると明らかにおかしな崩し方してるの。

>>136
公開されているコードはかならず無智な人間が改変する。

真に問題ないライブラリはバイナリのみを配ること。

結局オブジェクト指向のメリットはif文減らせるってことだけだよね。

カプセル化や再利用性保守性の向上等いろいろありますが。
こういうメリットを全く理解できないやつは
大きなプログラム組んだこと無さそう。

>>139
(；´・д・｀)ｴｪｰ?

>>140
そんなもんメリットにならねーってことぐらいみんな知ってるよ。

じゃあ何がメリットなのか

>>142
>みんな知ってるよ。
みんな自分と同じくらい莫迦だといいなあ、って事ですね？

つうかカプセル化しないのは馬鹿の極みですよ
アクセッサメソッドの意味がわからないとか言ってる奴ばカスですよ
もっかい調べたほうがいいんじゃない？
なんか構造化プログラミングと本質的には同じだ（近い）と思うんだけどね、カプセル化。

でもなあ、継承が延々と続くクラスで共通のシステムログを吐き出そうとすると
ルートクラスのファイルポインタは　protected:にしないとだめんなだよ。
喪前しらねえだろう。なんでもかんでもprivate:かよ。ﾀﾞｻｯ

カプセル化しか語れない椰子も馬鹿の極みですよ
融通がきかないA型でしょうか

まあ基本はprivate:な訳だが

>>145は前後のかかわりが全くない
ユーティリティクラス担当とみた

>>145
> アクセッサメソッドの意味がわからないとか言ってる奴ばカスですよ

もしかして貴方はバカみたいにアクセサ作りまくる人ですか？

getter/setterはメンバ変数さえあれば馬鹿でもインプリできるもんな

>>150
あのさあ。オブジェクト指向しらない人間にも理解出来る書き方をして欲しいな。
このスレはそういうスレなんじゃないの？（スレタイ見る限りでは）
情報隠蔽が有用だからアクセサ作るんだろ？
「バカみたいにアクセサ作りまくる人」ではアクセサを作る弊害が全然わからないじゃないか

というかアクセサはつくりまくるものでしょう？
違うの？

>>152
> 情報隠蔽が有用だからアクセサ作るんだろ？

そこまで分かってるなら、弊害くらい分からないか？
情報隠蔽したいのに、ほとんどのメンバ変数にアクセス出来てしまっては
隠蔽の意味が無い。

出来るだけメンバ変数にアクセスしなくても良いクラス設計するのが大事。

>>154
了解しました。蟻が�d。
>情報隠蔽したいのに、ほとんどのメンバ変数にアクセス
こんなことする人間がいるということ自体が考慮の外だったんで。スマンカッタ

アクセサを必死に作った挙句に
メンバ変数が全部public:な椰子っている？

プロパティがあればアクセッサなんてので悩む必要が無いんだけどな。
名前はそのままで、privateメンバ変数⇔publicアクセッサ相当を
自由に変更できる。

>>140
オブジェクト指向を知らない人にそんな用語使ってメリットを説明しようと
いうことが無理だろう。特にアンチオブジェクト指向の人はバカの壁作ってる
からいっそう無理。

もっとそういう人たちにもわかりやすいメリットの説明はできないものか？

>>151
そういうバカがいるから、情報遮蔽なんて有名無実なんだよ。

なんか>>152とかアクセッサの利点をわかってねー奴が多いな
カプセル化の基本中の基本なのに。

弊害ってなんだよ。そんなもん存在しねーよ。
いちいち書くのがめんどくせーなら>>157が言ってるようにC#ならプロパティつかえ
C++ならプロパティ用マクロでも書いとけ。Javaなら気合でなんとかしろ。そのうちプロパティが搭載されっだろ言語レベルで。
アクセッサはメンバ変数にアクセスする為のメソッドじゃねーんだよ
情報隠蔽の意味を取り違えるな。
実際に存在するメンバ変数へのget/set、実際には存在しねー論理的な意味でのメンバ変数へのget/setも
同一に扱えることが情報隠蔽の利点その１だろ。
そいでもって、例えば既存のクラスをスレッドセーフにしたい時を考えてみろよ
アクセッサつかってればアクセッサメソッド内で同期を取ればそれで終了だが
メンバ変数直アクセスしていた場合どうなるよ？それを参照している場所すべてでクリティカルセクションでも書くのか？
馬鹿の極みだろ？恐ろしくわかりにくいバグが発生して、デスマーチ確定だぜ？
修正は一箇所で済ませましょう。これ構造化プログラミングと同じだろ？
フラグとして利用できるpublic static const(final)intなんかは定数(READONLY)だから直アクセスするものが多いんだよ。(finalはちょっと違うが）

なんにせよ中途半端にアクセッサ使ってるような使ってないようなクラスは百害あって一利なし。
つうかクラスは使う側（クライアント）に、いかに使いやすいものを提供するか、だろ。
一時の楽を求めて誰でもかけるようなアクセッサを端折り
後でそのクラスを利用する、またはシステムを保守する奴に多大なる迷惑をかけるなよ。困るんだよ。激しく。

>後でそのクラスを利用する、またはシステムを保守する奴に多大なる迷惑

利用するときに迷惑なクラスはすでに話にならない、バグも一緒に継承しちゃうからね
システムを保守する・・完成したクラスは保守がいらないがOOじゃねえの？

>>161
なんかてめえは全然見当違いなことを言ってますね。
>利用するときに迷惑なクラスはすでに話にならない、バグも一緒に継承しちゃうからね
利用するとき迷惑なクラスにバグが入ってるなんて前提はどこにもねーんだがな。
迷惑なだけだ。すでに話しにならないって、それを使うことを強要される立場だったらどうすんだ？
なんでもてめー一人だけで作ってるわけじゃねーんだぞ？日曜プログラマか？
>>完成したクラスは保守がいらないがOOじゃねえの？
は、「保守がいらないが」じゃなくて「保守がいらないのが」と読み替えてOKかな？
完成されたクラスは保守がいらない？だからアクセッサも書いてないクラスが完成されたクラスなのか？

漏れは完成品しか使う木もしねえよ。
かわいそうな145だな、そんなに怒りまくるなよ。
どうどう。ｷﾓﾁﾊﾜｶﾙﾖ

145のプロジェクトには糞な椰子がいて足を引っ張られている
彼は多大なるストレスを抱えている。
がんばれよ。

なんでOOPの話になるといきなり切れだす椰子が多いの

>利用するとき迷惑なクラスにバグが入ってるなんて前提はどこにもねーんだがな。
おっといい忘れたけど、百歩譲ってバグがないにしろ
利用するときに迷惑なクラスは仕様のバグも含めて論外

構造化のときも同様だったよ。
匿名掲示板はなかったけどね。

>>161
>利用するときに迷惑なクラスは仕様のバグも含めて論外
なんど言ったらいいのかわからんが、使うことを強要される立場だったらどうするの？
論外なのは論外さ。俺だって論外だ。糞みたいなクラスを使わされるのは地獄以外の何者でもない。
だけど使わざるを得ない立場にある人だって沢山いるはず。
だから、作る奴はせめてアクセッサくらいはつけろよ？一時的にはめんどくさいかもしれないけど
それは後々必ず役にたつのだから。アンチOOでもそれくらいの利点はわかるだろう？
という話をしてるのになんでクラスのバグだのクラスの完成度の話にもってくかね
アクセッサの意味をオブジェクト指向の意味に拡大解釈しないでくれ

>なんど言ったらいいのかわからんが、使うことを強要される立場だったらどうするの？
喪前もこの業界で生きているならこんな泣き言はくなよ。
言い訳だよ。喪前が直せばいいんじゃんか。簡単な話だ。
まずは直してから、なっ。それから喪前の意見を聞いてあげるよ。

188 名前：仕様書無しさん 投稿日：04/06/11 00:55
オブジェクト指向のわからん老人が傷をなめ合うすれですか。（ｗ
「オブジェクト指向とは何か」なんて時代はとっくに終わってる。
「オブジェクト指向でやる必要」とかじゃなくて、わざわざ「オブジェクト指向
でない」ように考えることがもうできない。
もう、空気みたいなもんで、いまさら意識するまでもない。普通だろ？

>>169
俺が直せるなら直したいさ
しかし俺がクラスのインターフェイスを改変することで、その変更はそのクラスを利用する
全システムに影響するわけだよ？そう簡単に直せるもんだと思うの？
素晴らしい設計者と、すばらしい実装者だけがいるプロジェクトなら言うことなんて何もない。
だけどそんなの理想だろ？どこにでもカスがいるもんだ。理想と現実は大きく開いてるんだよ。

IFから?
そりゃあだめだ。そのクラスは全部クラッシュしてビルドしなおしが
一番いいかな。漏れならそうするな。マジで。

貴重なOO(を理解する)技術者ではあるが、
直情的な>145とは仕事できないなぁ…

こういう考え方もある。
COMはバージョン管理はしないが、一度公開した機能はそのままにしておくお約束。
公開機能を使っている椰子がいるからが前提。

この考え方を頂いて
その問題の糞クラスのクローンを喪前が作って、継承元をさらりとすりかえれば？
もちろん既存の糞コードはそのまま。

ああ、しかしそんな糞なクラスツリーが存在する事が許せないかな。
きっと喪前も許せないよな。

>>173
俺は145がOOを熟解しているとは思えん。
つーか、OOの本質を突いていると言うより、己のOO解釈を
押し付けている。
完全に間違った解釈というレベルではないから質が悪い。

>>175
まあ、>>145==161は疲れているんだよ。カスのおかげでﾃﾞｽﾏｰﾁになっちゃって。
そんなに責めるなよ。彼は思い込みは激しいが、真面目な椰子じゃないの。

2chに来ること自体カスじゃねーの？


と言ってみるテスト。

といいながら、漏れも自分の仕事しなきゃ
ぢつは、今日トップレベルのクラスを小修正してその影響たるやﾝﾄﾆﾂﾗｶｯﾀ
>>145 おーい、こんなもんだよ。がんばって直せや！

>>174
その考えも使えないことはないんだが(COM風に)
糞コードでメンバ変数に直接アクセスしている場合、そのメンバ変数をpublicにしたまま
アクセッサを書くことになるんだよね。
これだと俺はいったい何をやっているのか良くわからなくなるよ。
んで、そのシステム（クラス）をいじくる限りは、「これからはアクセッサを使ってください！」のような
へんちくりんな決まりごとを作らなきゃならなくなる。
で、そんな決まりごとをつくっても絶対破るやつが出てきて結果的にアクセス手段過多で余計わかりにくいコードになるんじゃないかと。
COMがそれでもまだ成り立っているのは、COMは全てがインターフェイスメソッドを経由してるからだと思うわけだ。

>>173
現実では直情的ではないよ
匿名掲示板だからだよ^-^

>>175
俺がOOを熟知してるとは思えないが、それでも解釈を押し付けていることは無いと思うけどね。
そりゃたかだか300行程度のツールを作るのにスレッドセーフを考慮してアクセッサを書け！だの言うのは大げさすぎると思うが
そもそも300行程度のプログラムにはオブジェクト指向を適用するほうがどうかと思うわけで。

>そもそも300行程度のプログラムにはオブジェクト指向を適用するほうがどうかと思うわけで。
をいをぃそうやってすぐに喧嘩を売るから・・

>>158
なるほど。じゃぁ例えばカプセル化。
やたらグローバル変数を宣言したがる香具師は素人
と言うのはアンチOOPも含め衆目の一致するところだろう。
なぜか。いろんなところからアクセスが可能なため
バグの原因になったり保守性の悪さに繋がる。
カプセル化というのはこの考えをもうちょい進め、
変数のスコープを狭め、処理の内部化をする事。
と言えば少しは飲み込めるだろうか？

>>181
その説明では、「非OOPにおける引数によるインターフェース」との差異が理解出来ない。
被参照側のローカル変数は当然の事ながら参照側からは見えない

>>182
じゃぁ喪前が説明したら？

だからさあ、構造体に操作メソッドがおまけについたのがOOの基本操作体系
ポリモアフィズム、インヘリタンスがOOの本命部分
細かいところでスコープ系
private,public,protected
仮想関数系(抽象系) (JavaのAbstruct or Interface)
virtual void hoge()=0;　これが継承先で名前と引数を強制する仕組みの核となる
const系(readonly)
virtual void hoge() const =0;
static系(非インスタンス領域のグループ)
コンスト、デスト系
初期化・廃棄系(Javaは糞JVMまかせ、いちおうgcを利用できるが)
これらを組み合わせて再利用可能なモジュールをActiveDirectoryのような
ﾄﾞﾒｲﾝツリーではなくクラスツリーを作る。作ったクラスが糞だとだめ。
>>145のようなプロジェクトで使っているクラスのようにしてしまうのが
最悪の良い見本、あんなふうにしなければ大丈夫だみんな

>>184
>ﾄﾞﾒｲﾝツリーではなくクラスツリーを作る。
ここがよくわからない。
全体−部分ではなく、汎化−特化の関係にしろってことか？

ドメインツリーって表現はイケてへんと思う。

開発者がどの視点にたっているかでずいぶん考え方は変わるもの。
１４５が怒りを感じるのは、てめーの能力不足でＯＯを勉強するどころか
納期にまともに動くものを提出することもできるかどうかの香具師が、
納期を言い訳にしてＯＯを理解することを放棄するどころか、ＯＯが良しとする
長い目で見た保守性などをすべて放棄しているからだろう。

納期に間に合わせてちゃんと仕事をしている一人前がそんなことを言っていたら
殺したくならないか？

>>181
うむ、よくわかった。とりあえずカプセル化のメリットの説明はあなたのを使わせてもらう。
説明としてはこれぐらいの長さが適切だな。

>>184
そうやって専門用語を並べて相手にわかってもらおうという気持ちがあるのか？
たいていの場合、専門用語を並べるのは相手を煙に巻いてやり過ごすときで、
なぜそんなことするかというと、説明している本人が理解してないからなんだよな。

>>188
そらまぁ専門用語には違いないが、マにしてみたら普通の用語だろ。
ってゆーか、話をそらしたいのか？

専門用語の羅列や限られた状況におけるメリットだけを述べた客観的でない説明は
詐欺師のやり口に近いものを感じる。

>>190
それを理由にＣ＋＋の理解を放棄している一人だろう？
Ｃ＋＋は万能じゃない。ある程度の制限を掛けて保守性、再利用性を高めようという
ルールなんだ。

実装自体はＣ言語が動作すれば自前で作れちゃったりもするわけで。


アセンブラしかやったことない人間に、Ｃ言語すすめても、アセンブラでやるほうが
仕事はやいから。

こういわれたら、誰も反論できんだろう。その人間にとって見ればそれは真実だからね。

ここでＣも覚えられないバカとかいうのは筋違いなわけ。Ｃで作るよりアセンブラで作った方が
良い場合ってのもあるわけだし。

ＯＯはＯＯになじんだ世代だけで開発するようにならんと、まともにまわらにょ。

>>191
アセンブラの大ベテランでもCでコーディングする並みのプログラマーに開発速度でかないません。
例えが悪かったな。CとC++じゃどっちが開発期間が短く済むか微妙な場合も結構多いぞ。

プログラミング、ってのは理解が簡単でシンプルなものが一番だと思うのだが、
>>184みたいな羅列を見てると、それを覚えるだけで苦痛に思えてくる。

ゲーム機のハードだけがどんどん進化していって、それに見合うソフトを
作るのが困難になっていくように、プログラミング言語も機能を追加しまくって
複雑になっていくにつれて、それを使いこなして作る人間が減っていくような気がするな。

憂鬱なプログラマのためのオブジェクト指向開発講座を読んで
初めてオブジェクト指向の目指してるものがわかった。
IF文が減るとかカプセル化とか多態性なんてのは実装における一要素に過ぎない。
設計にこそオブジェクト指向の本質があったんだよ。

>設計にこそオブジェクト指向の本質
それがすべて。実装云々の話からはOOは見えてこない。

>>192
ライブラリ（？）が揃ってるならアセンブラ使った方が速いという状況もあるかと。
以前に使ってた６８０００系ならオールアセンブラでの資産しかないから、なんか作るなら
アセンブラのままのが・・・ってわけねーよな。（ワラ

>>195
それを実装してる現場でいきなり使えってなるから歪が生じるわけで。
コーディングと設計がきっちり分けられれば、うまくまわるかもしれんが・・・。

>195
あ、だから設計者が不足していると言うことでいいのかな。
PMもこのあたりのアサインに気を配らなければなのだが
現実OO設計をターゲットの言語レベルできちんとできるのはきっと
漏れだけだろう。(藁藁

PGにクラス階層を任せればそれは糞クラスになるの決まっているから
設計者がIFをがっちり設計し、IFをインプリメントするクラス機能
テンプレートツリーをPGに提示する必要があるかな。

設計者とPGが違ってる時点で糞

>199
喪前本当に馬鹿だな。
喪前のような椰子が>>145のプロジェクトのような糞クラス作るんだろう

では、もまいらのクラスの出来具合を尋ねますが、

すべてのクラスのメソッドは平均３０ステップで収まってますか？

もまいらのプロジェクトは業務を抽象化しているクラスがありますか？

実装レベルのクラス図を作成した時点で全体のクラス数は決まり、見積もりに
誤差は生じませんでしたか？

いまだに「共通関数は？」とかいっているメンバーがいませんか。

＞いまだに「共通関数は？」とかいっているメンバーがいませんか。
漏れが言っていまつ(w
public static な単純処理メソッドは、それ以外に言いようがないからです。
javaなら、Mathクラスの各メソッドがその代表でしょうか。

>201
共通関数を非難する前に、ステップとか言ってる手前を責めろ。

>201　喪前業務アプリ屋かよ、漏れは低水準開発屋だから
所詮土俵はかち合わないのだな。漏れが抽象化するのはINETのサービス関連だからな。
やってて楽しいよ。糞業務アプリは大嫌いだから漏れ。
技術的にもつまらんしな。DBカラムの操作ばっかしじゃんか。どうせ。

とりあえず、メソッドの行を数えてみたら 30ステップよりはやや多いかな。
これは詳細なシステムログを吐き出すためのコードがかなりの割合を占めている。
正常コード10%に対してエラーチェック60% シスログ30%といった割合かな。
喪前のPRJなんて　正常系70% エラーチェック30%じゃねえの(藁
だから破綻するんだよ。念のためシスログは当然インスタンスパラムで
ON|OFF|FULLオプション化してある。

>いまだに「共通関数は？」とかいっているメンバーがいませんか
馬鹿だな、staticメソッドは必要なんだよ。なんでもインスタンスメソッドに
するほうがよっぽどあれだ・・

見積もり？設計上の見積は基本的にはぶれないが、パッケージエンジンとなるクラスライブラリを
請け負っているので、難易度が高い実装についてはそのつど交渉しほとんど漏れの意見で通っているよ。

すれ違いだが>204補足(なんて親切なもれ)

ソフトウェア開発には、5つの世界がある：
パッケージ
インターナル
組み込み
ゲーム
使い捨て

ttp://japanese.joelonsoftware.com/Articles/FiveWorlds.html

>205
で、よく読んでないけど
>201の仕事はどれにあたるの？

パッケージじゃねえし、組込でもないし、ゲームでもないから
インターナルか使い捨てのどちらかだよな。

>201
業務系はいいよな。ターゲットのOSもひとつに絞れるし
ブラウザもIE5.5以上のみの対応ですとか言えるし
エラーチェックが適当でexceptionおきても「オーダのシステムですから」
とか言ってごまかせるし。
ああ、漏れも業務系に転向しようかな

喪前らどんなUMLモデリングツール使っているの？

もちろん｢エクセル」最強伝説

マジレスすると、UMLは手書きがいい。
柔軟性、拡張性、仕上がりの早さ、どれをとっても手書きに勝るツールは無い。

>211
いえてるかも。漏れはVISIO 2002使っているが
文書化の部分が印刷できないよ。ってツールならばラショナルあたりを
使わないとだめ？

みなさん十把一絡げにUMLとおっしゃってますが"何図"を想定していますか？

静的構造図
シーケンス図
アクティビィティ
コラボレーション
配置
ステートチャート

ユースケース追加

>208
妄想系はいいよな。以下略

再利用とか考えずにコピー＆ペーストで使い回せ。
工程数も大幅にアップすることだし。
ライブラリの再利用性だけに注目していると、そのライブラリの保守性を
維持しなければならなくなり、拡張性を的に絞った開発はもとよりしょぼい
共存性を維持する結果となってしまうことが間違いないからだ。

再利用性を重視する開発は、サードパーティーにライブラリを配布するなど
特にクライアントが居ない限りはなんの役にもたたねぇよ。

えー、コピー＆ペーストって再利用のことでしょ？

>>219
コピペは再利用というようりも古紙再生って感じがするね。マジレスすまん。

>220 古紙再生ならばどっちかってーと移植だろ？(w

再利用を考える奴は、昔、ハードディスクの容量が極限に少ない時代を過ごした
老い耄れかなんかだろうと。

>>222 バカ？

そもそも、コードの再利用を１００％オブジェクト指向に求めること自体が間違っている。
オブジェクト指向とは、常に拡張性を維持させながら進化させるデザインパターンであるのだから。
そのデザインパターンに足枷を嵌めるようなことしてどうなるの？

そう、チョッパリであるならば、コピー＆ペーストの精神を！

>>224
再利用と使い回しを混同してないか？
言葉遊びだと言われればそれまでだが、両者は明確に区別しておいたほうがいいぞ。

UMLの本読んだけど、こんなの一々書くくらいなら
SEがそのままプログラミングできるんじゃないかというくらい
複雑だな。

言葉が間違っていた。
再利用は、１００％自動ではないということ。
スーパークラスは、いじれないと意味がない。

オブジェクティブなコードをオブジェクト指向を知らない奴がいじると、
目も当てられないような酷い状態になる。
この問題、誰か何とかしてくれ。

高度なプロジェクトをプログラミングを知らないSヨが指揮すると、
目も当てられないような酷いデスマになる。
この問題、誰か何とかしてくれ。

　素人には、極力スーパークラスを触らせてはいけない。
　末端クラス以外の設計に手を触れさせてはいけない。

　特に３０歳過ぎた辺りのアタマかちかちの連中には要注意だ。

オブジェクト指向を新人共に覚えさせる為にこんなん考えた。

キャラクタークラスというがあって
そのクラスが、ＨＰ，ＭＰ、経験値、状態、というステータスを
持っていて、
攻撃、防御、逃げる、道具というメソッドを持っている。
これがスーパークラス。

そのキャラクタークラスから派生して、
勇者クラス、戦士クラス、魔法使いクラス
が存在する。

ドラクエでオブジェクト指向を考えてみた。
どうかな？

おお、わかってるやん。
攻撃、防御、逃げる、道具というメソッドは　virtual　で管理するわけだね。

＞ 攻撃、防御、逃げる、道具というメソッドは　virtual　で管理するわけだね。
バカは、ここをタイプ分けして下位クラスにキャストしてから所定のメソッドを呼び出す。

>>232
釣るつもりはないが、スーパークラスに属性として職業を設けてはいけないのか？
勇者や戦士、魔法使いを属性にしてしまえば、わざわざそんなクラス作る必要ないぞ。

さぁこんな質問が来たときどーする。

>>235
その種類を判別させてわざわざタイプ分けする気だろ？
センスのいい奴は、正体を特定させなくとも、
スーパークラスですべてを管理するものさ。

おれなら、そう言い放つ。

どちらにしてもキャラクター管理クラスは必要になりそうかな。
シューティングゲームのような自己管理＋自動消滅型のクラスなんかは
説明が難しいだろうね。

>>235
あながち間違ってないぞ、その考え。
職業が、単なるenumとかじゃなくて、職業クラスをコンポジットで持たせてるならな。
つうかたぶん実際の設計ではそうなるな。場合によるけど。

職業はダーマ神殿いきゃ変えられるんだから交換可能でなければならんよな。
しかしダーマ神殿にいってキャラクタオブジェクトごと変わるってのは可笑しいとは思わんか。
キャラクタは同じだけど、そいつの職業が変わってるだけだ。
キャラクタごと変わっちまったらジョブチェンジじゃなくて人間チェンジだ。
つまり、キャラクタクラスがコンポジット（保持）している職業クラス（のサブクラス）が変わればいいんだよ。
そしてその職業クラスにHPやMP、ちからetcなんぞの補正をかけるインターフェイスを用意したり
あるレベル（とか熟練度とか）を引数に渡すと、覚える技とかを返すようなインターフェイスを定義しておく。
これを、職業クラスから派生させたクラスでオーバーライド。
魔法使いクラスならHP補正は1/2、レベル2でメラを覚える、レベル３でギラ。とか実装。
戦士クラスならHP補正は二倍、レベル5で疾風切りを覚える。とか実装。
キャラクタクラスは、その職業クラス（のサブクラス）のメソッドを呼び出してパラメタに補正をかけるなり、
覚えた技をコレクションしたりするわけだな。
そうすりゃ、ダーマ神殿で転職したら、この職業クラスを切り替えるだけでキャラクタのパラメータが自動的に補正される。
これから覚える技も変わる。（覚えた技はキャラクタクラスがコレクションしてる）

ほら、いつのまにか立派なデザインパターンになったぜ、Strategyパターン！！

そりゃそうだが…。
オブジェクト指向を新人共に覚えさせる為に
ドラクエ実装までしてみせるつもりか？

>>240
うーん、確かに初級者には難しいかもしれんが「継承」の説明じゃなくて「オブジェクト指向」の説明だろ？
正しくない（もしくはより良い解がある）んだったら、難しくても正しいほうを教えるべきだと思うんだよな。
そうやって勘違い（？）して育った奴が結局プロジェクトをめちゃくちゃにするんじゃねえかなあ。
出来る奴は自分で勉強してくるから、言わなくても勝手により良い解を覚えてきてくれると思うけど
普通の奴は教えたことしか出来ない。だったら出来るだけ正しいことを覚えてもらいたいんだけどね。

オブジェクト指向設計/プログラミングを実現する一要素である継承に関する説明としては良いかもしれないが
それでオブジェクト指向の説明にはならないな。

和食の作り方を教えてやる、といって御飯の炊き方だけ教えてるようなもんだ。

否定的な人は長くやってきた手続き型に習熟していて
オブジェクト指向には慣れていないだけじゃないのか。
ここで言われている再利用や設計等についての欠点と、
同様の事がC何かでも言える事が多いと思う。
コボル上がりの人が設計したものは何故と思うような事が多く、
長い間いい加減に拡張し続けられた物は破綻したコードが多い。

クラス設計は完璧である必要なんか無く、
根っこ部分はできるだけシンプルなのがベスト。
変更があればその都度クラス設計やコードを修正しつつ拡張すればいいじゃん。

クラスベースOOだけにクラスチェンジできない。
そこでプロトタイプベースOO

>>242
他の要素で教えないといけないのって何がある？
カプセル化は教えてるとして。

デザインパターンを知ってる != OOを知ってる

かといって OO の理念そのものを教えるのはかなり難しいから、
デザインパターンやMVCモデルとかリファクタリングを教えながら
OOのこころを汲み取ってもらうしかないんだが。

別にC++を使わなくてもCでも関数単位でブラックボックスに
なるように作っていればたいして不便はないと思うが。

>>247
OOの話ができないなら来なくていいよ

ここって>>247みたいな人を説得するスレじゃなかったのか？

正直、伏字かと思ってました→○○

>>249
そうだった、ｽﾏｿﾝ

>>232
俺だったら攻撃だとか逃げるだとかのコマンドも振る舞いクラスにして、
職業クラスをファクトリーにするかな。
こうすると職業固有の動作が可能になるし。

最近マ板でデザパタの用語を連発するカキコが増えたな。
そろそろ俺もやっとかないと時代に取り残されるか・・。

というか、GoFなんかは古典とまでは行かないけど
もはや読んでてあたりまえじゃね？

おまいら、専門用語が全然わからんのですけど、

１． OO オブジェクト指向？（Object ？）
２． GoF （Gang of Four) 意味不明。本の名前らしいが、アマゾンへのリンクきぼんぬ
３． Java言語で学ぶデザインパターン入門 http://www.amazon.co.jp/exec/obidos/ASIN/4797316462/
　　　とりあえずこれ買えばOK? http://www.hyuki.com/dp/
４．オブジェクト指向 ＝ デザインパターン？

おしえてエロい人！

>>255
OO = Object Oriented (多分)

0x101ゲトー

ｴｰ(･∀･)ﾎｻｰ!!

Object Orientation の場合も

OO = Omae Oboeroyo

(´OO｀) ﾌﾞﾋｰ

実装とコーディングの違いはなに？

中身が分からんでも、よそから持ってきてくっつけてはい一丁上がり、
って可能なのが"実装"

実際、今時ぜーんぶコーディングする香具師はアマチュアだけだろ(w

実装の中にコーディングが含まれる。

ちゃんと機能を実現するのが実装。　プログラム書く行為がコーディング。

>>255
2, GoF -- Erich, Richard, Ralph, John の4人。パターンでは有名な連中。
　　　【類】GoF本 -- 「オブジェクト指向における再利用のためのデザインパターン」
　　　　　　GoFパターン -- GoF本に載ってるパターン
4. 厳密にはNo。パターンなしでも OOP は出来る (碌なモノは出来ないかもしれない)。
　　また、OOP でなくてもパターンは存在する。

>>265
さんくすです。
GoF本ってこれのことだったのね。
オブジェクト指向における再利用のためのデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/

うーむ、難しそうだ。買うなら結城さんのJavaのデザパタの本が良さそう。

GoFの23ﾃﾞｻﾞﾊﾟﾀですね。
http://www.hyuki.com/dp/cat_index.html

C++ってオブジェクト指向言語じゃないの？

C++の危険な仕様箇所を取り去ったのがJava
当然オブジェクト指向言語だし、Javaの父母でもある

C++は多重継承が許されているが
Javaは許されていないInterfaceで不完全ながらシミュレートはできるがね

Javaは物真似の猿言語なわけだ

JavaはSTLなどのテンプレートも使えない
お子様向きの業務アプリ言語、VBと同等で糞
VBより悪いのがインタープリタ実行
ガキのおもちゃという位置づけ

安心しました。C++はオブジェクト指向じゃない。JAVAも厳密にはオブジェクト
志向じゃないと強く主張する方がいるのでオブジェクト指向の解説以前の問題で
躓いてます。

>273
そういう話ならば、そう主張する人の言い分も正しいよ
C++の醜い(ANSI Cと共存する)仕様も含めて

オブジェクト指向はけんか腰になれる議論のネタとしては
最高なのだよね。

C++ はオブジェクト指向マクロアセンブラ。

c++もJavaも純OOPLではないぞ

準OOPLはSmallTalkだけ。
関数もオブジェクトマンセー。
型なし言語マンセー。

純OOPLはSmallTalkだけ。 でした。

そういう話はム板でやってくれよ。

やだぴょ〜ん。

C++はオブジェクト指向プログラミングにも対応できる言語

Javaはオブジェクト指向プログラミングがし易い言語

SmallTalkはオブジェクト指向プログラミングしかできない言語

一生懸命オブジェクト指向プログラミングを勉強して、なんとかそのメリットを
理解することができるようになる。
↓
周りの人間が全く理解していないことに気付く。
↓
一人オブジェクト指向がいかに虚しいものであるかを理解しているので啓蒙に走る。
↓
苦労の甲斐なく理解してもらえない。
↓
泣く。

>>283
・・・まあパラダイムシフトは時間がかかるのは歴史が証明しているので。
諦めるか、シフトが進んでいる場所に行くか
の二者択一だとおもわれ

>>283
〜〜啓蒙に走る。
↓
構造体さえ理解していない人間が多いことを知る。
↓
吊る。

　　　　|
　　　　|　　('A`) オブジェクト指向ぐらい理解してる会社に入りたい……
　　　／￣ﾉ( ﾍﾍ￣￣


　　　　|　　　　　　　　　　　1000行ぐらいなら　　　　　 ＼
　　　　|　　( 'A`)　　　　　　関数は作らずに
　　　／￣ﾉ( ﾍﾍ￣￣　　　main に全部書いていいよ ／


　　　　　　　‖　　　　　　　グローバル変数に int i; って書いて ＼
　　　　　　('A`)　　　　　　 色んなループで使いまわすと
　　　　　　（　）　　　　　　　メモリの節約になるよ 　　　　　 　 　 ／
　　　|　　　 | |
　　　|
　　／￣￣￣￣

そういう時代もあったんだよな。メモリが4KBでさｗ

DEFINT A-Z

ノスタルジーオタクはどっか逝け

グローバル変数＝悪なんて覚えてちゃいかんだろう。
理由があってそれをよしとするとこまで理解しなきゃ。

ＯＯがなんで必要なのか誰か教えてくれなかったのか？

だれもグローバル変数＝悪なんて言ってなさげ。

グローバル変数は、悪
ある意味goto誤用よりも悪い
トップクラスの禁止事項だ
完全に禁止すべきだとまでは言わないが

グローバル変数に int i; って書いて
色んなループで使いまわすと
メモリの節約になるよ

この場合、グローバル変数「名」が悪いと言っているのでは？

>>294
これでいいか？

int global_and_dangerous_i;

int 変数;

int BENRI_NA_AI;

関数が再帰したときどうすんだよ ＞ グローバルな i
後々のこと、まるっきり考えてないだろ？

グローバルな i を書くようなお人が
再帰なんて高度なテクニックを使うかな。
存在すら知らない気がするけど。

スタックの概念ぐらい覚えておけよ。
ノイマンがあの世で泣いてるぞ。

main関数１つに全部おさめるにきまってんだろ。

ここは「マ板のPGにC言語を覚えさせたい！」スレに変わりました。

>>302
それは絶対条件ではないのか？

オブジェクト指向を知っていると思い込んでいる奴も
多いような。（漏れも含めて）

いつから再帰が高度なテクニックになったのだ?

超能力者 = サイキック

グローバル変数のフラグをうじゃうじゃつかってる再帰だと、
解析するのに非常に高度なテクニックと根気を要する。
そして、殺意を抑えるのに非常に高度な忍耐力を要する。

えー、忍耐力には高度もなにもありませ〜ん

>>305
昔から。そこいら辺にいるプログラマのレベルを高く見積もりすぎ。

再帰も知らないでプログラマ面する奴はどうもね

新人に再帰を説明したらぽか〜んとしてたのを思い出すなあ

再帰知ってても、再帰ルーチンをforループにしてくれと言われると
未だにちょっと悩むよ。あれだ、未だに植木算が苦手なのに似てる。

再帰先でprintf仕込むと逆向きに表示するからなあ

つーか再帰しないほうがいまどきのＣＰＵは処理が速いような。
コードは綺麗になるけどね。

>>310
プログラマのくせに素人面する奴はもっとね。

5年以上もPGやってる先輩が未だに再帰が理解できてなくて、
再帰処理は分かりにくくなるから使うなと強制してくるんですが、頃して良いですか？

>>316
理解できないのがその先輩だけなら頃して良い。
全体の５割以上が理解できないなら書いてはいけない。
その中間なら教育コストと相談。

俺の会社じゃ、技術を身につけたって発揮できない。
誰も理解できないから。俺は再帰すら書かない。

>>317
それはいくらなんでもネタだろうと思った。

・・・もしかしてマジ？

どんどんオブジェクト指向から離れていきます。
まさに終了条件を決めていない再帰ループのようだ。

再帰ループなら、そろそろグローバル変数に話が戻るんじゃないか？

いや、StackOverflowが先じゃないか？(w

関数型言語やれば再帰など嫌でもわかるようになるぞ

再帰がわかり難いから関数型言語が流行らない。

ベーシックで１０万行を超えるプログラムを書いてたら神。

カプセル化の実践例

作業者の技量がどうあれ
外向きにはSE、PGとして
しかみえない。

>>324
Out of memo（ｒｙ

>>326
CHAINする100単位のプログラムの総合計が10万行ということで

>>325
パブリックに
SetWork
Doit
GetResult
しかありませんでした。本当にSEかな？

オブジェクト指向の厄介なところの例。詳しくしらなくても使えるが全く知らないと使えない。
そもそもそういうクラスがあることを知らないと話にならない。

＞詳しくしらなくても使える

これにつきるべよｗ　まったく知らなくても使える道具はこの世にあんまりないよ。

SetWork
Doit
GetResult
入力、実行、出力に対応させている。
恐ろしいまでに汎用性のあるデザインです。

いまだに最大抽象入力点と最大抽象出力点を引き摺っているのだろか

ゲームじゃ便利なんで使ってるよ。ポーズ時には描画だけ、スキップ時には
処理呼び出しだけやってる。
Win系だと時間で処理したほうがいいけどね。

GetWorkとSetResultを追加しました。

なんでDoitなんだろう。DoItじゃないのかと。

C言語でライブラリ作成中..

データを構造体にまとめてと、
各処理を関数化してと、
おっ、複数ユーザからの利用を考えると
ユーザごとにデータを確保しておく必要
があるなぁ..
よし、データ領域をmallocで確保して、
そのアドレスを関数で参照させるように
して..

クラス？、インスタンス？、サパーリわかんないや。

覚えれば便利なので覚えるんだ！
忙しいなら無理には進めないが。
関数とワークメモリをセットで扱えるだけでも結構便利だよ。

問題は使えない環境に放り込まれた時に耐性がなくなっているとキツイことくらいか。

>>335
クラス＝構造体の定義
インスタンス＝構造体の定義を使って宣言された実体
サパーリ＝これは俺もわからない。

ここでさらにオブジェクトは何とくるわけだ。
本によってはクラスをオブジェクトと呼んでいたり、インスタンスを
オブジェクトと呼んでいたりする。

SmalltalkやRubyみたいなメタクラスの概念がある言語はいいんだけど、
C++でクラスをオブジェクトと呼ぶのは抵抗を感じる。

もうオブジェクトという言葉はＣ＋＋で使われて久しいので諦めてください。
役不足みたいなもんで。

オーバーロード　：オーバーライドさんの人気にはかないませんなぁ。
オーバーライド　：いやいや、お恥ずかしい限りです。
インスタンス　　：まぁ、役立っている度合いが評価に繋がるとは限りませんからな。
インヘリタンス　：失礼だよ君。オブジェクト指向の花形をなんだと思っているんだ。
オーバーロード　：まぁまぁ、おふたりの実力はインスタンスも私もよく理解しているわけで。
インヘリタンス　：オーバーロードさんにはかないませんな。
一同　：わははは・・・オブジェクト指向万歳。

○　　　　　　／￣￣￣￣￣＼
十　―――|　サービス残業　|――― 　＿|￣|○
∧　　　　　　＼＿＿＿＿＿／
PG　　　　　　　　　　　　　　　　　　　　　　　　PG

せつないユースケースだな。。。

>>343
アクターに価値を提供してないぞ。

いや、価値はあるのか・・・

サービス残業プライスレスです。

>>341
確かにオーバーライドは知っていても
オーバーロードという言葉を知らない
人達も少なからずいます。

オーバーロードはオーバー労働を連想さ
せるため、無意識のうちに話題として避
けられる傾向があると私は考えます。
この仮定はユングの集合的無意識を根拠
にしています。

Visual Objective-Cが(　ﾟдﾟ)ﾎｽｨ…。

設計とか仕様を確認することを嫌がり、コーディングが
終わってから関連文書を作成し始めるような連中がＯＯ
をやるからおかしなことになる。

ＯＯは分析・設計が好きなＳＥ・ＰＧのための技術。
考え抜いてから作業を始めるＳＥ・ＰＧのための技術。

オレはデバッガで動かしながら考えたい！

>>338
クラスもインスタンスもオブジェクトの一種ですが。

　　／￣￣⌒＼
　　（　　"　　　　＼　
　｜＿＿＿ノ＼　｜
　　|｜＿　＿　｜｜
　　|｜�V`'�V　｜｜
　　　(　　し　ノ｜　}
　　　＼　Д ｜|＼|
　_　　　|` ＿ノ／|
　!!　／　＼|＿／ ⌒＼
　|ベ　　　 |
　＼)⌒|　 |。
　｜‖｜　|　　考えるな、感じるんだ！
　｜‖｜　|。

>>348
動かしてみて良し悪しを判断するのは簡単だ。
理由後付けだ。

分析・設計フェーズで如何に製作フェーズ、
運用・保守のことを予測できているかが重要
なわけだ。まぁ、そんなことは誰もが認識し
ていることだ。
それでも一日中IDEばっかり触っている連中が
多いのはＰＧの皮をかぶったコーダーが存外
多いということなんだろう。

　我々は良い設計でないクラスの継承は
　一切、お断りいたします。
　　＿＿＿　　　　　＿＿＿　
　/　-<　-　＼　　/　-<　-　＼　　　
　|　　コ　　　|　　|　　　コ　　　|
⌒　　　　　　⌒／　　　　
　VB　5.0　　　　　　VB　6.0

うちじゃ誰もｵﾌﾞｼﾞｪｸﾄ指向できない（というより異様に毛嫌いしてる）から
実質OOP禁止です。
VBなんかなまじﾌｫｰﾑ部分がOO（っていうには制限多いが）だから、
OOと手続き型がいりまじってかえってわかりにくいyo
あれなら、全部CでAPI叩いた方がまだわかりやすい。
早くﾄﾞﾄﾈﾄになってほしい。

みんなは自分が「正しい」ＯＯＰの何割を実践してるとか、どうやって
実感してる？
俺は「まあこんなもんだろう」という実感しかないが…

>>353

サポート切れまでよろしくお願いします。
　　＿＿＿　　　
　/　-<　-　＼　　　
　|　　コ　　　|
／　　　　　　＼
　　VB　6.0

>>354

要件定義、外部設計でユースケース図、シーケンス図、
クラス図（publicなメンバのみ）使って作業している
とＯＯだと実感する。
コーディングのレベルだとあまり実感はないな。

>>355
ゲ製板のペイピッポゥ並にひどいＡＡだな。

>356
どういうダイアグラムを描いてるかによるな

俺はＡＰそのものではなく、ＡＰ開発者に使ってもらう部品を
作っている。

ユースケース図は業務の概要を描いた落書きレベル。
シーケンス図にはクラスとして作るもの以外も記述している。
オペレータとか画面と入力装置とかだ。
だから、PGが想像するようなシーケンス図ではない。あくま
でも客に説明し、提供機能部分を明確にするための図だ。
基本的に客はUML知らない。

クラス図は部品を提供する立場上、クラス名、プロパティ名、
メソッド名とメソッドのパラメータを完全に提示する。pirvate
なメンバは提示しない。ちなみに開発言語はC#だ。

で、外部設計完了となる。実感としてＯＯは機能とプログラム
の対応付けが旧来の手法（ＤＦＤとか）に比べてやりやすい。
まぁ、バッチＪＯＢとか作る場合はあまり効果ないわけだが。
内部設計では各ＰＧにＵＭＬに従ったクラス図とシーケンス図
を書くようにしてもらっている。メソッドからのリターンの矢印が
破線でなかったら詰問だ。

>>359
veryにgoodな手法だ。

>>37
> オブジェクト指向のメリットって何？
> ぐぐっても難しい言葉ばかりでさっぱりわからない。
> IF文減らせるだけだと思うのだがどう？
> 開発効率なんか上がらないし、ソースはわかり辛いし、継承しまくりで
> どこがわかりやすいのかわからん。

「継承しまくり」というのはオブジェクト指向をわかったつもりになって実際にわかってない人が
やるありがちなパターンですなあ。

オブジェクト指向を駆使して開発効率を高めるには数多くのデザインパターンを知り、
実際に使ってみることです。
使えば、使うほど、スキルアップし熟練したオブジェクト指向プログラマになれます。






しかし、マ板でここまでオブジェクト指向を知らない人がこんなにいることには驚いた…………

>>361
君はオブジェクト指向についてよく理解してるつもりらしいから聞くけど、
昔ながらの構造化分析手法に対するオブジェクト指向分析手法の
メリット・デメリットについて説明してくれ

簡単にいうと
構造化手法のデメリットはモジュール間の結合力が密になりやすいということかな。
ポリもーフィズムをうまくつかうことで結合力を疎にすることができるのがオブジェクト指向開発の利点。
しかし二つのクラスを継承関係で結んだだけでは逆に結合力が密になりやすい。
そこでどうするかというと今のポリモーフィスムを使って
ある二つのクラスをもう一つの抽象的なモジュール(抽象クラス)のサブクラスにすることで
その二つのクラスの関係が以前よりも疎になるというわけだ。
詳しいことでOpen Closed Principleで検索してみておくれ。

デメリットはだな(w
なんだろうなｗ
おれにとってはメリットのほうが大きいからなw

○オブジェクト指向を知らないといけない。
○慣れるまで時間がかかる。
○慣れていないと納期にますます遅れる。
○周りがオブジェクト指向を知らない、否定的、懐疑的だと一苦労する。
○小規模開発ではコード量が余分に増えることがほどんどである。
○使い捨てプログラムを作るには勿体ないことがある。
○開発が小規模であればあるほど逆効果となることが多い。
○一度作ってしまったものをオブジェクト指向に書き直すのに手間がかかる。
○オブジェクトの生成にはヒープ領域を使うのでオブジェクトを大量生産するとメモリを大量消費する。
○オブジェクトをループで何万回も新規作成するとその分だけオーバーヘッドがかかる。

だろうなw
メリット・デメリットはこれだけじゃないがw

サルゴリズムも知りません

オブジェクト指向だと、あちこちに飛ぶからわかりにくいという
意見があるけどそれはどうなんだろう？
オブジェクト指向プログラミングでその意見、聞き入れたら
アクセサメソッド使わないでフィールドをpublicにしたり、
やたら長いメソッドを作るハメになるわけだが。

＞アクセサメソッド使わないでフィールドをpublicにしたり、
＞やたら長いメソッドを作るハメになるわけだが。
どういう理屈でこうなるんだ？つーか、やたら長いメソッドって何？

＞あちこちに飛ぶからわかりにくい
これは多分クラス設計の時点で間違ってる。

あるフォーマットのファイルを印刷するクラスがあって、
ファイルを読む、編集する、印字する
という3つのメソッドがあったとして、それが更に、
"ファイルを読む"が、"ファイルを開く"、"ファイルのデータをメモリに読む"
とかいう風に分かれてたのを、あちこちに飛んで分からんから纏めろと。
纏めた結果、"ファイルを開いてメモリに読みこんで、編集のために1文字読んで括弧を付けて
2文字読んで括弧を閉じて．．．印字する"というやたら長いメソッドに。
で、setとかgetがめんどいから、publicで直接アクセス。

つか、最初からオブジェクト指向ではないだろ。

>>369
メソッド云々以前にそのクラスは大きすぎる。

>>370
後で、フォーマット、ファイル、印刷くらいに分けたほうが良いと思ったが、
めんどくなった。

>>366
あちこちに飛ぶから分かりにくいを勘違いしてないか？
継承が多くて、どのメソッドが呼ばれるか分かりにくいならあるが。
SetやGetがめんどいって設計まずくて多すぎるだけじゃ？
場合によって、protectedにして派生して直アクセスでもいいだろうし。
ただ、他人が設計したコードは、オブジェクト指向の方が分かりにくいのは、
そうだと思うが、まあ、Ｃでも同等の事をしようとすると、分かりにくくなるが。
設計が優れている＝分かりやすい、じゃないからな。

>>345
>オーバーロードはオーバー労働を連想さ
>せるため、無意識のうちに話題として避
>けられる傾向があると私は考えます。

コピペ？
禿藁

>>369

そのメソッドを仮にOpenとするならば、

　Open(StreamReader &BaseStrem ) ;

class FileReader : public StreamReader

class FileStreamReader : public StreaReader

class MemoryReader : public SreamReader

のようにして、すべて下位レベルの処理に回せ。

オレもアイツもオーバーロード

講師「それではオブジェクト指向の講義をはじめます」
生徒「オブジェクト指向ではネコが爪を持つとか、犬が哺乳類だとか意味不明なこといいますね」
講師「うむ、それは has-a と is-a のことですね」
生徒「なんですかそれは、僕にわかるように教えてください」
講師「ＡさんのバグとＡさんがバグは違うということだよ」
生徒「なるほど全てを理解しました」


開発チームをシステム開発のための製品とみなした場合、
製品のバグは事前に取り除かなければならない。
―オブジェクト指向は現実世界を我々に教えてくれる。

チェーンジ ゲッター！！

オブジェクト　オーバーライド！

>>366
> オブジェクト指向だと、あちこちに飛ぶからわかりにくいという
> 意見があるけどそれはどうなんだろう？
IDE使ってるか？　いやIDEの替わりにビルドツールでもいい。
GNU make とかApache Antとかを使ってその問題を解消するんだよ。

達人プログラマというのはプログラミングを自動化することに長けているんだよ。
ビルドツールで自動化くらいせい。

>>369
とりあえずJavaをやってみることをお勧めする。
java.ioパッケージをよく見てみるといい。
GoFデザインパターンの一つ、Decoratorパターンが適用されている。

import java.io.File;
import java.io.FileImputStream;
import java.io.InputStreamReader;
import java.io.BufferedReader;
import java.nio.charset.Charset;

/////略

Charset encoding = Charset.forName("UTF-8");
File file = new File("/usr/local/tomcat/conf/server.xml");

FileImputStream fis = new FileImputStream(file, encoding);
InputStreamReader isr = new ImputStreamReader(fis);
BufferedReader br = new BufferedReader(isr);

while(reader.readLine() != null){
//略
}

中央部分は、こんな書き方もできる。

FileImputStream fis = new FileImputStream(file, encoding);
InputStreamReader isr = new ImputStreamReader(fis);
BufferedReader br = new BufferedReader(
　new ImputStreamReader(
　　new FileImputStream(
　　　new File("/usr/local/tomcat/conf/server.xml"), Charset.forName("UTF-8")
　　);
　);
);

ちょっとしたI/O処理記述するのにストリーム多すぎ・・

セッターゲッターロボ発進！！

public class Robot
{
public void setName(string name){}
public string getName(){}
public void setAddress(string address){}
public string getAddress(){}
・・・＜省略＞
}

○○なんてポリモ覚えたらそれで終わり。セタゲタ、カプセルなんて不要。

詳しいことは知らないがだれかがWebSphere用にパッチつくってないのか？

>>382
ちょっとした事でも細部まで分解することに意味があるのだ。

>>384
それだけ(setter,getter,カプセルだけ)では足りんぞ。
デザインパターンをきっかりと習得することだ

>>382
目的によるよ。
これはあくまで一例。
これがいやなら短縮コマンドみたいに関数を自作すればいい。
Jakarta Commonsにも似たようなものがあったが

デザパタを「きっかりと習得する」ってのはむずいな。
そもそも、デザパタ自体が設計能力無い人間に対して
出来る奴がよい構造を教えてやるぞって意味合がつよいからな。

デザパタよりよい構造を思いついたけど（実際にそんなこと殆ど無いが）、
そのよさをデザパタ厨房に潰されるっていう危険性だって孕んでる。

デザパタ厨房の意味が分からない。
互換性の無いM$独自仕様みたいに独自用語つくるなといいたい。

とりあえずデザインパターンを気安くデザパタと略す奴は
ゲイツのケツの穴でも舐めてさっさと死んで欲しい。

>>387
日本語勉強しようね

デザインパターンだって、独自用語だろ。
イテレーターパターンだって、別にそうと気づかずに使ってたりするだろ。
DelphiのTListみたいに。
オブジェクト指向言語なのに独自の用語を作られるのは確かに困るが。

>>390
「お前の作ったアルゴリズムのほうが早いのかもしれないが
　こういう場合はデザインパターンこれこれを使うべきだ。
　Gof本にも載ってる！これ最強！間違いない！」
とかいって、わざわざ保守性と効率を下げて満足する奴もいるんだよ。
それがデザパタ厨房な。

FileImputStream ってナニ？ 英語勉強しようね。

細けぇよ、馬鹿。どうせIDEで補完すんだから。

>394 A型
>395 B型

>396 AB型

>>393
なんかデザパタの本を読むとどれもこれからの標準とか業界スタンダードなんて言ってるが
実際には全然普及していないから彼らの言うことはどの会議でも「ふーん」状態で放置されてる。

なんと。デザパタって普及してないのか。

デザインパターンは奇麗事だからな。
実際の業務開発の設計とシンクロするような本があればもっと普及するかもね。
OOの動物園の例と同じという事かな。
わんわんにゃんにゃんでなぜOOが理解できるのだ

デザインパターンが実際に使えないという人っているね。
抽象的な思考の苦手な人は案外多い。

実はデザインパターンは108ある

使えないと言うか使う機会がない。
デザ-んパターンが使える所は汎用的なライブラリを作るとき。
多くの場合ライブラリは使うだけですむので使う機会がない。

だから業務系にはデザパタなんて必要ないんだって
アンチパターンだけしっかり押さえといて

オブジェクト指向言語を取り入れられるかどうかも分からない
組み込み系、携帯電話系、ゲーム系もデザパタ使いようがないですね。

>403
という事は、末端業務系コーダ君は「いつまでも知らない」
「知る必要もない」でいいですか

>>406
違います。曲解せずに素直に文章を読み取りましょうね。低脳君。

>>397
当たり！！！

>多くの場合ライブラリは使うだけですむので
こりゃコーダの台詞としか思えないんだが。

>>405
ゲームも取り入れられるけど、規模はそれほどでもないからね。

>>409
そういう意味じゃなくて、ライブラリを使うときに
そのライブラリの振る舞いを知らんとならんだろ？

デザインパターンに沿った設計が出来る必要はないが
ライブラリがどのような設計で動作するかは知っている必要がある。

コーダーも、コピペとか条件反射でコード組まれても困るわけよ

>>393
> デザインパターンだって、独自用語だろ。
> イテレーターパターンだって、別にそうと気づかずに使ってたりするだろ。
> DelphiのTListみたいに。
> オブジェクト指向言語なのに独自の用語を作られるのは確かに困るが。
どこでDelphiを持ち出すのはセンスが悪いな。
独自の用語を出したがるのはオブジェクト指向を使ったつもりになっているM$みたいな企業のことをいう。


> >>390
> 「お前の作ったアルゴリズムのほうが早いのかもしれないが
> 　こういう場合はデザインパターンこれこれを使うべきだ。
> 　Gof本にも載ってる！これ最強！間違いない！」
> とかいって、わざわざ保守性と効率を下げて満足する奴もいるんだよ。
> それがデザパタ厨房な。

そんな奴はお前の脳内にしかいないよ。2chやりすぎて頭がおかしくなってノイローゼにでもなったんじゃねえのか？

>>398
> >>393
> なんかデザパタの本を読むとどれもこれからの標準とか業界スタンダードなんて言ってるが
> 実際には全然普及していないから彼らの言うことはどの会議でも「ふーん」状態で放置されてる。

だからデザインパターンをデザパタと気安く言ったら殺すぞ。
高度なソフトウェア開発もできない愚か者が何を言うか。
普及していないのは日本だけだ。日本人がアメリカ人と比べバカだから普及しないんだよ。

ソフトウェア開発ってものを力押しだけですませればいいと考えてなめてかかっている日本人が多いから
日本ではオブジェクト指向もデザインパターンも普及せずソフトウェア管理品質が低下しCMMレベルも低下している
という無様な実態をそこにあるのだ！

>>400
> デザインパターンは奇麗事だからな。
愚か者よ。ろくに使いこなせていない、いやそれどころか触りしか知らないから
そのような勝手な偏見を持ち出す結果を生み出す。
デザインパターンというのは綺麗事ではない！
デザインパターンとは経験則の集合体だ！
これを標本テンプレートとして新たにソフトを開発していくのだ！

>>402
> 実はデザインパターンは108ある
>
たったの108しかないわけないだろう。
デザインパターンは星の数のように無数にある。
お前もなにか新しいパターンを編み出せ。

そしてデザインパターンを超越したアーキテクチャーパターンを編み出せ！

>>403
> 使えないと言うか使う機会がない。
> デザ-んパターンが使える所は汎用的なライブラリを作るとき。
> 多くの場合ライブラリは使うだけですむので使う機会がない。

積極的に使おうとしないからなかなか使えないんだぞ。
デザインパターンを使いこなすには想像力が必要だ。
とにかく右脳を積極的に使わなければデザインパターンはうまく使いこなせない。
とにかく空間思考が必要だ。立体的に物事を考えられるものがデザインパターンを使いこなすことができる。

>>410
ゲームは速度にこだわるからデザインパターンを使うことを拒否する傾向にある。

>>411
> >>409
> そういう意味じゃなくて、ライブラリを使うときに
> そのライブラリの振る舞いを知らんとならんだろ？
> デザインパターンに沿った設計が出来る必要はないが
> ライブラリがどのような設計で動作するかは知っている必要がある。


そのライブラリとやらがApache HTTPd Serverのように十分にテストされ信頼と実績の
あるものなら振る舞いを細かく知る必要はない。
知るだけ時間の無駄だ。知るなら短時間で知るべきだ。
そのためには

お前はライブラリを使って済ますだけの短いプログラムしか書けないことは容易に想像が付く。
デザインパターン、オブジェクト指向なしでライブラリを使ったライブラリを作ることがどれだけ大変なことかを
お前はまだ知らない。これからの時代はライブラリではなくフレームワークの時代だ。
フレームワークというものをお前が目の当たりにしたとき、デザインパターンの話題にライブラリという言葉を
易々と使うことを恥じるだろう。

デザパタデザパタうるさい奴は厨ばっかだし、
デザパタ拒否する石頭な老害連中も邪魔

>>416
オブジェクト指向設計&デザパタ適用に必要なのは「仮説」と「検証」だ。
想像力が無くても、空間発想が乏しくてもデザパタは使いこなす事が出来る。

>>417
>ゲームは速度にこだわるからデザインパターンを使うことを拒否する傾向にある。
OOPが出来ない（やりにくい）言語を使っているケースが多いからでは？
そもそも、OOPやデザパタを導入して速度が遅くなるようなアプリケーション（の大部分）は
適用方法が間違っている。

>>418
1)俺は堂々とライブラリの話を出すが、何も恥じる事は無いと思う。
2)例えば社内で実績のあるライブラリの適用時に、振る舞いは知らなくて大丈夫か？
3)後、文章が良くわからん。何が言いたいのか？

と、否定意見を並べてみる。

とりあえず、独自のデザインパターンを考えた。

【引篭もりパターン】
　クラスすべてのメンバをprivateにする。

>>420
ゲームシェアの何パーセントがゲームボーイか忘れたが、気軽にＣ＋＋で
記述できるようなハードではないよ。まあ使ってるけど。（ワラ

シーン切り替え以外の部分で気軽にメモリの取得解放をバンバン行ったり
はやっぱやめておきたいもんであるよ。

といってもＰＳ２クラスならほとんど気にならんか。

>>420
> >>416
> オブジェクト指向設計&デザパタ適用に必要なのは「仮説」と「検証」だ。
> 想像力が無くても、空間発想が乏しくてもデザパタは使いこなす事が出来る。
>
> >>417
> >ゲームは速度にこだわるからデザインパターンを使うことを拒否する傾向にある。
> OOPが出来ない（やりにくい）言語を使っているケースが多いからでは？
プレステ2のビデオメモリはたったの4MBしかないからオブジェクト指向どころでは無いというケースが多いんだそうだ。

> そもそも、OOPやデザパタを導入して速度が遅くなるようなアプリケーション（の大部分）は
> 適用方法が間違っている。
パフォーマンスを改善することができるデザインパターン、ProxyパターンだとかFlyWeightパターンだとかの話が出てきそうだな。

>>420

> 1)俺は堂々とライブラリの話を出すが、何も恥じる事は無いと思う。
フレームワークとの区別もつけて貰わないと話が合わない。
オブジェクト指向が関与する話ではオブジェクト指向をしっかりと勉強してくれないと
まともにコミュニケーションとれないぞ。

> 2)例えば社内で実績のあるライブラリの適用時に、振る舞いは知らなくて大丈夫か？
詳細を全て知る必要はない。何度も更新したテストケースクラスでテストし、
より多くの者が使い、何度もバグが改善されているものならすべてを知る必要はない。
自動車の機械工学的な構造、エンジンの詳細な仕組みを知らなくても運転免許さえ取れば
自動車を運転できるのと同じだ。自動車はなんどもテスト走行をしてから売り出されている。
信頼度はかなり高い。特に、こういったものがさらにオープンソースであればさらに信頼性は高くなるものだ。

ここでは「ライブラリ」という用語よりも「フレームワーク」という用語のほうが適切なので「フレームワーク」という用語を
使わせて貰う。
むしろフレームワークを作る側が、詳細全てを知らなくても即座に適用できるように設計することが重要だ。
それオブジェクト指向のなせる技だ。オブジェクト指向だからこそ、詳細を知らなくても即座に適用しやすい
フレームワークを作ることができる。

>むしろフレームワークを作る側が、詳細全てを知らなくても即座に適用できるように設計することが重要だ。
メソッド仕様(IF)の縛りぐらいしかできないよな、それじゃあ

フレームワークだけがあって、サンプルコードとドキュメントが不在だと、




死にたくなる。

>426 多分えらそうな >424が作るUML設計もそんなもんな気がするな

>>426
> フレームワークだけがあって、サンプルコードとドキュメントが不在だと、
ドキュメントはソースコードと一体化している。

先にバグだらけの糞サンプルコード書いてからUML変換しているだけかよ

先にUML書いてからソースコードかくんだよ。

そしてまたUMLを書く、そしてソースコードをかく

これの繰り返しだ。

とにかく反復型開発だ

なんか、>>393の定義するところのデザパタ厨房が荒れ狂っているようにしか見えない…。

リンゴとカレーがある
→食べる→うんこになる　オブジェクト思考

おまいらフリーソフト作家のサンデープログラマならOOPやり放題ですよ。


フリーソフト作家なのでお金ないのでフリーできれいにUML書けるソフトきぼんぬ。

>>418
俺はStruts使った大規模システムの開発行ってるんだけど、
フレームワークでもライブラリ使うだろ？
第一、フレームワークを利用するときもフレームワークの位置づけ、
振る舞いの概要も（細かく知る必要はないが）重要じゃないか？

デザインパターン使ったライブラリを作ったことなどないが
有名なパターンは知ってるし、勉強もしている。
たとえコーダーでもこの辺の理解はないよりもあるほうが絶対いい。
どのパッタンのメソッド利用すればよいか、最適の選択が出来るからね。

フレームワークの時代というが、俺はフレームワーク大嫌い。
覚えるのめんどい。

>>433
> おまいらフリーソフト作家のサンデープログラマならOOPやり放題ですよ。
>
>
> フリーソフト作家なのでお金ないのでフリーできれいにUML書けるソフトきぼんぬ。

オープンソースIDE Eclipse 上で動く Omodoプラグインを使用することをお勧めする。
綺麗にかけるぞ。


Eclipse
http://www.eclipse.org/

Omondo(EclipseUML)
http://www.omondo.com/

>>433
これなんかどうだ？
Javaだがクラス設計にはそれなりに使えるとおもう。

http://objectclub.esm.co.jp/Jude/jude.html

>>434
いくつかのデザインパターン、アーキテクチャパターンを
理解すればフレームワークなんて覚えるのも面倒くさくもないだろう。

しかも一端覚えてしまえば楽勝だ。

>>435
そっちもなかなかいいらしいね。Java⇔UMLが相互にいけたんだっけ？

フレームワークは一端覚えてしまえばなんども再利用できる。
それがフレームワークの魅力だ。

>>438
> >>435
> そっちもなかなかいいらしいね。Java⇔UMLが相互にいけたんだっけ？
いとも簡単にいける。クラス図を更新するとソースコードとシンクロしてているため
見事にソースコードも更新される。

>>435
>>436
ありがとうです。見てみます。

どうせこうせそんなもの機械にやらせんか?

Strutsに限定して言わせてもらえばまずXMLとJSPが果てしなく鬱陶しい。
あんなにソースコードを美しく書けない（奴が多い）言語を採用するなといいたい。

フレームワークレベルではオブジェクト指向になっているかもしれんが
一貫された書式じゃないファイル群の編集は本当につらい。

Struts覚えたらSpringもいけるってわけじゃないだろ？
別フレームワーク採用になったらやっぱり覚えないとならん。
Java&Servlet&JSP覚えたのにStruts、Spring、AspectJと
フレームワークや流行ばっかり追ってると、なんか馬鹿馬鹿しい気がしてくる。

これぐらいのモン覚えれなくてどうするって意見は分かるし覚えるつもりだが。

>>443
> Strutsに限定して言わせてもらえばまずXMLとJSPが果てしなく鬱陶しい。

JSPのスクリプトレット<% %>を極力減らし綺麗にしようとしたのがStrutsだろう。


> あんなにソースコードを美しく書けない（奴が多い）言語を採用するなといいたい。
JSPやCをやりすぎた香具師がJavaをやり始めるとそうなるんだがな。
Eclipseのコードフォーマッタがあればかなり綺麗になる。

> フレームワークレベルではオブジェクト指向になっているかもしれんが
> 一貫された書式じゃないファイル群の編集は本当につらい。

struts-config.xmlファイルとかは新しいバージョンからはほとんど編集する必要が無くなったぞ。
それとツールを積極的に使え。デプロイツールたるAnt用build.xmlとか。
Strutsをマウスで簡単に設計できるCaminoというツールもある。
EclipseのStrutsプラグインを使うのもよしだ。

それとWebデザイナにとってはVelocityが魅力的だ。

ついつい人に

語りたくなる...
説教してみたくなる...

これがオブジェクト指向の真髄。

>>444
> Struts覚えたらSpringもいけるってわけじゃないだろ？
それはそうだが、「覚える」ということを意識しすぎじゃないだろうか。
覚えなくてもいいことまで覚えようとしていないか？
仕事中に解らないことがあったらリファレンスを引く、という手順を踏めばいいだけなんだよ。

> 別フレームワーク採用になったらやっぱり覚えないとならん。
> Java&Servlet&JSP覚えたのにStruts、Spring、AspectJと
> フレームワークや流行ばっかり追ってると、なんか馬鹿馬鹿しい気がしてくる。

それぞれには何かしら共通点があるがな。
GoFのデザインパターンを知っていればそれらを把握するのも難しくないと思うが。
それと、AspectJはちょっと畑が違うものじゃないか？

>>446
なにせ、オブジェクト指向は哲学から生まれたソフトウェアという科学だから。

プラトンが考えただけのことはある。

さあさあ人に

語ってみよう...
説教してみよう...

これぞオブジェクト指向の真髄。

オブジェクト指向は一見難しそうに見えるが
デザインパターンの本を読めば以外と理解が早まる。

それと、他人のソースコードを積極的に読むこと。
それによってスキルはあがる。

よく、
「他人のコードばかりよんでいると真似してばかりで
自分でコーディングしようとせずスキルアップにつながらない。」
などという大学教授がいるがそれはもはや時代遅れな考え方である。

その大学教授がオープンソースというものをよく知っていれば
そんな馬鹿げた発言もしないだろう。

オープンソースは魔法の粉。
奥方の浮気にだって効きますぜっ!!
by IBM(w

イデア論かい・・・
新しいパラダイムとギリシャ哲学の一つとの共通点を掲げることは、今まで何度も目撃したけどな。
共通点が存在したとしてもギリシャ哲学に源流があることの証明にはならないだろうに。
スレテーマから乖離していないか？

>> Strutsに限定して言わせてもらえばまずXMLとJSPが果てしなく鬱陶しい。
>JSPのスクリプトレット<% %>を極力減らし綺麗にしようとしたのがStrutsだろう。

それはそうなんだが、その思想に基づいてタグライブラリオンリーで書こうとすると
えらい状態になってしまうことが多いと思う。
こんなに可読性が下がるなら素直に<% %>でいいじゃんって感じに。
デザイナーがJSPに携わる敷居を低くするための処置なんだろうが、
正直あれではデザイナーには理解できなさそうだ。

しかし、新バージョン、ツールの情報は役に立ちそうだ。
調べてみるよ。ありがぽん！>>445

>>453
> >> Strutsに限定して言わせてもらえばまずXMLとJSPが果てしなく鬱陶しい。
> >JSPのスクリプトレット<% %>を極力減らし綺麗にしようとしたのがStrutsだろう。
>
> それはそうなんだが、その思想に基づいてタグライブラリオンリーで書こうとすると
> えらい状態になってしまうことが多いと思う。
そりゃデザイナが嫌がるだろうな。それだからJakarta Velocityというものが登場したんだろう。
Velocityを使うことで混乱も避けられる。

> こんなに可読性が下がるなら素直に<% %>でいいじゃんって感じに。
俺はそれで散々嫌なめにあっているんだ。タグの階層構造が10〜20段になっている
JSPコードというものを見たことがあるか？
デザイナによってテーブルタブが何十にもなっているところへスクリプトレットを
埋め込んでn重のfor文で埋め尽くすんだぞ。


> デザイナーがJSPに携わる敷居を低くするための処置なんだろうが、
> 正直あれではデザイナーには理解できなさそうだ。

いやむしろApache Strutsはデザイナの負担を逆に増やしてしまうものだが。
Strutsは技術者の負担を減らすためにあるものだよ。
そこでデザイナを助けるためにApache Strutsに対抗して作られたものがJakarta Tapestryだ。
しかしタペストリーはプログラマには当然人気がない。

これも参考に。


△△さらにStrutsの良さを教えて下さいSession3
http://pc5.2ch.net/test/read.cgi/tech/1088870989/


フレームワークStrutsをいじくり倒す人の為のスレ
http://pc5.2ch.net/test/read.cgi/php/1051485280/

Tapestryについて語ろうよ！
http://pc5.2ch.net/test/read.cgi/tech/1067531714/

>>417
ゲーム開発にもパターンは使われているよ。

例えばタスク。ゲーム特有のパターンだね。

>>422
GB開発はやった事無いからよく分らない(汗
スペックは調べたが、難しそうだな･･･。

>>423
PS2のビデオメモリは4MBだけどメインメモリは32MBあるし。
そのうちの大部分はビデオメモリの不足分を補うとしても、OOP化した事による
メモリ使用増加分ぐらいまかなえないか？逆に管理しやすくなって減るとかない？（自分がそうだった）
まあ実機で開発した事無いから、はずれているかも知れないけど。
FlyWeightパターンはメモリのフレーム管理に使用してます。

>>424
自動車に乗るのは顧客であって、俺らは自動車を作らなきゃいけないわけだが・・・。
まあ、話題は「フレームワーク(以下FW)は、使う側が詳細を知らなくても使えるような設計でなければいけないか？」
という事であって、これには自分も賛成だ。が、それの振る舞い（動作）に関して知らなくても良いと言う考えには反対だ。
と言うのも>>424の言う事は理想論だからだ。現実には開発者が作っているものの振る舞いを知らない事は障害の元だし、
当然テスト事項も漏れるし、設計側に問題を指摘する事も出来ない。そもそもモラルが無い。
しかし、FWは意味が広すぎて混乱する。>>424が言いたいのはStrutsなどのアプリケーションレベルでの話なんだろうか。

OOPは知っていなければならない約束事を減らすためのものだと考えれば
おのずと道が開けてくると思うが。

それを理解せずに使おうとするから遠回りになる。

>>457
PS2だと余裕でOOできるよ。
Flyweightの考え方は普通に使っているが、GoFの実装方法は
無駄ありすぎなんで使わないな。
意外に使える局面は少なくて、結局、普通に持った方が効率が
良いってことになる。ただ、ゲームによっては変わってくるだろうけど。
フレームワークに関しては、後半の保守という意味で自分で設計して、
自分で使って、他のプログラマーに強要させてる。
他のプログラマーは良い迷惑だろうけど。

フレームワークの中身を知らなくて良いなんてありえないんだが。
今時はそうなん？
趣味とか簡単な仕事ならそれでいいと思うけど。

フレームワークの中身は使いながら徐々に中身を知っていけばいい。
新聞を読むときにすべての記事を隅から隅まで読む必要はない。
まずは一面見出しから読んでいくはずだ。

テストもされてない、信頼も実績もないものやよほどの設計が悪いものでない限り
初めのうちはおおざっぱな外観だけを理解すればいい。

辞書にしてもそうだ。辞書を全部読む必要はない。必要なときにだけ必要な事項を参照して読めばいい。

選挙の日に投稿するとこうなるのか。
これから行くところだが。
　

愚民は寝てなさい

>>461
はじめから全部知るなんてそもそも無理だろ。
何、当たり前のこと書いてんだ。

>>464
フレームワークを覚えるのが面倒くさいっていう香具師がいるから説明しただけなのに

>>461にとっては大発見なので、そういうことを言わないでください。

いっている意味がわからない。
日本語しゃべってる？ >>461

間違えた。


いっている意味がわからない
日本語しゃべってる？ >>466

なんかオブジェクト指向を語ってるﾔｼってなんか概念的なのばっかで、具体的なソフト名で、
「このソフトはオブジェクト指向でデザインパターンを使って効率よく開発されてまーす！」
てな、サンプルを出して欲しいのだが。

>>469
http://jakarta.apache.org/

>>466 は >>464宛てだろ。

>>469
それが出てきたとして、一体何が判ると？

LinuxのカーネルとかOOPバリバリじゃない？

>>470
さんくす。
英語苦手なので出来れば日本語の例をきぼん。

オブジェクト指向が絵に書いた餅じゃない、と分かって勉強してみようかという気になるので。
結城さんのJavaのデザパタの本を買ってみたがｻﾊﾟｰﾘだったので。

後ろ2行は>>472宛のレスね。一応。

「UMLモデリングの本質」って日経から出てる本はオブジェクト指向を勉強するのに
よさそうな気がするよ。図書館の貸し出しシステムとか、駅の改札システムみたいなのを例題に
概念レベルでモデル化をする方法や考え方なんかが解説されてて。

>>476
他から出てたらいい本だったかもな。

もまえら、
ttp://images-jp.amazon.com/images/P/4797323361.09.LZZZZZZZ.jpg
これ最強。まじで。ちと高いが。

>>478
本屋で見かけたんで衝動買いして今読んでる。
ど素人が読む一冊目としては勧められないが、かなりいいね。
ただ奥義ってアホっぽいタイトルは何とかしてほしかった。

巻物にして欲しかったな

「オブジェクト指向がわかる本」　佐藤英人著　オーム社

とりあえず知りたかったので一番薄くて安い本を探した。もぐらたたきゲームを作るところで
ありがちな失敗例なども紹介されていてわかりやすい。Javaの知識があった方がいいが、
なくても問題なし。

オブジェクト指向を理解するならJavaを直接勉強するのもベストな選択に一つだぞ。

熟練者から見ては内容の少なさに気になる者だが
「独習Java」でもオブジェクト指向は十分理解できる。なによりも実践によって理解できる本だから。

プログラマーなら息をするのと同じように、オブジェクト指向を
理解出来てるでしょうに。
今更こんなスレ必要ないよ。

OOPはOOの一側面にしか過ぎないという認識は間違い？
「群盲象を評す」という錯誤のレスが沢山あるように思えて仕方がないのだが

オブジェクト指向は現実世界をモデル化するそうだ。つまり、現実世界が理解できないと使えないわけだ。
業務フローや客を無視してコンピュータの技術論を展開したがるPG達には縁の無いはなしってことさ。

所詮プログラム構築のための手段なんで。
いまのヘボいＣＰＵじゃロクな現実も再現できんよ。

オブジェクト指向は難しい、って言われてます。
ttp://plan9.aichi-u.ac.jp/programming.html
の、下の辺り。

おまいらの見解はどうですか。

>>487
継承（特に多重継承）ベースでのクラス設計はよろしくない。
オブジェクトコンポジションを使いましょう。
といっているように思えるが。

>第三版になって Alef が廃止された。残念がる声が多いが、全ての CPU に対してライブラリをサポートするのが大変なのだそうだ。
駄目じゃん

オブジェクト指向、って最初から作るものの大体のイメージを作れないと難しそう。
つまり、作っていくと、どんな不具合が生じるか、例外が生じるか、を
あらかじめ予測できないと、理想的な設計なんてできないんじゃないだろうか？

というわけで
「作る」＞「こんな不具合がぁ！」＞「スパゲッティで修正」
な俺には向いてないのかも orz

小規模開発では必ずしもそうでもないよ。
XP、アジャイルあたりを調べてみなよ。
http://www.objectclub.jp/community/XP-jp/

とりあえず作る→ダメっていわれる→手直しする→なんか違うといわれる→残業して頑張る→仕様変更の通知→＜省略＞
　　　
　((∬　　)))))三
　｜ヱ　ヱ　V6)　　出口が見えねぇ・・・、いつまでやっても終わらねぇ・・・
　　i　　し　u
　　＼　⊃　／
　　　　ー

　ノ　""""""｜
　ﾘ　[￣]-[￣]　　　ククク・・・幸せだろう。これは君が望んだスパイラルな開発。
　　　　　∪　｜　　　そう、これはオブジェクト指向なのだよ。
　　　　「ー　/

>>490
お前の場合、オブジェクト指向云々以前の問題だろ

>>490
オブジェクト指向に限らないよ。

全体−部分の関係は、それぞれの理解が深まるにつれて互いに他を
更新し合うからね。落ち着くところまできっちり分析するのが筋
だと思うのだが、んなプロジェクトは見たことない！

>>494
だって、そんなことできるわけないじゃん。

　((∬　　)))))三
　｜＞`'＜　V6)　俺に、俺に分析・設計能力さえあればスパゲティにならずに・・・くそっ
　　i　　し　u　　　　インヘリタンス、コンポジット、ポリモ・・っ、舌を噛んだ。
　　＼　⊃　／
　　　　ー

ポリモひとつでいいよ、覚えるの。

>>342
乙　　　　　,,､､､,,,、,,z､,_,､、
　　　　 ,r三ミﾐﾐヾヾﾐt,X(ﾘﾐ､,
　　　　 ミﾆﾐﾘ" ゛ミ､"゛ﾘ"ミﾐ､>
　　　　三ﾆ"　　　　　　　　゛ミi
　　 ,､_ミ爪",,-____　　　　　　,,<､
　　 i ﾄ､ﾐﾐ　,r‐- ､｀`'ニ=‐、.彡ﾘ
　　 ヾ,iﾊ゛.´ _,,､_ 　i.;　_,.　｀ 彡'i)
　　　 ｀､j,'　 `ﾟ''´:.ﾉ i::<･ゝ) .ﾊン
　　　　　i, 　 ｀ ,､/　i_　｀`　,r'
　　　,r〃'i　 ,r'ヽ、 _,〉　　/
　　 /i:ﾄ､;;i, 　ﾐ=_‐_-, 'i　/ヽ__
r-‐'´i::::ﾊ;;ヾ、‐‐-､　 ノ´/i:::'i｀i‐- ､_
::i' .l:i 'i::::i ヾ;;`‐---‐'i':/ i､ 'i::!　i::::i　｀
http://news.kyodo.co.jp/kyodonews/2002/niccho/gallery/021203D125.jpg

>>487
結城浩の「Java言語で学ぶデザインパターン入門」を読めばどうってことはない。

>>490
それも結城浩のデザインパターン本を読む、
ことでだいたいイメージがわいてくる

オブジェクト指向言語を理解するのは難しくはないがオブジェクト指向を極める
のは難しい。

結城浩のデザインパターン本＝糞グラマー量産本

みんなオブジェクト指向って単語なら知ってる

Javaプログラマのデザインパターンの理解には正直結城本なんかよりも
日立の「Javaデザインパターン徹底攻略」のほうがいいと思う。
これでアウトラインを理解したうえで更なる理解が欲しければGoF本読む。

最初からGoF読むと正直なにをやりたいのかよくわからんしな。

しかし、ギャングオブフォーとか、スリーアミーゴとか
計算機連中は単なるオタの癖に悪ぶってカッコつけるから少しキモイ。

スリーアミーゴって踊る代走査線のおっさん三人だよな。
奴らは悪ぶってカッコつけてたのか？

>505

大捜査線のスリーアミーゴス自体がパクリなのよ。
元ネタは邦題「サボテンブラザース」という映画(1986)。
ttp://www.amazon.co.jp/exec/obidos/ASIN/B00005G0JB/250-1045888-8809028

>504 がいっているのはUMLを作成したJacobson, Booch, Rumbaughの三人のこと。

>>485
これを読め。
ttp://www.atmarkit.co.jp/farc/rensai/goodmodel01/goodmodel01.html

>>485
15年くらい遅れてないかい。

>>507
＞良い設計モデルの作り方（前編）
フム、フム。具体的な例は後編ですか・・・

->良い設計モデルの作り方（後編）
->通常、「ユースケース実現」やそのほかの分析方法によって、分析モデルを推敲するのですが、その方法は、割愛します
割愛!?

->設計モデルを作成するのですが、ある程度分析モデルは正しく作成されている、つまり、すでに分析モデルの段階で
->モデル自体が機能要求を満たしていない、または責任が正しく分割されていない＜省略＞状態ではないとします。
やられた！設計モデルのはなしをする上で「分析モデルが正しい前提」という布石をされた。もう無理ポ。
〜糸冬〜

メモ：オブジェクト指向をPGには普及させるための問題点
・分析において客との対話は重要である。およそPGはこれを得意としない。
・いまやほんとどのPGはコーダー化している。その気質は「設計メンドクセ」である。

おいおいPG達よ、はやまるな。分析・設計はSEである俺様の仕事だぜ。

おいおいPG達よ、はなまるや。

たいへんよくできました。

>>510
だって、もまいらの設計書、役にたたねんだもん。

>>513
それじゃ、とりあえず不明なとこはお客さんに質問してといて。

せっかくオブジェクト指向設計しても顧客の無理な要求によって
再利用など無縁なアプリが出来上がるってのは常識ですが．．．

　((∬　　)))))三　　この設計書おかしいじゃないっすか。製作できないっすよ。
　｜ヱ　ヱ　V6)　　あいまいな事だらけでお客さんの要望も変わってるし・・・　
　　i　　し　u
　　＼　⊃　／
　　　　ー

　ノ　""""""｜　ククク・・・上流工程での仕様は仮定（仮想）であり、大まか（抽象）だ。
　ﾘ　[￣]-[￣]　　つまり、 virtualであり、abstractなのだよ。
　　　　　∪　｜　　下流工程で適切にオーバーライド（仕様変更）される。
　　　　「ー　/　　　　そう、これはオブジェクト指向なのだよ。

>>510
将来、SEの仕事はプログラマが兼ねることになる。
UMLによるModel Driven Architecture、リバースエンジニアリング、
eXtreme Programmingの台頭, Rational Unified processが
さらにそれを加速させる。
　 　

>>502
だが初心者がオブジェクト指向に対する理解理解を深めるには
「Java言語に対するでざいん入門」はうってつけの本だ。
まずはあそこから入りオブジェクト指向初心者に自信を持たせることが重要だ。
だが、ある程度あの本の内容を理解してきたらそこで止まるな！　と警告は
しておいた方がいいことには間違いない。　 　




>>510
将来、SEの仕事はプログラマが兼ねることになる。
UMLによるModel Driven Architecture、リバースエンジニアリング、
eXtreme Programmingの台頭, Rational Unified processが
さらにそれを加速させる。

ＰＧの作業負担が増えることをさらりといってのける心地良さよ。

【玄人】我が名はプロジェクトマネージャーMaven
http://pc5.2ch.net/test/read.cgi/prog/1090129578/

こいつをつかえばプログラマの負担は逆に軽減する。
しかも、MavenはSEやテスターだけでなく
プロジェクトマネージャーの仕事までをも略奪する強力なツールだ。

便利なものは積極的に使え。
ビルドツールはIDEと併せて積極的に使え。
プログラミングの自動化は開発効率の大幅な向上につながる。
よってApache Mavenに加えてGNU make, Apache Antを積極的に使え。

>>516
今の職場の上司、本気でそう思っているっぽい...orz

ブラックＯＯな予感・・・

過去の製品をただ継承することが＝拡張とかオブジェクト指向としか考えていない
教授もいたけどな。こまったもんよ。

「継承」というネーミングに騙されてるんじゃねえのかと。
継承はオブジェクト指向を効率良く使うための一つの機能に過ぎないっつーのに。
デザインパターンを勉強しろっつーの

(　´Д｀) ｷｮｳｼﾞｭ?　ﾅﾂﾔｽﾐﾀﾞｶﾗﾈ (´∀｀　)

オブジェクト指向ってオブジェクトとオブジェクト間の関係で考えるってことなんしょ？
継承はその関係のなかの一種類で。

考えが甘すぎ。
それそこオブジェクト指向のことをよくわかっていない教授と同じ

>>526
解説ｷﾎﾞﾝ

とりあえずデザインパターン本でも読め

デザインパターン=オブジェクト指向なのか？

デザインパターンってどっちかというと実装レベルよりの話のような気がする。
オブジェクト指向で難しいのって分析・設計レベルというか概念レベルのモデリングの
ような気がする。

>>530
デザインパターンは設計段階のパターン
分析段階のパターンはアナリシスパターン
実装レベルのパターンはイディオム、ちゃんと理解してから書きましょう

>>531
そうやね。ｽﾝﾏｿﾝ

ポリモを如何に覚えさせるかにつきると思うんだが。
その上でデザパタは優秀。

おまえら冷静に考えろよ

オブジェクト指向以前のパラダイムでも
まともに設計やコード化ができない連中が
オブジェクト指向を使えばできるのか？

それ以前のパラダイムでもまともにできないバカは、やっぱり、
考えてもわからないバカだから、
ちょっとはやっているキーワードに引っかかるんだろうな。

>>534
ではおまえはアセンブラで組んでみたまえ。オレはオブジェクト指向の言語で作る。
同じ力量なら同じ期間で同じものが作れるだろうな？

>>535
オブジェクト指向言語で作ればオブジェクト指向なのか？

やっぱバカだな。

突然だけど賢者＆大魔道士の方々に見習い魔法使いから質問です。

あるアプリケーションの基盤となるクラス(AppBase)があったとします。

で、マスター的な情報、例えば郵便番号をキーとして住所が取得できるHashMap
(addresslist)と、
建物情報を複数持っているArrayList（buildings）を持っています。

class AppBase {
HashMap addresslist; // キー:郵便番号 データ:住所
ArrayList buildings; // Buildingクラスが格納される。
}

buildingsにaddする建物クラス(Building)があったとして
Buildingはaddresslistの情報を使用したいとします。

この場合、Buildingのコンストラクタにaddresslistを渡したり、
addresslistにアクセスするstaticなアクセッサを用意したり
するのって、私としては依存関係的？に気持ちよくありません。

そこで、BuildingクラスにsetAddress()みたいなセッターを用意して、
Buildingクラスのインスタンス作成後に住所をセットしてあげるのを
考えたのですが、こんなカンジでよろしいのでしょうか？

うまく伝えられるか心配ですが・・・。

依存関係的にaddresslist<-AppBase->Buildingとなっている場合に、
addresslistとBuildingの間で情報をやり取りする架け橋の
スマートな実装方法を教えて欲しいのです。

もし、時間がありましたら教えてくださいませ。

>>529
死ね

>>536
お前のバカな脳みそとどうしようもない低スキルでは
オブジェクト指向にもならないだろうなw

>>537
AppBaseクラスを一体何につかうのか？
そこをちゃんと考えたか？

AppBaseクラスはその喩えで言うと
土地みたいなものか？　それとも、なんでも
かまわない適当なものであるのか？

もし仮に土地と考えるとおかしなことだ。
一つの土地に複数のビルが立ち並ぶのか？
では、複数のビルにまったく同じ住所を割り当てるのか？
おかしな話だ。

>>540
537です。
AppBaseはなんでも良い適当なものと考えました。

>>537
Buildingが10件あったとして
それぞれのコンストラクタに全く同じ住所を持たせるのか？
ほとんど無意味だな。
AppBaseがすでに住所もっており
各Buildingの住所は全く同じなら
わざわざBuildingのコンストラクタに住所を渡すことに何の意味があるの樽か？

その例ではBuildngクラス内で住所を使って何かをしたいだけか？
だったらassresslistの情報のためだけにBuildingの
それ用のコンストラクタ、setterメソッドもいらない。
特にアクセス権の制限もない。
Building側からassresslistにアクセスすればいいだけだろう。
Building側からHashMapのgetでとってくるだけでいいだろうか。

それとだ、staticなアクセッサなんぞつくってどうする気なのか？

Visitorパターンとか使えや

>>541
その一言で使えないわけのわからないソフトを
作ってどうするんだ？　って思われるだけだぞ。

AppBaseがどうでもいいならBuildingと住所との関係も希薄だな。
一緒にくっつける意味がない。

>>537
ちと例えがアレだけど
俺もおまいとまったく同じ事でつい最近悩んだゾ

各buildingを生成するときにbuildingからaddresslistを参照したいけど
addresslistをコンストラクタでツッコムとか
addressList自体をstaticに触れるようにしたりするのは気持ち悪い
ってことだよな。で、生成後にセットするしかないのかと。

でもさーその例だとさー
擬似コードみたいな感じだけど
class Data {
　　Address address; //住所クラス
　　Building building; // Buildingクラス

　　setAddress();
　　setBuilding();
}

HashTable ht;//C++だとテンプレートての使うのかな。キーとDataをペアで格納。
Data data;
int key;
ht.set(key, data);
とかでで事足りちゃわないか？
これでダメな理由かかないとアカンとかおもた。

>>542,543
ダメ頭で説明頑張ります。

たとえば、皆さんはマスター的な情報と、個々の情報を持ったクラスを
作成することはあるのかな？と、
こういう方法事態が問題なのでしょうか？

Buildingが10件あったとすれば、勿論、郵便番号も住所も色々としてます。
AppBaseは考え方を説明するためのただの基盤となるクラス。
意味をつければ「建物情報管理クラス？」となるのかな。
この意味付けの場合、建物情報管理クラスにaddresslistを持たせるな！とかは
置いといてください。すいません。

考え方というのは「マスター的な情報に個々の情報がアクセスする方法」
です。

> Building側からassresslistにアクセスすればいいだけだろう。
> Building側からHashMapのgetでとってくるだけでいいだろうか。

ごめんなさい。この引用部分の意味がわからないのです。
Buildingクラスのインスタンス作成後に、
BuildingクラスのsetAddress()とかに対してaddresslistのgetで取得した
住所をセットしてあげれば良いということですか。

なんらかの意見があれば宜しくお願い致します。

>>544
537です。
ごめんなさい。書き込みに気づきませんでした。

544さんの悩んでいた状況の通りです。
書き込んでいただいたコードを見ていて。
ちょっと明るい気分になった気がします。
（そんなもんかい！とか言わないで。）

今、作りたいものはどんなもので、情報としてどのように持たせれば良いのかを
もう少し自分なりに考えてみます。

また書き込みさせていただくと思いますが、今日はこの辺にしておきます。

どうもでした。

>>546
納得かＹＯｗｗｗｗ

>>537
多重継承を使え。

俺はWindowsアプリ作るとき、ドキュメントクラスに入れるかビュークラスに入れるかでさえ
悩むが、普通のオブジェクト指向プログラマーは迷わないのか？

迷うくらいどちらにもそれなりの必然性があるならどちらでもいい。
どちらかを選択して問題が発生したら直せばいい。
そんだけ

☆問題☆
以下の条件を最低限満たすためにどう設計しますか。
AMgr・BMgrは単なるプレイスホルダーではないので
構成を変えられないと仮定する。

class AMgr{
　　private Vector AVec; 　　//Ａクラスのオブジェクトが登録される
}

class BMgr{
　　private Vector BVec; 　　//Bクラスのオブジェクトが登録される
}

class A{
　　//Bを複数生成しBMgrに登録しなければならない。
　　//必要に応じてBMgrから抹消しなければならない。
}

class B{
　　//生成したＡからのみ操作される
}

なんかの宿題か？

>>551
それだけの条件なら、機械的にやりゃいいんじゃないの？

「前提条件が足りねえ。腐った設問だ。」と言い放って終わりにしたいが。

ああ、ごめんヌルーしてください

こんばんは、昨日の537です。
ちょっと気になったので書き込みします。

548さんの「多重継承を使え。」とは、
どんな感じの実装になるのでしょうか？

浅はかな頭で考えて、
どんなに継承してもBuildingとaddresslistが
紐付かない気がして眠れません。

賢者の方々解説やお怒りお願いします。

ソース管理もしないで〜♪
１システム何百というEXEを構造化プログラミングしていたあの日よ〜。
今では〜♪
まともに動く事だけが結果とはならない？オブジェクト指向開発〜。
でもね。
最近、ちょっとだけオブ脳なかんじが
「ピキーーーンッ」
ってきたりするんだ。
だからどうなんだって？
気にしないよ。
プログラムを書いてる時間が昔よりもっと楽しく感じられるのさ。

多重継承をつかえば、すべてのメソッド・値へのアクセスがクラス一つで実装できる。
ただし、多重継承を行う際には、メソッドや値が重複しているとエラーになるので
要注意だ。

そういう使い方をした瞬間に
オブジェクト指向とは言いがたい代物になりやせんかね？

ビルに必ず住所があるなら継承でいいだろ。

だめ。

>多重継承をつかえば、
>すべてのメソッド・値へのアクセスがクラス一つで実装できる。

という発想で継承するなら
もうめんどくさいからこの際全部継承してみてはどうだろう。
Ｃ言語のグローバル変数みたいに何でもアクセスできて
さぞかし使いやすいと思うＹＯ

で、呼ばれてもいないのにちょっと過保護的に説明してしまうと
上のような理由から多重継承はカプセル化の根底を覆しかねない。
また人間の知性を超えた得たいのしれないものが出来てしまうかもしれん。
よって慎重に使うわけだが
そんなウンチクなぞ関係なく
>>548は>>537の次元の違うクラス同士を多重継承しようってのか
このうすらトンチキのおっぺあｓｗ＄「＠ｐ９ふじｑ４３こ

今日も懲りずにこんばんは。
昨日の「多重継承を使え」の意味が理解できました。

「このオブジェクトは”六本木ヒルズタワー”でもあり
”全世界住所録2004年版”でもある。」

っていう考え方ですよね。
もしこうするのなら

「このオブジェクトは”六本木ヒルズタワー”であり
”全世界住所録2004年版”を所有している。」

ってかんじの「包含」関係のほうが粋な感じがします。
でも、最初の質問のときのようにマスター的な情報を個々のクラスに
持たせたくないんですよね。

なんかむずかしいなあ。

sage忘れ＆562は537の書き込みでした。

OOPは魂のささやくままに組めばいいから、俺は楽だがなぁ…

>>545
だったらaddressはBuildingクラスだけに持たせろ。

それかaddressクラスを分割させろ。
東京都という】都道府県情報をもつクラス、あるいはフィールド、
市区町村情報をもつクラス、あるいはフィールド、
をそれぞれ持たせるような形にすればいい。

>>551
> ☆問題☆
> 以下の条件を最低限満たすためにどう設計しますか。
> AMgr・BMgrは単なるプレイスホルダーではないので
> 構成を変えられないと仮定する。
java.util.Vectorは使用禁止だ。ついでにHashtableクラスも使用禁止だ。
これからの時代はArrayList, HashMapの時代だ。

それと実装多重継承なんぞ御法度。実装多重継承はオブジェクト指向の敵。

public final class AMgr{
　private ArrayList aVec;

　public AMgr(){
　　aVec = new ArrayList();
　}

　public add(A a){
　　aVec.add(a);
　}

　public A getA(int x){
　　return aVec.get(x);
　}
}

public final class BMgr{

　private ArrayList bVec;

　public BMgr(){
　　bVec = new ArrayList();
　}

　public add(B b){
　　bVec.add(b);
　}

　public B getB(int x){
　　return (B)bVec.get(x);
　}

　public void remove(int index){
　　b = (B)bVec.remove(index);
　}

}

class A{
　private BMgr b;

　public A(int numberOfB){
　　b = new BMgr();
　　for(int i = 0: i < numberOfB; i++){
　　　b.abb(new B());
　　}
　}

　public A(List arrayListB) throw BOnlyException, Excception{
　　b = new BMgr()
　　if(arrayListB.get(0).getClass().getName() != this.getClass().getName()){
　　　throw new BOnlyException("ここにはBクラス以外は受け付けないぞｺﾞﾙｧ");
　　}
　　b.addAll((ArrayList)arrayListB);
　}

　public void remove(int index){
　　b = b.remove(index);
　}
　
}

public class B{

　private double x;

　public B()｛
　　x = StrictMath.random();
　}

　public double getX(){
　　return x;
　}

}

public class Main {
　public static void main(String[] args){
　　ArrayList bArray = new ArrayList();
　　bArray.add(new B());
　　bArray.add(new B());
　　bArray.add(new B());
　　bArray.add(new B());
　　bArray.add(new B());
　　bArray.add(new B());
　　bArray.add(new B());
　　bArray.add(new B());
　　A a = new A(bArray);
　　a.remove(5);
　}
}

こんな感じでどうだ？

JAVAで書くな。

（ﾟДﾟ）ﾊｧ?
質問者がJavaコードを使って質問したから
Javaで答えてやったんだが。

>>509=485
507の段階でもっと直接的に書くべきだったな。
後で何を書こうが、485はオブジェクト指向を分かってないレスだ。

485 ：仕様書無しさん ：04/07/15 01:54
オブジェクト指向は現実世界をモデル化するそうだ。つまり、現実世界が理解できないと使えないわけだ。
業務フローや客を無視してコンピュータの技術論を展開したがるPG達には縁の無いはなしってことさ。

(ttp://www.atmarkit.co.jp/farc/rensai/goodmodel01/goodmodel01.html)
　つまりオブジェクト指向とは「実世界を忠実に表現する」というよりは、構
造化やデータの抽象化によってモジュール化を強化し、「プログラムの依存性
を制御する」という概念から生まれています。『Agile Software Development:
Principles, Patterns, and Practices』（Prentice Hall刊）の著者である
Robert C. Martinの言葉を借りるとオブジェクト指向技術とは「モジュール間
の相互依存性を制御することができるソフトウェア開発のための設計手法であ
り、抽象化を用いることにより、依存性を制御する（モジュール間で、モジュ
ール同士が直接依存することを避ける）壁を作り（独立性を高め）、ソフトウ
ェアの陳腐化（保守や拡張ができなくなる状態）を防止する」となります。

>>568 public A(List arrayListB)
関係ないけど、Javaのコレクションはこういう実装しか出来ないのが困ったもんだな。
いちいち型チェック、キャストしなきゃなんないのが、面倒だし、バグの温床。
1.5ではGenericsがあるけどさ。
これはオブジェクト指向的にどうなんだ？

現実世界をモデル化するのはどんなソフトウェアでもそう。
人間がやってる処理をコンピュータにやらせるってのはそういう事だ。
どの部分をどこまでシミュレートするかはそれぞれ

>現実世界をモデル化する
とか
>実世界を忠実に表現する

というような表現は俺にはたわごとに聞こえる。
オブジェクト指向が概念的で難しいものであるかのように
無駄に神格化するような作為を感じる。

DFDも論理モデルとか物理モデルとかいうし
ER図とかのデータモデリングも知らんのか
モデリングはOO以前からある営為だ

そもそもモデリングは現実世界を「忠実に再現する」事ではないしね

>>574
他人に使わせる場合はあらかじめArrayListの要素に入るものを限定することをコメントしておく。
ArrayListクラスを継承する、ラップする、委譲する、集約する。
Jakarta Velocityを使う。

>>577
> DFDも論理モデルとか物理モデルとかいうし
> ER図とかのデータモデリングも知らんのか
> モデリングはOO以前からある営為だ
アフォか。オブジェクト指向はDB以前からあるものだ。
オブジェクト指向の歴史はギリシャ時代のプラトン哲学にまで遡ることができる。
それに比べDBの歴史は100年も経っていない。

長い間主流だった構造化プログラミングの反省から
再利用やデータの保護を意識的に取り入れたら
オブジェクト指向と呼ばれてパラダイムとして受け入れられました、
ってだけの話を難しくしすぎ。

オブジェクト指向で書くと再利用しやすいＹＯ
オブジェクト指向で書くとデータを安全に使えるＹＯ

というのがオブジェクト指向の正体です。
それ以上でも以下でもありません。
おまいらもっと気楽にＯＯＰ楽しんでください。おながいします。

>>579
えらい遡ったな。(笑)
話がちゃんぽんになってるだろ。
概念としてだけのＲＤＢみたいな理論なら、
ギリシャ時代にだってあったのかも・・・

「集合を取り扱う方法」という切り口で見ればどちらも同じだと思う。

>>580
まぁそんなとこだよね。

>オブジェクト指向で書くと再利用しやすいＹＯ
>オブジェクト指向で書くとデータを安全に使えるＹＯ
なかなかそうもいかないんだが、他にとって変わるものは
なさそう。「ちゃんと書ければ」の話だよな。

>581

いや、ところが本気でプラトン哲学(イデア論)と絡めてオブジェクト指向を説明する
輩が一杯いるのだよ、これが。
プラトンのイデア論では「世界はイデア(理想状態)の不完全な投影に過ぎない」と
いうことになっているが、これを当てはめて「世界はクラス(イデア)のインスタンス」、
「この世は不完全なんだからイデア(クラス=概念=言葉、継承構造や集約構造などの
抽象パターン)の方が大切だ」と大まじめに主張する奴らがな。
>579 はこういう連中の考え方に毒されているだけだろう。

もはや異常者だよ･･･

単に共通点を見出す事が出来るというだけなのに。
本当に遡ることが出来ると言うのなら、イデア論から二十世紀までの歴史を解説してみろ
ってんだｗ

オブジェクト指向のキモになる考え方が単純であることと
らしく書けるかどうかは別問題。
らしく書くのによさそうな教材はデザインパターン。

デザインパターンを使おうということではなくて
オブジェクト指向設計・実装の感触をつかむのに
これ以上ないってぐらいの教材と思うがどうか。
実際そういう趣旨の本もでているけど。

デザインパターンそのものは
適用できる場面が思いのほか多くないのではないだろうか。
無理やり適用しようと思えばかえってらしくなくなる。

多態とか多様てのは
オブジェクト指向特有の考え方ではないと思っています。
Cにも関数ポインタがあるし。
利用場面がとても多いので後発のOOPLは言語機能として
とりいれていることが非常に多いというところですか。

オブジェクト指向だとIF文が減るという言葉の意味がわかりません。
誰か教えてください。

>>588
if文やcase文で分岐する代わりに、ポリモーフィズムで分岐するから。

>>589
なるほど。�d

なんでもかんでもpublicにさえしなければイイよ

>>582
イデア論を持ち出して説明することの何処が悪い。
初心者をオブジェクト指向の世界に導き出すにはわかりやすくていいだろ。

>>592
釣れそうですか？

>>580
> 長い間主流だった構造化プログラミングの反省から
> 再利用やデータの保護を意識的に取り入れたら
> オブジェクト指向と呼ばれてパラダイムとして受け入れられました、
> ってだけの話を難しくしすぎ。
>
> オブジェクト指向で書くと再利用しやすいＹＯ
> オブジェクト指向で書くとデータを安全に使えるＹＯ
>
> というのがオブジェクト指向の正体です。
> それ以上でも以下でもありません。
> おまいらもっと気楽にＯＯＰ楽しんでください。おながいします。

それだけじゃ「なんだ、それだけだったらオブジェクト指向にする必要がないじゃないか」
という輩が出るからそれだけでは良い説明とはいえないな。

コードの再利用をするとコストが50%上がるという話は聞くだろう？
するとオブジェクト指向はコストがかかると勘違いするウザイ奴が現れる。
よってその説明では誤解を生みやすい。

それだったら、可読性、信頼性、拡張性や移植性、メンテナンス性をアピールしたほうがいい。

>>586
> デザインパターンそのものは
> 適用できる場面が思いのほか多くないのではないだろうか。

そりゃチミの視野が狭いだけだよ。
いつでも拡張しやすいように準備されたフレームワークってものをご存じかな？
JavaのAPIにはそういうものがかなり出そろっている。
APIそのものにデザインパターンが駆使されている。
それどころかデザインパターンをしらないと使いこなせないAPIというものもある。

>>588
Stateパターンの解説を読んでみるとよくわかるぞ。

>>595
そもそも、ＡＰＩなんて最初っから拡張されることを
ある程度見越して設計されているわけで、
業務アプリなんかではそんなに出番はないような・・・

って釣られたか？

>>597
java.utilパッケージとははデザインパターンを使う出番がかなり多いぞ。
Observerパターン、Iteratorパターンが見事に使われているわけだし。
Servletとか使うときも知らない間にTemplate Methodパターンを使っている。

ServletContextを使うときも知らない間にSingletonパターンを使っている。

Mathクラスみたいなstaticなクラスを作るときもFacadeパターンは重宝する。


Jakarta Projectにあるツールなんてものはまさにデザインパターンの宝庫だ。
Jakarta Commons のフレームワーク、ライブラリをよく見てみよう。
よくできたデザインパターン、フレームワークだ。

今MFCのサンプルソースと格闘中。スクロールバーひとつ追加できん。
どこが何を担当していて何にどれを渡せばいいのかさっぱり。
おまけにVisualStudioが.netになってからどこになにがあるのかもわからん。疲れた。

いまからMFC学んでもいいことないんじゃないかな？というよりむしろ悪い？

>>598
だ・か・ら、業務アプリではそういうのを「使う」だけであって、
組み上げることはほとんどないんじゃないかと。

Observerとかも、インフラチームなんかが使って
業務チーム用にユーティリティーを作ったりするだけで、
業務アプラーが直接使うことはたぶんない。

>>601
つまり、VB厨と大差ないレヴェルだと。

>>601
それはあんたのスキルが低いだけだよ。
相互依存しまくりなコードしか書けないんだろ？
GOFのデザインパターンを全て禁止されたら、まともなものを作れないぞ。

>>603
どっちかっつーと、コードを書かせる方のポジションなので、
その辺には気を配ってるつもりだ。
類型化とか共用化が必要なところを直接業務アプラーに
やらせることはほとんどない。

気を配ってたら、そういう考え方は出ないだろう。
同種の別ソフトを開発する時に、ルーチンの再利用もしないで
くみ上げるのか。

>>599
MFCは偽オブジェクト指向の巣窟だから
オブジェクト指向スキルを鍛えるには不向きだよ。
それは.NET frameworkになっても変わってないから気をつけておくれ。

やはりオブジェクト指向能力を鍛えるには数多くのデザインパターンを
駆使したソースコードを読むこと、JavaなどのようなAPIにオブジェクト指向を
効率よく使っているフレームワークを使っている言語を習得するのがおすすめだ。

>>601
> >>598
> だ・か・ら、業務アプリではそういうのを「使う」だけであって、
> 組み上げることはほとんどないんじゃないかと。

おまいは>>597で何が言いたいんだ？　「だから」なんといったところで
自分が正論をいっているようにみせかけているつもりか？

業務アプリを開発する話かと思ったらプログラミングすることもない、
ただ業務アプリを使うだけの側の話をしたいだけか？
だったら論点がかなりずれいているぞ。

>>604
ホントにデザインパターンを知っているのか？
類型化とか共用化のための技術じゃないぞ。
誤解を承知で大ざっぱに言うが、クラス間の依存を疎にする技術だ。
それで変更に強くなるし、再利用もしやすくなる。

>>605
たぶん、再利用するルーチンはインフラチームが作るという主張だろう。
そんな事言ってたら、全部丸ごとインフラチームが作る羽目になるのにな。
業務アプラーの出番はない。
適切にデザインされた結果なら別だが、何も考えずにクラスが相互依存しても
問題がない箇所なんてないのに。
>>604はその辺の切り分けが分かってないんだよ。

手下がボンクラ揃いだから、特別重要な箇所だけでもまともな奴ら（インフラチーム）に
作らせているという戦略なら分からんでもないが。そうじゃないんだろ？

>>606
>それは.NET frameworkになっても変わってないから気をつけておくれ。

それには同意できない。
同程度の機能を実現するもので、Javaでは適切にデザインされているが
.NET frameworkでは偽オブジェクト指向になっている例を５つ６つ挙げてくれ。

論点がズレてたり、考え方がズレているらしいので逃げることにする。

私が経験してきたプロジェクトでは、インフラ、アプリでチームが分かれ、
かつ会社も異なるというのがほとんどだった。
インフラチームでは大枠のアプリケーションフレームワークを作り、
その枠組みの中でのみアプリを書いてもらうことでボラリティを小さくすること
が重要なのであった。無論アプリチーム内でドメインフレームワークを
作ってもらったり、ツールキットを用意してもらうのもいいのだけど、
そこまで込み入ったモデルを用意するようなケースにはあまり遭遇しなかった。

>手下がボンクラ揃いだから、特別重要な箇所だけでもまともな奴ら（インフラチーム）に
>作らせているという戦略なら分からんでもないが。そうじゃないんだろ？
ほぼ正解なのだが、自分たちがまともかどうかはとても怪しい。

>誤解を承知で大ざっぱに言うが、クラス間の依存を疎にする技術だ。
>それで変更に強くなるし、再利用もしやすくなる。
主流の解釈だとは思うが、Gamma本のタイトルに「再利用のための」
とあるように、デザインパターン自体は、繰り返し現れる問題、およびそれに対する
解決策を形式化するものだと思っている。

スレ違いで失礼しますた。

今時OO談義ですか・・・
そういや2ch創成期にも似たようなことやってたな。
あれは何年前の話だ・・・

>>610
「繰り返し現れる問題」ってのが業務アプラーの領域でもガンガン現れると主張している。
まあいいけど。それにしても、うちもそうだがどこもボンクラ揃いなんだな。
それでも仕事になってるんだから、技術ってのは実はさほど重要じゃないんだろう。
困った事だ。逃がしてやる。さよなら。

>>611
２ちゃんねるより前にniftyのFPROGでやってた。
その前もきっとどこか（fjとか？）でやってたに違いない。
オブジェクト指向が主流であり続ける限り、いつまでも繰り返すんだよ。
もし構造化が主流だったら、今でも「なぜgotoは禁じ手か」とかやってるぞ、きっと。

gotoを使わないのは構造化プログラミングで、よくオブジェクト指向と対比される
構造化手法と名前は似てるけど中身は別物。

一言にオブジェクト指向と言われてもなぁ。
分析、設計、コーディングすべてをひとくくりにされても、話がかみ合わないよ。

ちょっと勉強した感じ、設計、コーディングあたりなら、構造化プログラミングの
上に勉強しても、それなりに積み重ねられそうだね。
オブジェクト指向プログラミングの作法では、構造化プログラミングでは無作法と
されているものを、あえて行わなければならない、とか、あるのかな？

分析になるとどうなんだろう。
正直まだ大規模なシステム分析とか自体よくわかってないからなぁ。
細かい要件しかこなしたことないゴミＰＧだから。
２週間かけてコード修正５０バイトとか。

とりあえずわけて語ってもらえるとうれしいな。

むしろ分析/設計/実装わけておぶぢぇくと指向語るのはｲｸﾅｲよ
それぞれいったりきたりしようじゃないか
てのが構造化からの反省だしね
業務だと難しいんだろうけどね

>>615
つーか、構造化技法自体は「分析/設計/実装」
という「業務の分割」という考え方とは何の関係も無かったのだが。

構造化技法が現れた後に、得体の知れない香具師らが
「構造化分析/構造化設計/構造化実装」という言葉をひねり出してきただけ。

オブジェクト指向も同じ。
「オブジェクト指向分析/オブジェクト指向設計/オブジェクト指向実装」。

今後また新しいパラダイムが生まれたときも
同じことが起こるに違いない。

どうしてこう微妙にはずしたレスが多いのか？
プログラマには薀蓄をたれたい習性でもあるのか
気持ちにゆとりがなく本筋を追いきれないのか

なんてな

OOP一通り勉強したら次はUPとかXPとか、開発手法の
勉強になるのかな。
このあたりになると個人レベルの実践とはいかないが・・・

UPってなんだい？

>>619
プレイヤー残り人数が増えること。

>>619
UP=Unified Process

>>621
�d

>>606
MFCが偽OOPだというのはどこら辺なのかな。俺にはさっぱり。
とりあえず今画像処理プログラムを作成中。どうしてもアンドゥ入れたいので
早速メメントを実装しようと思うのだが、クラス作る一歩が踏み出せない。

OOPじゃなかったらガリガリ作ってたのだがな・・・VisualStudioはクラス作るの
楽だけど、修正と削除がえらく面倒。

>>623
言ってることが意味不明

クラスの作成や修正削除は開発ツールに依存するものじゃないだろ？

>>624
うむ、余計なこと書いたから焦点がぼけたな。

＞早速メメントを実装しようと思うのだが、クラス作る一歩が踏み出せない。

これが言いたかっただけだ。

VisualStudioのクラス作成が楽っていうのはウイザード形式で定義の追加とか一通り揃えてくれるというだけの話。
こっちの話はスルーしてくれ。

>>609
喪前は悪魔の証明を押し付ける気か。

staticメソッドの数が多すぎる。
I/O関連がJavaよりもオブジェクト指向的な効率のよい使い方ができず
初心者でもすぐに使えるようにという設計でDecoratorパターンとかが
ほとんど使われずに作られている。Win32 APIの名残だから仕方がないのだろうか。
Unixではファイルとディレクトリは同じものなのに無駄に
わざわざDirectoryというクラスまで用意されている。
C#のプロパティ。
プリプロセッサ。
演算子再定義。

frameworkという名をつけておきながらフレームワークらしくない
それがﾄﾞﾄﾈﾄフレームワーク。

>>612
> ２ちゃんねるより前にniftyのFPROGでやってた。
> その前もきっとどこか（fjとか？）でやってたに違いない。
> オブジェクト指向が主流であり続ける限り、いつまでも繰り返すんだよ。


いや、現場でオブジェクト指向を効率よく活用としている
ところがほとんどなく、無駄なことをしているのがおおい、
そこでインドやアメリカに遅れをとっているから
まだにオブジェクト指向談義は行われる。

>>618
> OOP一通り勉強したら次はUPとかXPとか、開発手法の
> 勉強になるのかな。
> このあたりになると個人レベルの実践とはいかないが・・・

XPは個人レベルでもできる。
だがUPは集団用かな

>>623
.net foramworkと比べたら
あれのオブジェクト指向レベルはひどいものだよ。
古い部品の名残でさ

>>626
例示しろと言っているのに、なんで悪魔の証明なんだよ。
言いがかりはやめろ。

とりあえず悪魔の証明という言葉の使い方が微妙におかしくないか。
存在しないことの証明＝何人にも不可能なこと、やで。
悪魔の証明とつっぱねられるのは
Javaより劣るものが.NETには存在しないという主張の場合だけではないかと。

そういう場合の正しい返却値は
「なんでJavaがでてくんねんそんなんしるかボケヽ(｀д´)ノ」
もしくは
「Javaはよくしらまいので無理でつ」

でも、Microsoftって天才プログラマーがたくさんいるんじゃ？
OO的にひどいってのはそれだけ現実的とも言えるんじゃ？

学者：純粋なOOP！
現場：性能そこそこで早く組めてなんぼ。

>>632
>でも、Microsoftって天才プログラマーがたくさんいるんじゃ？
そーでもない。質のいい技術者なんて、
金にあかして集めたうちの数人。
で、そういう技術者が基礎を作って
あとの無能な連中が滅茶苦茶にする。

>>634
アホみたいに人数の多い会社ってのは、社員になった事があるなら判ると思うが
大海だから舐めてると、いかに井の中の蛙か思い知らされるよん。
レベルが高いのは、金で集めた外の人間だけじゃない、内部にも居る。
外に出てこないから目立たないけどね。

変な想像膨らませずに、一度MSだのSonyだのといったクソでかい会社に入社してミソ。

>>635
現実に出来上がったモノ (API にしろ MFC にしろ) を見ても
あそこのレベルが判らんか？そりゃ大変だな。

>>636
素から作るのと違って上位互換を確保しながらやるのは
当時だと、マックだとおもうが同レベル程度でも、
よほど技術力が圧倒してない限り不可能だよ。
まあ、作った事無いと全く感覚がつかめないだろうけどね。
いつぞソースコードが流出しとったでしょ、一度それ読んでミソ
そうそう、GNUのソースもついでに読んでミソ

ttp://member.nifty.ne.jp/yamazaki/doc/cpp_design_pattern.html

ここのソース鵜呑みにしていいのだろうか？メメントでフレンド使ってるのだが・・・

>>638
自己解決。なんでこれがカプセル化が崩れないのか理解できんかったがやはり
friend使うのだな。というかこういう話はマ板ネタで聞くことではなかったな。

オブジェクト指向はわかったふりをしておくのが一番だよ

答えなんてないしな。

>>639
friendってのは、姑息にカプセル化を維持するときによく使う罠。

ところで、
なんでコンストラクタは継承できないんだろう？
コンストラクタを継承できる言語を俺はしらない。
superは実質同じ事をしているように見える。
ということはコンストラクタの継承には致命的な何かがあるわけだ。
それは何か？

>>643
釣れますか？

>>643
俺はコンストラクタに返り値なしってのが不思議だ。なんでだろう。

>>645
インスタンス作成時に自動的に呼び出されたコンストラクタが
値を戻したとして、その値は何処に格納されるんだ？

>>644
別に釣りじゃないし。

>>647
釣りじゃなきゃリアルなアフォってことになるけどそうなの？
本当は釣りなんでしょ。

コンストラクタか。いやーあれはインスタンス作る上で重要だよね。

おみゃ〜らよ、ｵﾌﾞｼﾞｪｸﾄ指向の利点をひとつだけ言うならば、
ｵﾌﾞｼﾞｪｸﾄ指向ならｲﾝｽﾀﾝｽをつかって表現できるものを、
非ｵﾌﾞｼﾞｪｸﾄ指向だと、配列や構造体をつかって表現しなければならないということだ。
その結果大きなﾌﾟﾛｸﾞﾗﾑだと、重〜い配列や構造体を使うから、ｺﾝﾊﾟｲﾗが自動的に確保してくれるヒープやｽﾀｯｸ領域が足りなくなり、
たとえばﾘｿｰｽのために確保された領域を食いつぶしてしまってﾀﾞｲｱﾛｸﾞが出なくなるなどの不具合が生じるわけだ。
その都度ｲﾝｽﾀﾝｽを確保するｵﾌﾞｼﾞｪｸﾄ指向方式なら、この心配はないわけだ。
おみゃ〜らよ、これが唯一の現実的なｵﾌﾞｼﾞｪｸﾄ指向の利点よ。自分じわかるかな？
まあこれはﾏｼﾝ語に熟知したおりならではの意見よ。他の誰にもこういう意見は出せないぞ！！
どんな上級技術者にもな。
自分じわかるかな？

先に解説しとくと、>>650 は存在自体がﾈﾀなので
ﾏｼﾞﾚｽしないように。

派生で作ったクラスのデストラクタがパブリックじゃまずいよな。

>>634
かつてマイクロソフティと呼ばれた香具師はバカです。
NTを作ったデーブカトラーは天才かもしれないけど
考え方は古くさいし、ワーカホリックで週40時間越えて全然XPにならないし
短気だし、プログラミングは一人で作った方が効率がいいと言い張るし(ここでもペアプログラミングに反している)
C++は否定しCマンセーしていたし(オブジェクト指向を否定する時点でダメダコリャ)。

ちょっとねー。
しかし彼のコードはコメントをきっちり書いていたらしい。

>>653
XP崇拝もほどほどにな。ちっとは自分の頭を使え。

>>653
>プログラミングは一人で作った方が効率がいいと言い張るし
当たり前だ莫迦。

そいつが熟練者(経験が長いだけじゃない)なら、XPよりも一人で開発した方が
効率いいでしょ。
XPのペアプログラミングは二人で開発して手抜きやミスを防ぐ目的なんだから、
足を引っ張る奴とペアを組まされたらたまらない。

でも、一般的には有用だよね。ペアプログラミング。

ペアプログラミングの最大の利点は、情報が流通することだと思う。

>>656
俺が思うに、

　　ま　っ　た　く　無　駄

>>656
組む相手を選ぶのがかなり難しい。気の合う者同士でかつ技術レベルが互角ならいいが
そうでない場合がほとんどで、大抵両者とも物凄く疲れるだけで終わる。

疲れるとなんか仕事した気分になってしまうが、実際はさほど仕事は進んでいない。
実験的にちょっとやってみたが、正直もう二度とやりたくないなと思った。

>>657
そのメリットは大きい。そもそも会議を開かずに意思疎通できる。（会議開いても疎通できるとは限らないし）
ただしデメリットの方がはるかに大きかった。

>>660
日本語変だな。そもそもを削除

実際ペアプロなんて恒常的にやってるところなんてまずないだろ
>>657のメリットなんて、プログラムレビューをきちんとやれば済む話

じゃあ、「低スキル作業者のスキルの底上げ」
は？

>>662
>プログラムレビューをきちんとやれば

たいていの場合、この仮定が成り立たないとおもう。
というか、成り立っているなら「プログラムレビューをきちんとやっているから」
のような表現になるだろう。

カトラー＞＞＞＞＞＞全てのＸＰ開発者

これだけは事実。

>>653
>C++は否定しCマンセーしていたし
が、なんで
>(オブジェクト指向を否定する時点で
になるんだよ。アホかお前。

　((∬　　)))))三　お客さんの業務も知っていて、設計もできる先輩が
　｜ヱ　ヱ　V6)　　プロジェクトに参加できないとはどういうことですか。
　　i　　し　u　　　　　　当初とはなしが違う・・・俺達だけはもう限界です。
　　＼　⊃　／
　　　　ー

　ノ　""""""｜　安心したまえ。客は営業を通してしか状況を把握できない。　
　ﾘ　[￣]-[￣]　　内部事情がどうあれ、外部に対しては「進捗に問題なし」だ。
　　　　　∪　｜　　ククク・・・社内開発、営業というインタフェース・・・
　　　　「ー　/　　　　そう、カプセル化だ。これはオブジェクト指向なのだよ。

開発怪談スレはここですか？

>>667
ﾜﾗﾀ

>>664
何が言いたいのか良くわからんが、ペアプロは有用って言っているわけ？

>>670
レビューなんか真っ先にないがしろにされるものだから、
レビューをやればOKなんて仮定は無意味。
レビューをやってるかどうかは傍目にはわからないしね。
その点ペアプログラミングなら情報が確実に流通するのがいいね。
ペアプログラミングをないがしろにはしないだろう。
傍目にペアプログラミングしていないのが明らかだから。

というのが主張。

でも単純に工数が倍かかるハンデはでかいよねえ。
だから有用かどうかはわからない。ペアプログラミングを知ったときに、
「情報流通を強制する手段があったのか！考えたやつ天才！」と思ったもんで。
他のメリットとされているものは、有用なのか実感として分からない。
そう思った要因としては、今の職場が情報滞留しまくってるのがでかいな。
あ、あと俺XPやったことないんで想像で語ってる。ごめんな。

>>655
> >>653
> >プログラミングは一人で作った方が効率がいいと言い張るし
> 当たり前だ莫迦。
ヴァカか。お前が想像するような糞仕様プログラムくらいだ。
大規模開発であとから誰かがこの機能を追加したいといっった注文が
殺到する場合は一人よがりな開発手法は非常に効率が悪すぎるだろうが。

>>654
> >>653
> XP崇拝もほどほどにな。ちっとは自分の頭を使え。
脳足りんなお前は。頭が古いぞ。ＸＰだからこそ頭を使うんだろうがｳﾞｫｹ

>>656
> そいつが熟練者(経験が長いだけじゃない)なら、XPよりも一人で開発した方が
> 効率いいでしょ。

大規模開発の場合、
たとえどんな熟練者でも時間制限をかけられればかけられた分だけ
潜在的に大きなバグを生み出す小さなミスは犯す。
小さなミスが大きながバグになり大損害をあたえることもありうる。

そりゃ小規模なら一人のほうが速いがな。
しかし大規模開発では熟練者でも一人の力では無力に等しい。
複数人が連携プレーをとることで初めて大規模システムを短期間で構築することができる。

>>659
ペアプログラミングをするとき
その分だけ報酬が高ければ負担がへると思うが。
ペアプログラミングでやっても一人プログラミングだけでやっても
報酬がかわらなければ>>659のような事態になる可能性は高いだろう。

>>665
そして
> カトラー＞＞＞＞＞＞全てのＸＰ開発者 ＞＞＞＞＞＞　>>665

これも事実

>>667
お前はアフォだ。
オブジェクト指向＝カプセル化

程度にしか思っていないほど視野が狭すぎる。

オブジェクト指向といえば
カプセル化、継承、多態以外にも、委譲、集約、コンポジション集約、
Facade, Factory Method, MVCアーキテクチャーなどいくらでもあるだろう。

>>672-677
そんなに頑張ってレスしなくても・・・
ひょっして愉悦厨房ですか？
ちなみに >>667 は誰がみてもネタですが。

>>677
もまえ、言葉を頭に単に流し込んでるだけで
整理できてないだろ。視野が浅い。アフォとかいうてる立場じゃない。

>>677
は
>>667
のネタをみて

>オブジェクト指向＝カプセル化
>
>程度にしか思っていないほど視野が狭すぎる。

の結論に到達すること自体がやばすぎ。

ネタを見てそこまで連想するのは、相手が自分より劣っていて
欲しいという願望があるんだろう。
そのため自分が知っていること＝相手が知っていることとは
考えられずに、ネタではなく間違っているのだと考えてしまう。

>>672
あのさあ、ホント頭使いなよ。信者だねえ。カトラーの主張を否定するために、
ペアプログラミングを出すってことは、何も分かってないってことだよ。

カトラーの主張：
　　　　プログラミングは一人で作った方が効率がいい
　　＝10人×1ヶ月の仕事は、1人でやったら8ヶ月でできる
　　＝1人のほうが10人より1.25倍効率がよい。

XPの主張：
　　　　ペアプログラミングがいい
　　＝10人×1ヶ月の仕事は、5ペア×0.9ヶ月でできる。
　　＝ペアを組んだほうが組まないより1.11倍効率がいい。

数字は適当な。でも別に矛盾しないだろ。否定の根拠にはなりえないよ。

語調とカキコ時刻からみて >>672-677 は同一人物の可能性が極めて高い。
XP信者なのだろう。XPに対する否定意見が許せんかったのだろう。
で勢いにまかせてネタに誤爆だ。

日本でペアやらすと「もたれあい」する恐れがある。

オブジェクト指向 と Java をよろしく。

　　　　 /＼
　　　　i〇-ヽノ
　　　ノ|　　　|
　　　　レ＾i_ﾉ

>>676

> カトラー＞＞＞＞＞＞全てのＸＰ開発者 ＞＞＞＞＞＞　>>665 ＞＞＞＞＞＞ＸＰ信者＞＞＞>>676

これも事実

>>675
>ペアプログラミングをするとき
>その分だけ報酬が高ければ負担がへると思うが。

つまり顧客が２倍の金をくれるってこと？

　　/　　　　 ﾐ三
　ﾐ＿　　＿　三　君に相談なんだが・・・我が社の経営状況では　
　（　・`' ・　　ﾐり　今年の新人に１人１台のPCも支給できんのだよ。
　　i　 し｀　　　　
　　＼ ―　　／
　　　　ー−

　ノ　""""""｜
　ﾘ　[￣]-[￣]　　社長、いまや時代はXPです
　　　　　∪　｜　　ククク・・・そこでペアプログラミングですよ
　　　　「ー　/

いま >688 がいいこと言った

>>686
> > カトラー＞＞＞＞＞＞全てのＸＰ開発者 ＞＞＞ ＞＞＞＞＞＞ＸＰ信者＞＞＞>>676 ＞＞＞ >>686　＝ >>665

これも事実

>>679
で、何がどう視野が狭いんだい？
チミをアフォな人間だといわせてもらうよ。
カプセル化程度のことしか知らないクズが偉そうに語ることではないからな

>>681
> ネタを見てそこまで連想するのは、相手が自分より劣っていて
> 欲しいという願望があるんだろう。
そしてチミも相手が自分より劣っていて
> 欲しいという願望があるんだろうな。
そのチミのこのレスがまさにそうであるように。
みんなからそう思われたいんだろ？

>>690
お前、虚しくないか

>>682
お前、いかにも正論をいっているように見せかけたプロパガンダ戦術で
チームすら組まずにひとつのプロジェクトを一人ですべて一人で
やったほうがいいと言い切ることが正しいと思い込ませようとしているだろ。

>>691-692

真性かよ。

>>693
それをいうなら、>>686にも言うこと。
言わなければ癪に障る

>>695
何が真性だ？

いってみろ

だが、
XP開発者　＞　ウォーターフォール信者

の式は成り立つことには変わらないがな

>>696
Ａ>>>>>>>>>>Ｂ
↑これ書く椰子って厨ばっかなんだよな。

この式も成り立つ

アスペクト指向 + オブジェクト指向開発者 ＞　オブジェクト指向開発者　＞　構造化手法開発者(C厨)　＞　アセンブラ厨

>>699
>>>>>の数を減らせばいい。
さもないと、数学板、などではまともに議論がしずらい

オブジェクト指向肯定・推進派　> オブジェクト指向を知らない者　> オブジェクト指向否定派

だな

>>700
左ほど馬鹿が多いという罠

オブジェクト指向肯定・推進派　> オブジェクト指向を知らない者　> オブジェクト指向否定派

ゆえに、技術者の地位、スキルは

オブジェクト指向言語開発者 > C厨 > アセンブラ厨

となる。

>>703
馬鹿＝天才なら君の意見は正しい

>>704
言語開発者ってことはストラウストラップとかか。
そらスキルも地位も高い罠

>>706
まあ、それでも

カトラー＞＞＞＞＞＞＞＞＞＞ストラウストラップ

だけどな。

でもね
誰か言ってたけど

日本人にオブジェクト指向で書かせたら、
十人十色で、共同開発や再利用がかえって困難になるらしいよ。

欧米人やインド人とかはそのへん、自然とビシッと合うみたい。

国民性とかあまり信じたくないけど、
やっぱ、日本人はワビサビなのかな

日本人には述語型言語がいいね。

>>694
カトラーの主張とXPの主張が矛盾しない以上、XPの主張が正しくても
カトラーの主張を否定する材料にはならんといってるだけだ。

どっちが正しいとか言ってないだろ。
何のためにわざわざ「主張」と断ったと思ってるんだ。
論理的に考えろよ。自分に都合が悪きゃプロパガンダ呼ばわりってアホか。
出鱈目なレッテル貼っておしまいじゃ、そりゃ頭使ってないといわれるに決まってるだろ。

カトラーさんは今何してんの？
AMD64がらみってことだけど、Microsoftにいるのは変わってないのかな。

なにやら変な式厨が出没してるな

>>708
>日本人にオブジェクト指向で書かせたら、
>十人十色で、共同開発や再利用がかえって困難になるらしいよ。

それ、十人十色だからじゃなくて、単に出来が悪いんだと思う。
もし、俺の会社でオブジェクト指向を導入されたら最悪だと思うよ。
みんなカスばっかりだもん。

オブジェクト指向風に設計されたでたらめなプログラムよりは、
構造化風に設計されたでたらめなプログラムの方がまだマシだとおもう。

>>713
> もし、俺の会社でオブジェクト指向を導入されたら最悪だと思うよ。
> みんなカスばっかりだもん。

そんなに自分を卑下すんなよ。

マ板スレの基本は自虐だ。

>でも単純に工数が倍かかるハンデはでかいよねえ。

プログラム設計+コーディング+単体テストの工数が倍かかる?
1/2の間違いだね

オレは今朝テレビで死んだ息子の死を悲しむオヤジ見ちゃったから
とても>>716みたいなこと書けん。

俺もオブジェクト指向のメリットはよくわからん。
単に言語がJAVAだからとか、そういう理由だけで仕方なく使っている。
あまり開発経験は無いが、VB・ASPと比べて、どこが言語的に良いのか
いまだに理解できない。頭悪いのかな？

>>718
異種リストをみてスゲーと思えればセンスはあると思う。

>>718
経験が少なすぎるか、頭が悪すぎるか、回りの環境が悪すぎるか。
いずれにしろ、何とかしないといけないよ。

>>719,720
C++とかObject指向そのものは、悪いとは思いませんが
単にJAVAが、いろいろすごそうな感じの仕様だけど
結局、頭でっかちな人が喜ぶってだけで
実践的でないな部分が多い気がする。
JSP＋サーブレットにしても、修正したときに
サービスを再起動しないと、いけないっていうのは、ちょっとねえ。
運用管理上、最悪な仕様だと思うのですが・・・。
そもそも、たいてい単純なただDBに登録するだけのような一般業務で
こんな複雑な言語なんて必要なんでしょうか？

>>721
自分の未熟さを他の物の所為にしないようにね。
C++で作成した実行ファイルを修正する時は、再起動の必要がないのかなー。
大体再起動の必要があるのは、一部の設定の修正だけでしょうに。

大体どこが複雑なんだろう。
初心者向けの本を買ってきて、読んでみたら？

>>722
はい。C++の場合は、モジュールの上書きで済みます。
WWWの場合、サービスを止めなくちゃいけない場合、事前に掲示しないと
いけないから。そういう意味で実践的でないと。
PERLの場合はもちろん、ASPにしても止めずに済む話が、
JAVAの場合いちいち管理がうざい。
721が頭がいいのかしらんけど、誰がどう見たってシンプルではないと思うが・・・。
JAVAがすぐれているっていうのなら、それを有効活用できてこその話。
設計・コーティング・テスト・運用管理　どの観点でみても、すぐれたツールとは思えない。
前にDBアクセスのコーティングを自動で作るものをPERLで作ったことがあるが
わざわざそんなものを作る必要のある言語って冷静に考えるとちょっとおかしい。

coding

>>723
そんな場合なら、Javaでも上書きで済むじゃんｗ
リロード出来るのも知らんのか。
アフォか。
本当に自分の無能さを他の所為にしてるな。

>>723
perlとかASPって、システム更新するときに、止めずにできるの?

＞721が頭がいいのかしらんけど
自作自演するにしても、もうちょっと謙虚さを・・・。

おみゃ〜らよ、大抵の仕事は中学までの算数を知っていればこなせる。
それはﾌﾟﾛｸﾞﾗﾐﾝｸﾞとて例外ではない。
ﾌﾟﾛｸﾞﾗﾐﾝｸﾞも中学までの算数で十分だ。
ﾌﾟﾛｸﾞﾗﾐﾝｸﾞだけではないぞ。建築設計や薬剤関係の理工系の仕事でさえ、中学までの算数を知っていれば十分だ。
そしてふつーの人が学習してマスターできるのは、中学までの算数が限界だ。
おみゃ〜らよ、オブジェクト指向は、高校の数学にあたるものだ。
オブジェクト指向は、高校の数学にあたるものだから、ふつーの人がマスターするのは、ちょっと無理だ。
高校の数学をマスターできるのは、頭がいいやつ、勉強ができるやつだけだ。
だからおみゃ〜らの中の過半数のやつは、オブジェクト指向がどうしてもマスターできないだろう？
無理もない、オブジェクト指向は、高校の数学にあたるものだからな。
だからおみゃ〜らは、無理せず、手続き型のスパゲティプログラムでも書いてるほうがいい。
安心しろ、スパゲティプログラムだって、ちゃんとしたソフトはできるぞ♪
自分じわかるかな？

オブ脳っていう言葉を本屋で見かけましたが、定着するかな?

>>728
沢村よ、おまえやっぱり世間知らずの高校生だろ。
SEだなんてのは真っ赤な嘘。

はやく夏休みの宿題片付けろよ。あしたから学校だぞ。

それとも　　ひ　き　こ　も　り　　で学校に行かなくていいのか？ｗ

>>728
ゼータ関数やリーマン平面の基礎も知らん奴が、DB設計できるわけがない。
と数学ｵﾀｸの上司が言っていたのを思い出しますた。

>>728
こんな間抜けな質問するやつが何えらそうなこと言ってんのさ？
基礎教養を身につけてから来いよ。

　65 ほんたま 04/08/26 20:11
　　おみゃ〜らよ、ちょっと聞いていいか？
　　JavaはOS･CPUに依らないことを売り物にしているのに、
　　どうしてOS･CPUごとにいろんなJavaがあるの？

CユーザーのためのC++入門くらい読んでおけよ。
それが読み終えたら、初めてSTL本を読んでいい。
いきなりSTLを理解しようとするとドツボに嵌るよ。

俺の場合、

　1.　K&R　AnsiC 入門 改訂２版
　2.　Ansi C 言語辞典
　3.　make の入門書
　4.　CユーザーのためのC++プログラミング入門
　5.　C++標準ライブラリチュートリアルリファレンス
　6.　Effective STL

てな感じ。

これだけ大量の本を読んでおくと、Javaなんか
知らなくてもなぜかコーディングできてしまう。

>>733
俺の場合、

　1.　Slim　Can 入門 改訂２版
　2.　de Can 言語辞典
　3.　hontama の入門書
　4.　Slim de CanユーザーのためのSlim de Canプログラミング入門
　5.　Slim de Can標準ライブラリチュートリアルリファレンス
　6.　Effective Slim de Can

だな。

>>728
　頭悪い香具師をフォローしてると、頭の悪さが伝染するから、気を付けろ！

>>733
　読書とは、人に誇るためにする物である。もっと多読して、その結果を列挙するんだ！

w

>>721
>そもそも、たいてい単純なただDBに登録するだけのような一般業務で
>こんな複雑な言語なんて必要なんでしょうか？

大規模・複雑なシステムでしかオブジェクト指向が有効でないって、
オブジェクト指向を知らない奴の典型的な思い込みだよな。

本をいろいろ読んでみて思った事。
「オブジェクト志向が理解出来ない奴はオモイッキリ馬鹿だと思う。」

>>728
変な本ばっか読んでるからな（ｗ

特に馬鹿な奴は、「オブジェクト指向が理解出来ない」から、
「オブジェクト指向は役に立たない」に思考ワープしてしまう奴。

頭悪すぎる。

>>726
例えばJSPであるタイミングでWWWの入力フォームの項目を変更したいってとき
PERLやASPならその時間でファイルを更新すればOK。
JAVAの場合、セッションで管理しているため、一連の流れを保障しなくちゃいけなくなるわけで
一度アクセスできない状態にして
一連のサービスをすべて再起動する必要が生じる場合がある。
また、バグが発見されたときとかの対応とか、はっきり入って、ああ、ASPやPERLだったら
もっと楽だったのにって思うけれど何か・・・。
そのあたりって気にならないのかなあってことが純粋に不思議なのだが。
それと、文字列のライブラリもVBに比べて貧弱だと思うのだが・・・。
うんちくでなく　JAVA最高！って思いたいのですが・・・。
皆さんは、そういう経験ってないのでしょうか？

この俺を目の仇にする暇があったら勉強しろよ年配のハゲ軍団ども。

>>741
セッション管理しなきゃいいじゃん。
セッション管理する必要なければな。
Perlでもなんでも、Webアプリなら同じだ。
hiddenタグで値を受け渡したければ、そうしろよ。

文字列のライブラリって、正規表現ライブラリがあれば
十分だと思うが、VBはそんなに凄いのか？

つーか、やっぱオマエダメだわ。

>>741
【初心者】Java質問・相談スレ52【大歓迎】
http://pc5.2ch.net/test/read.cgi/tech/1093267533/

>>741
PerlやASPでノンストップでシステム更新できるって言うから
オレのしらない技があるのかと思ったら、その程度の認識だっのか。
質問して損したって感じ。

>>741
初心者の質問
http://school4.2ch.net/qa/

741はJavaだけでなくHttpについてももう少し勉強が必要だな

ノンストップの場合は複数台のWebサーバをひとつの代表IPで運用し、
一台ずつ停止とファイルを入れ替えをおこなうのが本流だろう。
セッションはWebサーバのメモリ上でなく別機のDBに保存し、DBも
クラスタ化しておけば万全だ。

ハードに投資する金がない？じゃあ、諦めてくれ。

私の場合は一台のサーバ機がWebサーバであり、DBサーバであり、ファイルサーバです。
CPUもひとつです。そうですか、誰もきいてませんか。失礼しました。　(T∀T　)

>>743
ごもっとも。
HIDDENパラメータでも代用できるものをセッション管理で作られているだけ。
で、全部JSPファイルにベタでコードが記述されている。
ものすごい醜悪なソースファイルだ。
これがJAVAか・・・って感じだ。
文字列処理という言葉が悪かったな。
VBのFormat関数のようなものを期待しているのだが・・。
それともっと充実したデバック環境と。
やはりステップ実行、イメディエイトウィンドウは便利だった。

>>750
ここまで来ると釣りとしか思えない。

Java使った事無いけど、流行ってるから勉強しなきゃ。
でも何にも知らないから得意のVBの知識をひけらかして探ってみよう。

って感じかな？

>>752
JAVAの良い部分を探っているのはホントです。
例えばオブジェクト型だと、手続き型と比較して
一般業務の場合、DBアクセス用の関数がメインとなるケースが多いと思うが
メソッドによる値渡しの構成に変わる。
テーブルアクセス用の関数が１つ増えたときの作業量は、
手続き型のと比較して、メソッドの作成がはっきり言って面倒である。
カプセル化によるセキュリティ面のメリットって何？
実際、それで助かったなんて話、業務システムでは聞いたことがない。
一番多く聞くのはマイクロソフト固有のバグだ。
冷静に見て、ほぼ入力チェックとDB更新だけのようなシステムで
本当にオブジェクト指向というのが有効なのかを知りたい。

＞カプセル化によるセキュリティ面のメリットって何？

カプセル化で「セキュリティー」でメリットがあるなんて、
一般的にも言われてないし、このスレでもそんな発言は
無いみたいだけど?

>>753
>例えばオブジェクト型だと、手続き型と比較して
また随分とトンデモ比較ですね。

＞冷静に見て、ほぼ入力チェックとDB更新だけのようなシステムで
＞本当にオブジェクト指向というのが有効なのかを知りたい。

おいおい、入力チェックとＤＢ更新だけのようなシステムを前提として話をしてるんかい。
世の中そういうシステムばっかりだと思ってんの？

>>756
いや、そういった程度のシステムでも有効なのかって話だろ。

じゃ　結論。

簡単なシステムでは、オブジェクト指向は必ずしも有効ではない場合もある。

有効だと思うけど。
みんな違うの？

あ、このケース↓の話ね。

>冷静に見て、ほぼ入力チェックとDB更新だけのようなシステムで
>本当にオブジェクト指向というのが有効なのかを知りたい。

入力チェックや更新方法がきわめて簡単なら、別にオブジェクト指向のメリットは得られないだろうし、
それなりに複雑ならメリットはある。

したがって>>758の結論でいいと思うが。

>>721
> >>719,720
> C++とかObject指向そのものは、悪いとは思いませんが
> 単にJAVAが、いろいろすごそうな感じの仕様だけど
> 結局、頭でっかちな人が喜ぶってだけで
> 実践的でないな部分が多い気がする。
> JSP＋サーブレットにしても、修正したときに
> サービスを再起動しないと、いけないっていうのは、ちょっとねえ。

お前はなあTomcatやJBossをWindowsServer2003みたいなOSと
アップデートするのに再起動が必要なのと一緒にするなよ。
ホットデプロイ機能も知らんとは。
XMLファイルを弄れば再起動せずに済むぞ。
本番環境では常識だぞ。

>>723
> >>722
> はい。C++の場合は、モジュールの上書きで済みます。
> WWWの場合、サービスを止めなくちゃいけない場合、事前に掲示しないと
> いけないから。そういう意味で実践的でないと。
> PERLの場合はもちろん、ASPにしても止めずに済む話が、
> JAVAの場合いちいち管理がうざい。

お前はTomcatとのAdminツール、Managerツールを知らんのか？
Tomcatが起動中でもブラウザからJavaアプリケーションをインストールできるんだぞ。
デプロイといってな。WARファイルを指定するだけでアップロードされ、
自動的にWARファイルが展開されその場で即座にその該当するサービスがインストールされ稼働する。


> 設計・コーティング・テスト・運用管理　どの観点でみても、すぐれたツールとは思えない。
JUnitもCactusもMockObjectsもJMeterも知らんのか？
寝言はもっとJavaのことを勉強してから言え。

> 前にDBアクセスのコーティングを自動で作るものをPERLで作ったことがあるが
> わざわざそんなものを作る必要のある言語って冷静に考えるとちょっとおかしい。
お前はO-RマッピングツールもCMP Entity Beanも知らんのか？
HibernateやCayenneといったツールを使えばわざわざPerlで作らなくても済むぞ。
それらを使わなくてもEntity Beanで解決することもできるぞ。

冷静に考えられないのはお前のほうだ。

>>733-734
> これだけ大量の本を読んでおくと、Javaなんか
> 知らなくてもなぜかコーディングできてしまう。

Javaを知らないとなぜかスパゲティコーディングが
簡単にできてしまう傾向もあるがな。

それだけの本を読んだところではJavaを使いこなすことはできないぞ。
データベース、TCP/IP, WebServicesについてよく知らないと
Javaスキルを高めることはできないぞ。

>>741
> >>726
> 例えばJSPであるタイミングでWWWの入力フォームの項目を変更したいってとき
> PERLやASPならその時間でファイルを更新すればOK。
> JAVAの場合、セッションで管理しているため、一連の流れを保障しなくちゃいけなくなるわけで
> 一度アクセスできない状態にして
> 一連のサービスをすべて再起動する必要が生じる場合がある。

そんなやり方をしているのはお前がServletのことを良く分かっていないか、
お前の設計手法に欠陥があるかのどちらかだ。

JSPとServletとの違いもホットデプロもイトランザクションもロールバックコミットも知らんでアホなことを言わないように。
もうちょっと勉強して出直して来な。

> また、バグが発見されたときとかの対応とか、はっきり入って、ああ、ASPやPERLだったら
> もっと楽だったのにって思うけれど何か・・・。
> そのあたりって気にならないのかなあってことが純粋に不思議なのだが。
> それと、文字列のライブラリもVBに比べて貧弱だと思うのだが・・・。
> うんちくでなく　JAVA最高！って思いたいのですが・・・。
> 皆さんは、そういう経験ってないのでしょうか？
>
>
>
>

>>741
> >>726
> 例えばJSPであるタイミングでWWWの入力フォームの項目を変更したいってとき
> PERLやASPならその時間でファイルを更新すればOK。
> JAVAの場合、セッションで管理しているため、一連の流れを保障しなくちゃいけなくなるわけで
> 一度アクセスできない状態にして
> 一連のサービスをすべて再起動する必要が生じる場合がある。

そんなやり方をしているのはお前がServletのことを良く分かっていないか、
お前の設計手法に欠陥があるかのどちらかだ。

JSPとServletとの違いもホットデプロもイトランザクションもロールバックコミットも知らんでアホなことを言わないように。
もうちょっと勉強して出直して来な。

>>741
> また、バグが発見されたときとかの対応とか、はっきり入って、ああ、ASPやPERLだったら
> もっと楽だったのにって思うけれど何か・・・。

型に曖昧な言語(Perlと型に曖昧なVBがメインのASP)のほうがJavaよりもバグ対策に弱いぞ。
JUnit, Cactus, MockObjectsとかも知らないでアホなことを言わないように。
バグが発見されてからの対応は言語仕様の問題ではなくフレームワーク、ツール、開発環境などの問題だろうが。
Eclipseを使っていれば大した問題でも無い。バグ対策もバカ対策も

> そのあたりって気にならないのかなあってことが純粋に不思議なのだが。
> それと、文字列のライブラリもVBに比べて貧弱だと思うのだが・・・。

これもまた言語仕様とは関係ないことだな。

それと、そいつはVBではなくPerlの間違いかな。正規表現ライブラリは充実しているぞ。
ただしオブジェクト指向を理解できない奴には充実しているように見えず使いこなせないがな。

Jakarta ORO, Jakarta Commons Langも知らんのか？
これらを見てライブラリやフレームワークが貧弱と思ったら盲目だよお前は。

ライブラリという言葉をよく多様する者ほどオブジェクト指向を理解していない傾向が強いものだな。
オブジェクト指向を理解しているならライブラリよりもフレームワークを好む傾向があるからな。

>>749
> 私の場合は一台のサーバ機がWebサーバであり、DBサーバであり、ファイルサーバです。
> CPUもひとつです。そうですか、誰もきいてませんか。失礼しました。　(T∀T　)
rsync, vinumをインスコしてどうにか汁

>>750
> >>743
> ごもっとも。
> HIDDENパラメータでも代用できるものをセッション管理で作られているだけ。
> で、全部JSPファイルにベタでコードが記述されている。
> ものすごい醜悪なソースファイルだ。

お前がオブジェクト指向を理解できていないだけだ。
オブジェクト指向を理解できているならそんな効率の悪いことはしない。
J2EEを使ってMVCアーキテクチャを考慮し、Servlet、EJBなどと分けで分離して考えるはずだ。
それかApache Struts, JSF(JavaServerFaces)を使って分離するはずだ。


> これがJAVAか・・・って感じだ。
> 文字列処理という言葉が悪かったな。
> VBのFormat関数のようなものを期待しているのだが・・。

java.text.Formatクラスのようなものか？
java.lang.Stringを見ただけで文字列関係が貧弱だと思いこんでいるんだったら
お前盲目だぞ。

> それともっと充実したデバック環境と。
Eclipseを使え。リモートデバッグできるプラグインもあるぞ。

> やはりステップ実行、イメディエイトウィンドウは便利だった。
>
>
>
>

>>761
単純と言っても、GUIがあってデータベースを触るんでしょ？
非オブジェクト指向のGUIライブラリやDBライブラリって、いかにもつらそうだけど。

>>770
webアプリの話をしていると思っていたが、HTMLフォームのことをＧＵＩと言ってるの？

テキストフィールドが一つだけのフォームで、入力値チェックは数値がどうかだけという場合、
オブジェクト指向のメリットがある？

>>770
VBやDelphiだとそのレベルはほとんど意識しないし、って事では？

>>771
金払って作るメリットの無いシステムの議論は不毛だね。
１０程度の画面数、５程度のテーブル数でも、
保守性や拡張性を考えたらオブジェクト指向設計のメリットは十二分にある。

>>771
webアプリだとは微塵も思わなかったが、まあwebアプリだとして、
そこまで極端に単純だとさすがにメリットはないかも知れないが、
>>758はそんな状況を想定しているようには読めない。

というか、オブジェクト指向のメリットが無い例がそんな極端なのしかないなら、
そりゃ単なる言いがかりだろう。無理矢理じゃん。
まあ、>>758は単なる可能性の提示だとか言い張られたら終わりだが。

>>772
昔のVBはまだしも、DelphiのVCLを使っておいて「オブジェクト指向じゃありません」は
無理があるだろ。

>>774
Javaのクラスライブラリ使っているから全てのJavaプログラマはオブジェクト指向を理解している、と？

問題がすり替えられてるけど、
オブジェクト指向を理解してるJavaプログラマは３人に１人くらいでしょ。
後はエセ。

>>776
残りの2/3は「クラス」って何だと思ってるの？
正直、知りたい。

>>775
ライブラリを使える程度には理解してる。
それに何より、オブジェクト指向のメリットを享受してるじゃん？
「有効じゃない」なんてとても言えないと思うけど。

>>777
776じゃないが、構造体に毛が生えたもの程度の利用しかしてないんじゃ。

>>779
VBやDelphiでも同じ。ちょっと変わった関数程度の認識。

>>779-780
でもさ、それじゃコンストラクタ/デストラクタとか、クラスメソッド/インスタンスメソッドの違いとか、理解できないんじゃ？

ほんとにそんな人たちがクラスを書いているの？
「使っている」だけなら分かるんだが。

753を書いた張本人だが、質問してみるものだな。
762>>のXMLファイルは知らんかった。
秀丸でコーディングして、コンパイル→デバックログでテストって手法でした。
また紹介していただいたツールも今度試してみよう。
ちなみに俺は、品質なんかよりも実効性を重視している。
つまり、コード量なんていくら増えたって、見やすくメンテナンス性が高ければまったく
問題ないと考える。
共通部分を関数化(クラス化)するのも、本当に有効と思えるなときにしか極力しない。
少しでも共通化されなくなる可能性があるなら、ベタでも十分と考える。
なぜなら、共通処理じみたものが複数箇所にあったとしてもGREPで簡単に修正できるし、
その状態でも、一覧性が良く、メンテナンス性が高いからであーる。
さて、こんな俺がオブジェクト指向なるものを好きになれるかどうか・・・。

ウンコプログラマになに言ってもムダってことで終了

>>782
一瞬、釣りか、初心者が想像で書いているかのどちらかだと思ったけど、
よく考えたらベテランでもこういう人はいるからな。。。

>ちなみに俺は、品質なんかよりも実効性を重視している。
こんな事言うベテランは見た事がないけどな。

>>782
あんたのソースをメンテするのだけは勘弁だな。

>>785
http://pc5.2ch.net/test/read.cgi/tech/1087050664/l50
このスレの575あたりから話題に上がってるようなPGなんじゃないの?

>>781
> >>779-780
> でもさ、それじゃコンストラクタ/デストラクタとか、クラスメソッド/インスタンスメソッドの違いとか、理解できないんじゃ？
デストラクタは不要だとしても
インスタンスとstaticとの違いが解らないのは
Servletプログラマとしては痛すぎる。
致命的なバグにつながるぞ。
staticメソッドマンセーな香具師ってのはC厨に多いもんだよ。
機能ばかりに重点を置いて、インスタンスフィールド(属性、メンバ変数)が一つもない
クラスばかり作っているケースとかだな。

連中の頭の中には「入力」と「出力」以外なにも無く「状態」という概念を考えられず
「機能」のみしか考えられないからあまりにも痛すぎる。

大学時代に信号処理、数値計算ばかりやってきた香具師に
そういうことをする傾向が強いのがなんとも皮肉だな。

「Servletプログラマ」と呼ばれること自体がかなり痛いぞｗ

>>782
> 753を書いた張本人だが、質問してみるものだな。
> 762>>のXMLファイルは知らんかった。
> 秀丸でコーディングして、コンパイル→デバックログでテストって手法でした。
> また紹介していただいたツールも今度試してみよう。
> ちなみに俺は、品質なんかよりも実効性を重視している。

君の想像する実効性とやらが小さくて貧弱で寿命の小さな実効性
に見えてくるよ。大規模開発では品質が下がれば実効性も開発効率も下がる。
いつまでも職人プログラマのような、勢いだけで進めるやっつけ仕事的なやり方は
とても非効率だよ。

> つまり、コード量なんていくら増えたって、見やすくメンテナンス性が高ければまったく
> 問題ないと考える。
> 共通部分を関数化(クラス化)するのも、本当に有効と思えるなときにしか極力しない。

君の場合は、有効と思えるときですらそれを怠っているだろうけれどもな。
君の自作する関数、メソッドは、「分割・統治せよ」原則に反し
平気で10000行、ステップ数をこえてしまっているのだろうな。
それだけで他の人は君のソースコードを読む気が無くすんだよ。
それで君が一生懸命必死になって書いたソースコードは捨てられてしまう。

> 少しでも共通化されなくなる可能性があるなら、ベタでも十分と考える。
> なぜなら、共通処理じみたものが複数箇所にあったとしてもGREPで簡単に修正できるし、
ほう、修正するたびに毎回grepしか使わないのか。
チームで開発するときはたいそう迷惑なやり方ですな。
重複部分の変数名やメソッド名などを他人が変更したらいくらgrepしても無駄でしょうに。
仕事でプログラミングしたことはろくになく、一人でしかプログラミング経験が無いんでしょうな。
リファクタリングツール、バージョン管理システムを積極的に使いなさいな。

> その状態でも、一覧性が良く、メンテナンス性が高いからであーる。
そりゃよほど小規模でだれも使ってくれない、見ても暮れないようなスパゲティコードしか
かいていないならそういう妄想も抱いてしまうもんだよ。
井の中の蛙になってそう思いこんでいるだけだよ

> さて、こんな俺がオブジェクト指向なるものを好きになれるかどうか・・・。

その頑固な性格でも無理だろうな。考えを改めないとな。アンラーンスキルによって
頭を一端リフレッシュして来い。いつもとは違う視点でものを考えてみればオブジェクト指向の利点は見えてくる。

そうですか、そういう訳で、１ページにクラスは１つしか
描かず、やたらメソッドが充実してる訳ですね。
さすが、若手ポープ、オブジェクト指向をきわめているだけあります。

私には足元にも及びませんのでとりあえず逃げることにします。失敬。

バカには何を言っても通じないのか。
メソッドの行数を減らすためにメソッドを分割した。

メソッドの数が増えた。
1クラスあたりのメソッド数を減らすために
クラスを分割した。

このとき、継承、ポリモーフィズムが使えるならそれを
使ってメソッドの数を減らすように工夫もしる。
もちろんこれは必要なときだけだ。

クラスの数が増えたからpackageでクラス群をふるいにかける。
packageが増えたらpackageもpackageでふるいをかける。
package名 + クラス名が重複しないようにパッケージ名のprefixにはドメイン名をつける。

packageやクラスが乱立したときはFacadeパターンを使って
アクセスを制限し、あるクラスのメソッドを使いたいときはFacadeクラスを通してしか
使えないようにすることですっきるさせる。
これは常識だろう。これによってモジュール間の関係が疎になることで依存度が低下することによる拡張性が高まる。

時と場合によるけどね。

↑オブジェクト指向じゃないやん。

おい、初心に戻ろうぜ

ここは「マ板のPGにオブジェクト指向を覚えさせたい！」というスレッドなんだが、
オブジェクト指向の実効性他もろもろを理解できない人間がいることが判明した。
しかも頑固で他人の考えを素直に受けようとしていない。
こういう人間は一生技術的に劣ったまま歳を重ねていくんだろうな。
なむなむ

>>790,791
高度なプログラムなんか書くより、初心者にも分かりやすい構成に
することが大事と言いたかったのである。(例が極端すぎたか)
もちろん画面数の多いシステムなら余計に、その基本構成となる部分の設計は
非常に非常に大事だと認識しているよ。
ただ、俺の中で、いまだに有用性についてしっくりこず不安になったので
カキコさせてもらった。
>>796
たしかにそうだな。すいませんね。

>>796
おい、初心に戻ろうぜ

ここは「マ板のPGにオブジェクト指向を覚えさせたい！」というスレッドなんだが、
オブジェクト指向の実効性他もろもろの説明が下手な人間が多すぎる。
論理的な説明もしないで「素直に受け取らない」と言い、さらには
「こういう人間は一生技術的に劣ったまま歳を重ねていくんだろう」などと暴言を吐く。
こっちは可能な限り素直に聞いているつもりだが。
そんな悪口を書くかわりに、「オブジェクト指向を覚えさせたい」というスレタイに沿った
理解しやすく論理的な説明をレスしたらどうか。

>>793
で、あなたはデスマから逃れられましたか？

それと同じ論理で実装まで進み、結局のところデスマ状態。
言ってることは、オブジェクト指向とはズレてる。
というのはあちこちで実証されてるな〜。
漏れは黙って逃げます。

>>785
>>ちなみに俺は、品質なんかよりも実効性を重視している。
>こんな事言うベテランは見た事がないけどな。

ま、漏れも直接見たことは無いが聞いたことはある（っていうか、よく耳にする・・・）。
たとえば↓

http://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/7bits/saredo
>時たま Common Lisp などという言語を使うこともあるが、
>それは単なるプロトタイピングだと割り切っている。
>Lisp で書かれたシステムはすべてプロトタイプであり、
>本物のシステムにするためにはＣで書きかえなければならないと思っている。

一般に "ベテラン" と呼ばれる人は皆、コンピュータとは
本質的に "計算する機械" であるという（極めて当たり前の）事が
骨身に染みているらしい。

"ACM" の 'M' が、未だに Machinery の意味を持ち続けている
というのは有名な話だ。

>>798
まあ自分で習得もできずに、2chで教えてもらうにも
教えてもらう態度を取れずにいる人は、そのまま技術的に
劣ったままでいればいいんじゃないかな。
オブジェクト指向なんて基本的なことを、未だに理解出来ない
人間が現場で働いてることは信じられないよ。

>>777
おみゃ〜よ、世の中には関数は理解できるが、クラスは理解できないPGが多いのか？
なぜ関数は使えるのにクラスは使えない？難易度は変わらないだろ？
まあクラスのほうがちょっと難易度が高いが…
その「ちょっと」の間に壁があるのか？
クラスがわからない者よ、どうだ？その「ちょっと」の間に壁があるのか？
おりはオブジェクト指向でわからないところはないので、おみゃ〜らの脳の構造がわからないわけ。
おみゃ〜らよ、そのわからないところを詳しく説明してみろ？

オブジェクト指向がわからない者よ。
またオブジェクト指向が必要ないという者よ。
おみゃ〜らよ、オブジェクト指向は確かに必要ないよ、プログラムは手続き型で十分だよ。
だがオブジェクト指向はあったほうが便利だよ。
オブジェクト指向とはそういうものだ。わかるか？
またオブジェクト指向が必要ないというおみゃ〜らよ、それを言うなら構造体も必要ないぞ！
あらゆる構造体を使う処理は変数さえあればかわりに行うことができるぞ。
変数の領域を宣言して、それを別の変数でいくつかに分割していけば構造体と同じだ。
でも構造体はあったほうが便利だろ？
オブジェクト指向もまったくそういうものだ。