5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

オブジェクト指向・嗜好・試行・至高・歯垢

1 :デフォルトの名無しさん:03/04/08 14:02
オブジェクト指向を激しく嗜好し、
オブジェクト指向を何度も試行し、
オブジェクト指向は至高のものだと考え、
オブジェクト指向は歯垢のように無駄だと思う人のスレです。


前スレ
貴様ら!オブジェクト指向を教えろ!!
http://pc2.2ch.net/test/read.cgi/tech/1047696495/

誰も立てないので立てました。
重複していましたら、削除依頼をお願いします。


2 :前スレのコピペ:03/04/08 14:06
おれもOOがカンペキでスバラシイなどとは一つも思ってないが、

・要件分析→設計までを一貫した成果物のスタイルに落とすことができ
て、他人が後からトレースするのが簡単
・クラスの分割、パッケージ分割などをきれいにしておくと、整理された
戸棚みたいに、特定機能の位置の把握がしやすい

あたりは便利だと思ってるな。
別に開発スタイルの一種だと思えば、それに従ってやるだけでしかな
いよ、折れは。仕事だし。

本読んだだけで分かった気になって、上司の攻撃に利用するマンセー
厨新入社員が大嫌いなのは、俺も同じだ(ワラ


3 :デフォルトの名無しさん:03/04/08 14:08
オロオロ(゚ロ゚;))((;゚ロ゚)オロオロ
http://hkwr.com/
http://hkwr.com/bbs

4 :デフォルトの名無しさん:03/04/08 14:08
                             /
\__________________/
         ○O
     ____,,,,,,,,,,,,,,,,、、、
    /            )))
   /    ______,,,ノ
   /    l /    \\ヽ|)
   |    | ''''''''''    ''''''''|  モワモワー
   |    | (  ・ )   ( ・ )l
   |     l        l  |
   |  ( ~         _)  |
    |   |      ,―――. l    / ̄ ̄ ̄ ̄ ̄ ̄ ̄
    l .|ヽ    ー――' /   < という夢を見たんだ
    ヾ |  \____ノ     \_______
  __/ヽ\      | l\_
 ̄     λ ヽ     / .|


5 :前スレのコピペ:03/04/08 14:16
Question
わからん・・・。
手続き型言語のサブルーチンじゃだめなの?
どこから呼び出しても使える便利なサブルーチンをたくさん作ってさ、
あとはメインルーチンからどれをどう呼び出すかだけ
プログラムすればいいようにすれコーディングは十分ラクできるじゃん。
オブジェクト指向はさらに何をラクしたくてできた言語なわけ?
よくできたサブルーチン集を作ることとの決定的な違いってなによ?

Answer1
コードの再利用とか不必要な情報の隠蔽とか利点はいろいろあると思う。
まあ特に必要を感じないんだったら従来どおりにやればいいと思うよ。

Answer2
モジュールとして完成度の高いプログラムはアセンブリ言語でも書くことが出来る。
したがって、オブジェクト指向型の言語は必須ではない。
しかし、オブジェクト指向型言語は、モジュールの完成度を高めるための支援を言語レベルで行う。
いわゆる勘違いによる間違いが減る。それだけである。が、これは圧倒的な生産性の向上を意味する。
よく出来たサブルーチンを作れる人ならば、オブジェクト指向の支援を便利に感じるであろう。
まずは良く出来たサブルーチンの条件、モジュール強度と
モジュール結合度などから学びはじめるのが良いだろう。


6 :前スレのコピペ:03/04/08 14:19
Answer3
構造化手法だけではカプセル化という概念を導入できない。

UMLかJavaの勉強をすればオブジェクト指向を素早く理解できる。

構造化手法だけでは各コンポーネント間の結合度を凝集度を下げることは
容易ではない。

各ソフトウェアコンポーネントは互いに低い結合度で結びつきあっていることが望ましい。
一つのコンポーネントは互いに関連のある責務だけから形成されていることが望ましい。

これが構造化手法の研究成果であるという。

7 :前スレのコピペ:03/04/08 14:22
オブジェクト指向の利点は、プログラムをオブジェクトと呼ばれる
ブロックに分割して開発できることだ。
だから、分担しての多人数の開発もやりやすいし、改良する場合も
必要なオブジェクトだけ変更すれば良い。

もちろん、オブジェクト指向を使わなくてもルーチン毎、ソース毎
の分割はできるわけだが、オブジェクト指向を使えばもっと見通しが
良くなり、データを不正なアクセスから隠蔽できたりもする。


8 :デフォルトの名無しさん:03/04/08 14:23
>>6
OO できる環境ならお勧めはしないけど、C の FILE * なんかはカプセル化だね。
FILE 構造体の中身は感知してはいけない暗黙のルールになっている。
言語が禁止できる仕組みを持っていないけれど。


9 :前スレのコピペ:03/04/08 14:24
例えばファイル読み込みについて書くと、
非オブジェクト指向だと、
1. "ファイルを開く関数"を呼ぶ
2. "ファイルからデータを読み込む関数"を呼ぶ
3. "ファイルを閉じる関数"を呼ぶ

オブジェクト指向だと
1. "ファイル"を表現する、オブジェクト(インスタンス)を作る。
2. そのオブジェクトに"開く"というメッセージを送る
3. そのオブジェクトに"読み込み"というメッセージを送る
4. そのオブジェクトに"閉じる"と言うメッセージを送る。

非オブジェクト指向のときは、どの関数の名前にも"ファイルを〜"と付いてる。
オブジェクト指向のときは、どの操作も"そのオブジェクトにメッセージを送る"となってる。


10 :デフォルトの名無しさん:03/04/08 14:25
>>8
で、引数に FILE * を取る関数群が FILE クラスのメンバ関数、ということになる。
まあ、わざとそんなことするのはとってもとっても不便だから、素直に class 使いませう。

11 :デフォルトの名無しさん:03/04/08 14:26
かあちゃん.おーいお茶();
とうちゃん.Getお茶(かあちゃん.Putお茶());
こんな幹事会。


12 :デフォルトの名無しさん:03/04/08 14:29
>>10
で、OO にすると、FILE 構造体のメンバ変数が File クラスの private メンバ変数になって、
FILE * を引数に取る関数が File クラスの public メンバ関数となる。


13 :前スレのコピペ:03/04/08 14:31
構造化とオブジェクト指向について結合度の観点から考えてみるよ。

構造化分析ってのは、システムを初期化処理、主処理、終了処理という
構造で考えていくことだ。それぞれの部分が、さらに
細分化されて、モジュールという単位になる。
細かく細分化されることで、確かに一つ一つのモジュールの
機能は分かりやすくなったが、解決されない問題もある。
それは結合度の問題。トップから始まるピラミッド形の構造が、
モジュールの結合を強固にしてしまっている。
簡単にいえば、処理する順番が決まっているということだな。
そこで、共通モジュールというのを抽出して、
いろんなところから利用できるようにするというのが
行われる。共通モジュールはいつでも呼び出せるので
結合度が低い。

OOは、結合殿観点からいえば、総共通モジュール化を
狙ったものととらえることができる。時系列に依存する
部分をできるだけ内側に綴じ込め、いつでもどこからでも
処理を呼び出せるようにして、結合度を低く押さえるわけだ。
つまり、OOでは構造化のようなモジュール分割ではなく、
小さなモジュールの見通しの良さを生かしつつ、逆に
オブジェクトの内部に、そのオブジェクトをうまく使うための
初期化処理(これは通常コンストラクタが担う)
終了処理(デストラクタなどが担う)
を内包させ、初期化後は自由に使えるようにしたわけだ。
発想が逆なのがおもしろいね。

14 :前スレのコピペ:03/04/08 14:35
「オブジェクト指向」とは、あくまで考え方。
その考え方に基づいたプログラム手法がオブジェクト指向プログラミングであり
同様な設計手法がオブジェクト指向設計。同様に分析手法が(略

で、オブジェクト指向という考え方がどういうものかというと、
「オブジェクトを単位に物事を考える」こと。

オブジェクトとは、内部に状態を持ち、その状態により振る舞いが変わる。
その振る舞いの結果、(自分自身も含めて)他のオブジェクトにメッセージを送る。
メッセージを受けたオブジェクトは、そのメッセージに対応した
状態変化を起し、あらたな振る舞いの結果、またメッセージ送信が行われる。

これが基本。


15 :前スレのコピペ:03/04/08 14:37
レーザープリンタでもドットインパクトプリンタでもサーマルプリンタでも
インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
プログラム上からは全部プリンタとして扱うことができる。

もちろんそれ以外の方式を採用したプリンタがでてもプリンタとしての
インターフェースを持っていれば同様に扱うことができる。
プリンタとして扱って欲しければプリンタのインターフェースを備えればいい。

レーザープリンタはプリンタとして汎用的に使うこともできるし
レーザープリンタとして特有の機能を使っても良い。


16 :前スレのコピペ:03/04/08 14:40
(問いかけ)
犬とかネコとか山田さんとかそういうことは理解できるんだけど
それを実際のアプリ製作に当てはめようとするとどうもいまいちわからない。

作成するアプリを書いたら、どういうクラスが必要かをレスしてくれるスレはないかなあ

(レス)
激しく同意。

俺の場合も、逝く度かの渡来&エラーを繰り返して、今も試行錯誤してる途中。
学の無い者による独学ほど非効率なものは無いと痛感。人生死ぬまで修行僧(意味不明

例えば経理システムをOOでどう構築しようかと(経理知識ゼロの俺が)思案してるんだけど、
とりあえず、最終出力たる各種帳票ごとに、対応するクラスをまず作ろうかと思ってる。
この各帳票に対応するクラスを「すごろくのアガリ」と考え、経理のネーチャンが端末から
各種データ(おそらくこれもクラス化の対象になるだろう)を入力してから「上がる」までに
どのような処理が必要かを考え、各種クラス・メソッド・DBレイアウト等をぼちぼち追加していく。

粘り強くやっていけば、いつかはパライソにたどり着くという目論見だが、多分この辺の
要件分析からクラス設計までの話は、学術的・体系的に確立されたものがあるような気がする。
2ちゃんねるではあまり見かけない気がするけど。

17 :前スレのコピペ(16の追加):03/04/08 14:42
(レス)
ただし、道筋に沿って最終目標へ近づけていくアプローチ自体は
むしろ構造化手法そのものなんじゃないかと悩み中。

いくつかの道を辿っていくうちに、以前設計したクラスと似た構成の
クラスが必要になったり、あるクラスの一部分の構成を別クラスとして
切り出して、他クラスにも持たせる必要が出てきたりすると思う。

そのときには、共通関数や共通モジュールのような「単なる共通系〜」を
作らないように気をつけてる。「オブジェクトとして表現すべきものか」を考えてる。
言葉にするのが難しいので、「この辺はやってみて、体で覚えて」としか言えない
のが心苦しいんだけど。


18 :前スレのコピペ:03/04/08 14:44
業務だからOOなんでは?
OOは大人数、大規模プロジェクトで複数の人がコードを参照し
仕様変更による改良・改変しデバッグをしやすいというのが売りなんだから
リバーシのような個人が数日で作れるようなソフトではプロセスをそのまま
コーディングする非OOの方が慣れてる人が多い分、早くても自然だと思います。
コードの量が増えるにしたがってOOが有利になると思います。

改良・改変・デバッグに費やす時間(ソースの量Nの増加として)
非OO:OO = N:Log N って感じかと。


19 :デフォルトの名無しさん:03/04/08 14:46
かなり抽象的な質問で申し訳ないが、
プロパティとアトリビュートってどう違うの?


20 :あぼーん:03/04/08 14:48
   ,.´ / Vヽヽ
    ! i iノノリ)) 〉
    i l l.´ヮ`ノリ <先生!こんなのがありました!
    l く/_只ヽ    
  | ̄ ̄ ̄ ̄ ̄|
http://saitama.gasuki.com/koufuku/

21 :前スレのコピペ:03/04/08 14:53
非OOで新規開発するのと、OOで新規開発するのは、若干ながらOOで
開発するほうが工数がかかると思う。ただ、OOで最初から開発しておけば
後々の拡張を考えたとき、非OOよりは工数が少なくなると思う。

非OO、OOとも、まともに設計されていれば、だけど。
ただ両者の差がどれくらいになるかはつまるところ開発要員によるわけで。
あまりどっちがどうのと優劣をつける問題でもないような気がする。人的な
問題のほうが手法的問題よりはるかに大きい。

優劣を論じたり、OOは使えないとか非OOは古いとかっていう二元論に
持ち込もうとする人間が最大のガンなんだろうと思う。


22 :前スレのコピペ:03/04/08 14:57
Question
インスタンス変数をpublicで直接いじるのでは
なく、privateにして、setter、getterメソッドで
アクセスさせる方法が定石なのはなぜなのか、
違い(というか、できたらからくりも)
お前ら教えてください。

Answer1
そうしておくと、そのオブジェクトの変数を変更しようとする人は、
必ずメソッドコールしてることになるでしょ。

そうすると、誰がいつ変更しようとしたかが分かるわけさ。
ワケワカランとんでもない値入れようとしたら拒否してみたり、変更の履歴
を取ったり、そういう仕事をメソッド内部に追加できるわけさ。
でもって、そういうものを追加しても、(メソッドシグネチャは変わ
らんので)ユーザに迷惑掛けないわけさ。

誰がいつどのように変更して、整合性の取れない状態変数の集合に
なっても全然かまわないクラスなら、全部変数publicでもかまわない
けど、普通クラスに複数の変数を宣言するときって、それぞれの変数
が全部"なんでもいい"って事は、ないことが多いでしょ?

Answer2
publicな変数を1つ使って実現していた機能が、変数2つに変更したいとする。
外部から直接変数を操作していると、操作する個所すべてに修正を入れる
必要がある。1箇所2箇所ならいいが、数百箇所もあったらバグるのは目に
見えている。

setter/getterメソッドを使って実現していると、メソッドの呼び出し形式が変更
されない限り、変数の操作はクラス内部に隠蔽される。よって、変更箇所も
クラス内部だけですみ、修正工数もバグも激減することになる。


23 :デフォルトの名無しさん:03/04/08 14:57
> レーザープリンタでもドットインパクトプリンタでもサーマルプリンタでも
> インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
> プログラム上からは全部プリンタとして扱うことができる。
つまり、端末からだろうが、どっかからのパイプからだろうが、
リダイレクトされたファイルだろうが「標準入力」として扱える
UnixってOO指向的なんですか?

24 :前スレのコピペ:03/04/08 15:03
オレルールで開発するのが楽なのは当たり前。
OO だと既存の開発プロセスや設計手法が沢山あり、
それに従って開発するのが OO だと思われているので、
不適合なプロセスを選択すると不自由を感じながら開発することになる。



25 :前スレのコピペ:03/04/08 15:04
オブジェクト指向のオブジェクトとは物体ではなく、対象・目的という意味合いが強い。
解説書には「物として扱う」などとかかれているが、それは微妙にニュアンスが異なる。
「対象として扱う」と記述したほうがより理解が進むであろう。

漏れはオブジェクト指向は目的思考とでも言ったほうが良かった気がする。
objectとまったく同じニュアンスを持つ日本語が存在しないために
苦肉の策としてオブジェクトというカタカナを使ったのだとは思うが、
物体思考だと勘違いする香具師がいかんせん多すぎはしないか。

26 :前スレのコピペ:03/04/08 15:05
いや〜、今日、死ぬほどたくさんのプリミティブ値の配列を準備して、全てその
配列への操作と大量のスイッチ文でプログラムを実現する、「根性の賜物」ソー
スを追う羽目になりまして、「ああ、コレ作った奴がOOをちょっとでも知ってたら、
オイラも楽だし、作った奴も楽だっただろうにな〜…何がなんだか分からんよ つд`)」
と思ったのデス。

根性なしのオイラからみると、作者はある意味えらいとおもうんだけど、その根性
をすこしでも情報収集に向けてくれてれば…


27 :前スレのコピペ:03/04/08 15:14
多態性というよりも、グルーピングといったほうがピンと来そうだけど……

せっかくオブジェクトとしてそれぞれ独立させたんだったら、相手の
オブジェクトのことは(必要最低限のこと以外は)知らなくても良いように
したくない?

多態性があると、『このオブジェクト群には、こう命令すれば動いてくれる』
といった感じに何種類かのオブジェクトをひとまとめにして取り扱うことが
できるので、そのオブジェクト群を使うオブジェクトが、そのオブジェクト群を
個別に扱う必要が無くなる->オブジェクトがシンプルになる。という訳。
wigetなんかの設計をするときに多態性がなかったら死んでますな………

#さらにこの考えを推し進めると、もっと便利になるよ。
#Rubyだと、そもそも同じ名前のメソッドだったら、継承関係の無い
#オブジェクトでさえも同じように扱える。

このへんは現実世界でも良くあることで、例えば
・テレビ用のリモコン
・AVコンポ用のリモコン
・エアコン用のリモコン
なんかは、とりあえずpowerボタンを押せば、それぞれの装置のことを
あまり詳しく知らなくてもスイッチを入れることができるよね。
多態性って、そのあたりのメタファーなんじゃない?

28 :前スレのコピペ:03/04/08 15:14
つづき
次に逆の方向になるけど、次のようなケースも多態性が必要になるケースですな。
すでにできあがっている/作りかけのシステムに機能(仕組み)を追加したくなった。
その機能は全く新しい機能なので、既存のオブジェクトを調整するだけでは
実現できないけど、機能を実現するための仕組みは従来のオブジェクトを
操作する方法を利用できそうだ。
(実際うまく設計できれば、様々な機能を同じ仕組みの上で実現することができる)

そこで、『このオブジェクト群と同じ命令を受け付ける様にする』すなわち多態性を
利用することによって、既存のシステムの仕組みを変更することなく新しい機能を
追加することができる。
こっちのほうがいわゆる『多態性』になるのかな?

このへんも現実世界で良くあることで、タイプライターとコンピュータのキーボード
なんかは良い例ですな。

つまり、多態性によって『機能』と『仕組み/操作方法』を分離することができるつうのが
『多態性』を重要なものにしている要因だと思うんだけど、どう?


29 :前スレのコピペ:03/04/08 15:19
Question
OOを採用したプロジェクトがなかなか成功しない
と言われる原因は何ですか?

Answer
全体的にプロジェクト自体の規模が大きくなり、予算・納期は縮小する傾向が
あるので、プロジェクトが成功しにくくなっているというのがある。
だから、OOを採用してなければ成功していたかというと、難しい。

また、新技術にはやはりリスクがあるので、OOを採用したからといって
最初からその利点の恩恵にあずかれるものでもない。

ただ言えるのは、最近の開発で成功しているプロジェクトは
OOを採用している割合が高くなっている。

30 :前スレのコピペ:03/04/08 15:20
ちなみにDelphiでやってた"継承"というのは、
画面フォームの提示様式とボタンの機能を統一するため、
最小限の基本機能(画面の見た目、パネル分け、PFキー、確認ボタン類)をクラス定義して、
各アプリはそのクラスを利用して造り込んでいく、というものです。

この時問題になったのは、クラス内部の(結果的に)冗長的な一機能が、派生先の仕様によっては足枷になる場合が開発末期に生じたという事です。
また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず独自に別個の関数をダラダラ書きやがったという問題もありました。
(俺も書きやがった一人ですが) …まあ、その程度の経験しかないす。

オブジェクト指向って、決して同一ではないが似たような手続きを複数箇所にダラダラ書くのはダサイから、
一つにまとめて能率よく処理できるよう工夫を凝らそうといったものになるんでしょうか。
ある種ゲージツ的センスで意見が分かれそうで集団開発にどこまで向いているのかちと疑問にも思ったりします。
ちゅーか、それこそ"指向"に左右されるのだなぁなんてね。

31 :前スレのコピペ(30へレス):03/04/08 15:20
そういう観点で言うなら、いかにプログラムを分割して
関連のあるものを近いところに、関連のないものを遠くにおくか、とか
まとめて変更する可能性のあるものをいかにまとめるか、とか。

だから、集団開発、という点でいえば、おおきなプログラムを
集団で作るときに、ある機能を担当している人が作るプログラムが
他の機能を担当している人のプログラムの影響を受けない・影響を与えない
ようにという方向で設計ができる、という点でオブジェクト指向が良い。


コードが似ている・似ていないが判断基準になるのではなく
概念的に似ている・似ていないが判断基準になる。
結果的には、コードが似ている・似ていないでまとめることになる場合が多い
のだけど、それは結果論。

ある時点でコードが似ているからという理由でまとめると、あとで泣く。


32 :前スレのコピペ:03/04/08 15:24
(問いかけ)
まあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。

(レス)
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな?となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。

33 ::03/04/08 15:27
とりあえずコピペまとめは終了です。
準備不足ですみません。


34 :デフォルトの名無しさん:03/04/08 15:34
まとまりすぎてこのまま終了の予感

35 ::03/04/08 15:37
>34
オレもそういう予感がした。。。。
突っ込む余地を与えるのも大事なんだな。。。。。
トホホ。。。。。


36 :デフォルトの名無しさん:03/04/08 15:37
乙>コピペ


37 :デフォルトの名無しさん:03/04/08 15:47
>>23
UNIX の設計は OO 風だと思う。
process が fork で増えてく仕組みなんかは prototype based OO そのものだし。

38 :デフォルトの名無しさん:03/04/08 17:04
オブジェクト最高!
Object Saiko!
Object Siko
オブジェクト指向

39 :デフォルトの名無しさん:03/04/08 17:05
なぁ、教えておくれよ。
プロパティとアトリビュートってどう違うの?


40 :デフォルトの名無しさん:03/04/08 17:18
>>39
prop・er・ty
━━ n. ((集合的)) 財産, 不動産(物件); 所有物; 所有地; 所有(権), 著作権; 特性; 【劇】小道具.
man of property 資産家.
prop・er・tied ━━ a. 財産のある.
property dividend 【金融】現物配当, 物品配当.
property insurance 【保険】財産保険, 財物保険, 損害保険.
property man 【劇】小道具方.
property tax 財産税.
real [personal] property 不動産[動産].


at・trib・ute
━━ vt. …に帰する, …のせいにする; 作者を…であるとする.
━━ n. 属性, 特質; 象徴; 標識; 【文法】限定詞.
at・trib・ut・a・ble
 ━━ a. …に帰せられる, に起因する ((to)).
attributable profit 帰属利益.
at・tri・bu・tion ━━ n. 帰属, 帰因; 属性; 職権.
at・trib・u・tive
 ━━ a., n. 属性の; 【文法】限定的な; 限定詞.
at・trib・u・tive・ly ad.


41 :2ch過去スレのコピペ:03/04/08 17:19
OOP教えるなら抽象論から入らないで型進化論的アプローチで
OOPしないことのデメリットを教えたほうがわかりやすいと思うんだけどね。

int x, y;
x += 1; y += -2; PutPixel(x,y);

 ↓構造体導入
typedef struct{
 int x, y;
} Pos;
Pos p;
p.x += 1; p.y += -2; PutPixel(p.x, p.y);

 ↓データ抽象化
typedef struct{
 int x, y;
} Pos;
PosMove(&p, 1, -2); PosShow(&p);

 ↓カプセル化
typedef struct{
 int x, y;
 void Move(int dx, int dy){
  x += dx; y += dy; Show();
 }
 void Show();
} Pos;
Pos p; p.Move(1,-2);
 ↓ポリモ以下略


42 :40:03/04/08 17:20
特性と属性で良いんじゃないかな?
特に分けては考えないけど、あえて分けるとしたら
 Property=特性=オブジェクトに影響を与える(影響が大きい)
 Attribute=属性=オブジェクトに影響を与えない(影響が小さい)
こんな感じかも? とおもう。


43 :2ch過去スレのコピペ:03/04/08 17:27
もし神がプログラミングするなら、OOは使わないだろうな。
どんなに巨大なプログラムでも全体から詳細まで把握してプログラムできるなら、
OOで無駄なポインタのやり取りなどせず書いたほうが効率がいいだろう。
でも自分は人間だから、脳内スタックがすぐ足りなくなるので
どうしても OOに頼らざるを得ない。

44 :デフォルトの名無しさん:03/04/08 17:27
はげしく勉強になるのでもっと書き込んでください。

45 :2ch過去スレのコピペ:03/04/08 17:37
(オブジェクト指向に)既存の手法に対する全く新規なアドバンテージもないと思う。
なら、何がいいのかというとトータルでは扱いやすいってこと。
むしろ既存の手法にあった色々な考え方を
カプセル化や継承なんていう基本語彙で表現しやすくしたのがでかい。

46 :2ch過去スレのコピペ:03/04/08 17:43
(オブジェクトとは)
元の対象とする事象 と それを認知した頭の中の model との間、
頭の中の model と それを自然言語で記述したもの との間、
および、自然言語で記述したもの と それを Programming Language で表現したもの
との間 での traceability を指している。

47 :2ch過去スレのコピペ:03/04/08 18:13
ライブラリのドメイン依存性(ある特定の問題領域の解決にどの程度特化しているか)や
粒度の大きさ(抽象度と言い換えてもいい)を再確認しよう。
依存性が高いか、粒度が小さいならば再利用が難しいのは明らか。

二つの戦略がある。(粒度の使い方が適当でないかも)

・再利用性を高めるためにドメイン依存をなくし、粒度を大きめにとる
・生産性を高めるためにドメインに特化し、粒度も適当に小さくする

はっきり言って前者は相当しんどい。
標準クラスライブラリ並みの作りこみが必要だし、
どうしたってドメインに依存せざるを得ない
(比較的依存しない部分は標準クラスライブラリでほとんど賄われているわけだし)。

だからデザインパターン(作り方・設計)を(再)利用して、
実際に作るのは後者でいいやんというのが現状。
実装の継承による差分プログラミングが有効なのは
もちろん親子直系のクラスツリーを作るときだけだよな。
それって結構範囲が狭い。

48 :2ch過去スレのコピペ:03/04/08 18:21
Question
GoF本とかじっくり読んで、部分部分はそれなりの設計ができるように
なったので、試しに一本ツールを作ってみたのですが…。

関連を増やすことを恐れるあまり、部分部分を繋ぐ部分がどうしても
MediatorかObserverっぽくなっちゃいます。つまりものすごく多くの
クラスと関連を持つ頭でっかちな中心クラスが一つ出来てしまうんです。

部分の再利用性は抜群ですが、中心クラスはそりゃもーむごいもんです。
この、設計の最終段階を解説してくれてるような良書ってありますか?
GoF本の2章も仕上げの部分が省略されてていまいちでして。


Answer
「中心」なんてものを出来るだけ無くすようにするのが吉。
芝居だって主人公が(あなたが言う意味の)「中心」である
わけじゃないでしょ?

注:OOPの古典的理論に「アクター(俳優?)理論」ってのが有るらしく。

つまり、
>MediatorかObserverっぽくなっちゃいます。つまりものすごく多く

この部分に「つまり」という単語が出るところが敗因。
もしかしてMediatorやObserverを中心に据えようと
していないっすか?
駄目っすよそのスタイルは。VB/Delを厨房がいじるのと
同じなんだから。(ナニも考えずにあの手のRADを使うと
Formに書く処理が爆発的に多くなる)

49 :2ch過去スレのコピペ:03/04/08 18:25
オブジェクト指向を使うと、凄く楽になったという実感があるよ。
ただ工数が減ったかといわれると微妙。
速く作れるようになったと言うより、
確実性が増したと言うべきか。

例えば、「こりゃ複雑すぎてメンテできん、
手も足も出ない」っていう状況はほぼなくなりました。
ドキュメントが無い状態でも、クラスを見れば、
おおよその働きは理解できます。
危険な操作はできないように隠蔽できるので、
アクセスのエラーが出たら、
何かしてはいけないことをしたのだという目安になります。

50 :2ch過去スレのコピペ:03/04/08 18:51
自分もOOPL覚えたての頃はクラスライブラリをべたべたと利用する だけで、
いわゆる「open~closeを並べる」タイプだったです。
でもしばらくしてからプログラムしている内容をオブジェクトに切り 分けて、
そのオブジェクト間のメッセージのやりとりという観点から 自前でクラス階層を構築する、
という作業をしてみると以前よりずっと 実際の問題に近いレベルでプログラムを構造化(?)できるなあ、
と 感じるようになりました。
openだとかcloseだとかは自分のつくったクラスのもっと具体的な名前 のメソッドのなかに隠されて
外からはすぐに見えなくなると思うのですが

51 :2ch過去スレのコピペ:03/04/08 18:54
オブジェクト(役割単位での分割)とモジュール(機能単位での分割)は区別して考えないと。
モジュールは管理している属性が不明瞭だし、操作する対象も不明瞭のままです。
そこを明らかにすることに価値を見出すのがオブジェクト指向かと。

52 :デフォルトの名無しさん:03/04/08 19:45
2chでも書くやつは書くね。


53 :2ch過去スレのコピペ:03/04/08 19:46
・多態が強力な一般化・抽象化の手段である。
・多態は静的な型チェックと動的なlate bindingを両立させる。
・late bindingによって実装を隠蔽したままオブジェクト間の組合わせを変え
 る自由度が得られる。
・late bindingによって「インターフェースのみを決めた」プログラミング、
 たとえばさまざまなデザインパターンが可能となる。

…のは確かなんだが、肝心なのは抽象化であって多態やlate bindingはその
手段じゃないかなあ。


(レス)
これらの意見は、一見、OOの利点に聞こえるが(実際、利点だが…)
この中にある『「インターフェースのみを決めた」プログラミング』が問題。
OOの利点を生かすためには、<インターフェースのみを先に設計する>という
前提が必要になるのだが、実際にはこの部分の実践が難しい。

54 :2ch過去スレのコピペ:03/04/08 19:58
OOになって、デザインパターンが出てきて、なるほど頭いい人は
こうやってコーディングするのだなあって思った。抽象化された
コアを作り込んで、具象化はなるべく後にする。そうすることで
問題の本質が見えてくるし、コードの再利用も進む。

頭いい人の手法を「再利用」できるようになったことは、OOによ
る恩恵だなあ。構造化プログラミングの時代には、データ構造+
アルゴリズム=プログラムだったから、ついついすべてのコード
がそのプログラムで解決したい具体的な問題に「べったり」なも
のになりがちだった。似たような、しかし、ちょっとずつ違うコー
ドを大量に書いた。いつもデバッグばかりしていた。それがOOに
なって、デバッグの済んだコードを再利用するケースが増えてき
た。デザインパターンまで来て、ようやく得られた恩恵だけど。

デザインパターンを知らないでいると、OOなんてちょっと気の利
いた(しかし、けっこう面倒な)モジュール化技術にしか見えな
いだろうな。

55 :2ch過去スレのコピペ:03/04/08 20:04
オブジェクト指向は複雑な物をシンプルにするのが得意。
すでにシンプルな物をよりシンプルにするのは苦手というか、効果が薄い。
そういうところはアルゴリズムにまかせたほうがいい。
有用な技術だけど、すべてにおいて効果を発揮する万能薬じゃないのだよ。

会社組織にたとえれば、2〜3人の小さな組織で備品購買担当を決める意味があるのか。
こんな小さな組織で下手に担当を決めるとかえって窮屈になる。
だから3目並べやテトリスくらいでは、デメリットばかりが目立っていい例はあげられない。
しかし大きな組織になったら担当が必要になる。
100人の社員が好き勝手に備品を買ってきたらえらいことになるし、
管理するのは大変だから担当を決めて、決済や稟議というメッセージを仲介し、
購入という操作や、予算という属性を隠蔽する必要が出てくる。
組織を知ればオブジェクト指向は見えてくる。

56 :2ch過去スレのコピペ:03/04/08 20:06
あまり一般的な分類だとは思えないなぁ。255 さんとかぶるけど、

OO=オブジェクト指向:思想。ポリシー。対象を特に選ばない。
OOA=オブジェクト指向分析:OOに基づいた問題領域の分析工程。
OOD=オブジェクト指向設計:OOに基づいた(ソフトウェアの)設計工程。
OOP=オブジェクト指向プログラミング:OOに基づいた実装工程。

クラスとかインスタンスという概念はOOでよく見られる一つのパターンであって
OOAやOODだからクラスでOOPだったらインスタンスというのは変だよ。
プロトタイプベースの言語だったらクラスないし。
クラス間ならぬインスタンス間の関係を設計段階では扱わないかと言えばんなことないし。

57 :2ch過去スレのコピペ:03/04/08 20:20
おそらくあなたは、「コードの把握しやすさ」は理解できても
「ソフトウェア構造の把握しやすさ」という概念は理解できていないのでは?

共通部分を括り出すだけでは自分用関数ライブラリと変わらない。
デザインパターンは、ソフトウェアを開発していると良く出くわす
*設計上*の問題とその解決法に名前を付けたもの。
名前があるおかげで、
「これはfactoryパターンでやるといいんでない?」「あ、なるほど」
というやりとりができる。
まあ、みんながパターンを知ってないと共通語彙として使えないから
まだまだ浸透するには時間がかかるだろうけどねえ。

58 :2ch過去スレのコピペ:03/04/08 20:22
ここにいるOOマンセーな皆の会社ではOO、デザパタなんぞ常識レベルなの?
俺もOOマンセーなんだけど、引継ぎで

俺「ここの状態遷移はStateパターンそのままで・・・」
相手「ハァ?すていとぱたーん?」
俺「個々の状態を、AbstractStateクラスのサブクラスで定義して・・・」
相手「ハァ?クラス?構造化プログラミングの言葉でいうと何?」

てなことがしょっちゅうなんだけど。

思うにOOの弱点は
・OOへの理解が浅い人間が設計するとどこまでもひどくなりうる。
・もともとの設計がまともでも、OOへの理解の浅い人間がソースを引き継ぐと
理解できない、またはどこまでもひどくなりうる
・上記2点にもかかわらず理解を深めるのが難しい。(このスレの混乱振りを見れば明らか)

つまり、フールプルーフがなってない。
よって、設計・実装・保守を行う者と、利用者が明確に区別できる場合
(たとえば自分用クラスライブラリや、商用クラスライブラリや、長期に渡って
同一人物やチームが保守することができる場合など)のみしか有効でないと
思うんだがどうよ?

#OOへの理解が浅いのはオレモナー

59 :デフォルトの名無しさん:03/04/08 20:26
クラスってアクションゲームとかだとどういった使い方をしますか?敵キャラのオブジェクトとかマップのブロックとか?とかですか?っていうかクラスってなんですか?

60 :前スレのコピペ:03/04/08 20:34
オブジェクト指向が特に便利というわけじゃなく、
その周辺に用意されたものが、たまたまニーズに
合ってるだけかもしれない。
オブジェクト指向は「狼の皮を被った羊」なんじゃないのか、と。


61 :前スレのコピペ:03/04/08 20:34
おまえら「オブジェクト指向」に騙されてるぞ。
「オブジェクト指向」と一括りにされて、うやむやにされた技術は、
実はほとんどが「オブジェクト指向」とは全く関係ないものばかりだ。
俺達は「オブジェクト指向」という言葉に踊らされているのさ。

62 :前スレのコピペ:03/04/08 20:35
>>61
なんかこれ、真理を突いてるっぽい。
初心者がプログラムするときなんか、メッセージなんて概念は
頭に出てこないだろうし。最近の言語の傾向見てると、
純粋な「オブジェクト指向」という意味自体も消えかかってる。

63 :前スレのコピペ:03/04/08 20:36
へんなちゃちゃが入ってるようだけど、オブジェクト指向のおかげで
プログラムをあまり勉強しなくても、ある程度部品を組み合わせれば
ある程度のものができるようになっている。

あと、>>60の言うような「周辺に用意されたもの」の多くは
オブジェクト指向を核に研究開発されている。
それは情報処理学会誌なんかを読んだ感想。

64 :前スレのコピペ:03/04/08 20:36
>>63
>オブジェクト指向のおかげで
オブジェクト指向のおかげじゃない。
オブジェクト指向の周辺技術のおかげだ。

65 :前スレのコピペ:03/04/08 20:37
>>63
>部品を組み合わせればある程度のものができる
これはオブジェクト指向とは何の関係も無いな。

66 :前スレのコピペ:03/04/08 20:41
>>60
なるほど。
多態や継承とかは、別にオブジェクト指向でなくてもできるよな。
純なオブジェクト指向つーと、メッセージ受け渡し程度だから、
まあ無くてもいいわな。

67 :前スレのコピペ:03/04/08 20:42
>>61
となると、純なオブジェクト指向=メッセージング程度という>>66の意見と、
オブジェクト指向の周辺技術がニーズにあっているという感覚からすると、
少なくとも俺はオブジェクト指向の派生物を便利便利と言っているわけで、
そうなると俺は何指向だ?オブジェクトデリバティブ指向とかか?

68 :前スレのコピペ:03/04/08 20:42
庶民はとくに指向でなくてよい。

69 :前スレのコピペ:03/04/08 20:43
>>68
まあ、確かにそうかもしれん。
でもやっぱりプログラムするときはいつもインターフェース
意識するから、しいて言うなら俺はインターフェース指向かな。
オブジェクト指向ではないことは、>>60の発言で確定したし。



70 :前スレのコピペ:03/04/08 20:43
まあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。

71 :前スレのコピペ:03/04/08 20:44
>>70
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな?となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。

72 :前スレのコピペ:03/04/08 20:46
>>71
そんなとこだと思う。
オブジェクト指向だけが全面に出てくる今の状況はおかしい。
理系の考え方じゃない。

73 :前スレのコピペ:03/04/08 20:46
>>72
エンジニアリングは理系じゃないからね。

74 :前スレのコピペ:03/04/08 20:49
>>82
同意。
オブジェクト指向の本はあんなに分厚い必要はない。
なんつーか、うまく分離できないものかね。





とまあ、この辺の話に興味があるので、レス番編集してコピペしときます。
煽りっぽい発言は省いてます。意味通じないかも。
というか今更だけど、

貴様ら!オブジェクト指向を教えろ!!
http://pc2.2ch.net/test/read.cgi/tech/1047696495/957-

とした方が良かったかも。

75 :1:03/04/08 21:01
まだ過去スレからコピペしたいものが一杯あるんだけど。。。
切りがないのでここらでコピペは一旦終了です。

>60-74はオレじゃないんで。(分かるだろうけど)

2chもノイズが多いけど、まとめると凄いためになるんだなと実感。


76 :デフォルトの名無しさん:03/04/08 23:42
>>1
お疲れ様です。
ワタシが勤めてるトコは、メーカーの情報システム部門で、
OPEN系の開発経験が浅いんです。
(VB、ASPとかくらい)
で、外部からも、Web系の受注を取りたいってことで
オブジェクト指向を取り入れる?ってことらしいんですが、
SEの平均年齢は40代後半、ちゃんと設計できるのかしら?

・・・このスレに堂々と書き込めるほどには、
オブジェクト指向を理解していないのでsage


77 :デフォルトの名無しさん:03/04/09 00:13
>>76
受注するのはいいが、オブジェクト指向はやめとけ。

78 :デフォルトの名無しさん:03/04/09 09:13
OOと非OOって1か0かじゃないよね。
PC上で作業する以上少なからずOOの要素は含まれていると思う。
100%完璧なOOも100%非OOも多分実用的じゃない。

79 :デフォルトの名無しさん:03/04/09 14:48

オブジェクト指向がいいとか悪いとか、もうどうでもいいんだあああ!!!

クラスの洗い出しがうまくなるコツをご教授してくれえええええ!!!


80 :デフォルトの名無しさん:03/04/09 15:12
思い切って1モジュール1クラスにしてみては?

81 :デフォルトの名無しさん:03/04/09 15:35
>>76
そのSヨがASPにはM$のASPと、ビジネス形態としてのASPの2種類があることを
知らずにASPASPっていってるのならあきらめたほうがいいね。


82 :デフォルトの名無しさん:03/04/09 15:38
                                                                                                                  



























83 :デフォルトの名無しさん:03/04/09 16:23
ASP = Advanced HSP

84 :デフォルトの名無しさん:03/04/09 16:30
どこにもHが見当たらないんですが。
ASP = Anal Sex Play

85 :1:03/04/09 16:41
ネタはこちらでお願いします。

貴様ら!オブジェクト指向を教えろ!!第2章
http://pc2.2ch.net/test/read.cgi/tech/1049857221/


86 :デフォルトの名無しさん:03/04/09 20:25
ここがネタスレ?

87 :デフォルトの名無しさん:03/04/09 21:39
>>1
おつかれ。てかグッジョブ。
>>79
インターフェースだ。インターフェース指向だとわかりやすいだろ?



88 :デフォルトの名無しさん:03/04/11 20:34
Javaで何か作るときは大体、インターフェースだけで先に骨格を組む。
で、各部品の叩き台みたいなのを作って動作を確認する。
正しく動いてさえいれば完成したつもりになる。
その後、部品をチューンして性能を上げたり、
インターフェースを継承して機能追加したり。

趣味プログラマからみたOOの利点は
妙なバグを出さずに改造を長く楽しめること。
気分はWIZとかのキャラ育ての延長なんだな。

89 :デフォルトの名無しさん:03/04/12 07:33
最初の方(5〜20あたり)、少しだけ読んだんだけど、説明(言い回し)が洗練されていて、
プロの文章に見える。
テクニカルライタさんでつか?

90 :2ch過去スレのコピペ:03/04/12 11:10
今度の論点は、継承の事か。
こちらの方が、深く根深い問題だな。
継承したら、子クラスは親クラスのインタフェースを必ず
すべてサポートしなければいけないのが、嫌なんだろうな。
階層の下に行くにつれて、インタフェースがどんどん大きくなっていって、
ある時点での子クラスは、その子クラス自身が使われる問題領域では
恐らく使わないであろうインタフェースまでサポートしなければいけないのが納得いかない…と。

これは確かに歯がゆいねぇ。
(1)子クラスが親クラスのインタフェースを全て扱えることを保証
(2)あるクラスが必要最小限のインターフェースをサポート
の2つの要求のどちらが優先か、にかかっている。
普通は、1>2の場合継承を使い、1<2の場合委譲を使う。
実装階層とインタフェース階層を別に用意して、
TPOに合わせて(?)インタフェース階層をいくつも作ったりとか…。
ここら辺が気持ち悪い?

91 :2ch過去スレのコピペ:03/04/12 11:13
クラスを「利用する側」と「提供する側」の永遠のジレンマですな.
利用する側:クラスは「自分の」プログラムに適したものが欲しい
提供する側:クラスは「利用者すべての」プログラムで使える様にしたい
つうことで,利用者は最適性を,提供者は汎用性を追い求める……と
結局,両方とも追い求めているものが違う訳だからねぇ.

通常だと継承とかしてクラスのカスタマイズをするわけだけど,
隠蔽という概念を尊重するのならばあまり無茶はできないし……

利用する側:
 カスタマイズ「したい」部分をカスタマイズすれば最適化を行える
 しかもそのカスタマイズは未来永劫利用できることを保証されている

提供する側:
 ユーザーがどのように利用していようと,ユーザーに影響を与えずに
 クラスのカスタマイズができる.

つうのは理想だなぁ.両者が好き勝手やるとなんにもできないので,
結局契約で縛る必要があるんだけど……

……デザインパターンとかフレームワークとかの話になるのかな?

92 :山崎渉:03/04/17 15:30
(^^)

93 :デフォルトの名無しさん:03/04/17 19:02
age

94 :public ◆PmQxVjGtl2 :03/04/17 19:11
Javaのデザインパターン!

95 :山崎渉:03/04/20 03:14
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

96 :デフォルトの名無しさん:03/04/21 00:47
そもそも、本当のオブジェクト指向ってなんなんですかね?
なんかいい本ありまつか?
C++から入ってしまった俺としては、C++≠OOは遠すぎるけどC++≒OOではないよなぁというぐらいの
認識しかないんでつけど。

97 :デフォルトの名無しさん:03/04/21 01:03
>>96
Smalltalk だよ。


98 :デフォルトの名無しさん:03/04/21 01:04
>>96
C++ でも、コンストラクタ以外、つまりデストラクタとメンバ関数をみんな virtual にすれば、
かなり良質な OO になる。


99 :デフォルトの名無しさん:03/04/21 01:12
iostreamは、多重継承あり、実装継承あり、インターフェース
継承あり、委譲(streambufへ)あり、複雑な内部状態あり、と
オブジェクト指向の好例だと思うけど。
文句を付けるとしたら、streamとstreambufの間の結合が
強すぎることだけど、これは仕方無い。

100 :デフォルトの名無しさん:03/04/21 01:12
>>98
こういう場所でねたはやめれ。

101 :とりあえずつっこみ:03/04/21 01:25
>>32 >>71 学術用途で抽象度の高かったオブジェクト指向
っていうレトリックは、何を指しているのかいなー?
アクター?

102 :デフォルトの名無しさん:03/04/21 01:46
>>100
ネタじゃねー。あたりまえのことだ。

103 :デフォルトの名無しさん:03/04/21 02:08
>>98,>>100 漏れ的にも、このスレ全体、特に>>98は不思議な違和感を覚える。最近のオブジェクト指向業界って、こんなに違和感のある意見が頻出する場所なの?

104 :デフォルトの名無しさん:03/04/21 02:14
>>103
確かに、Java のメソッドはみんな C++ でいう virtual やな。


105 :デフォルトの名無しさん:03/04/21 02:17
Java厨をまともに相手にするなよ・・・

106 :デフォルトの名無しさん:03/04/21 02:18
virtual = 動的 ってなニュアンスなのかなー。
でも、それだけで良質なOOになるとは思えないような。


107 :デフォルトの名無しさん:03/04/21 03:27
馬鹿だから、virtual にするかどうか、考えたくないんだろ。
みんな virtual なら、何でもオーバーライドできて便利♪みたいな。
オーバーライドが危険なメソッドとか、クラス丸ごと継承不可の時の効率とか、
どうでもいいんだろうな。


108 :デフォルトの名無しさん:03/04/21 06:52
>>107
C++ にはオーバーライドを禁止する言語的な指定はできないから、virtual をやめようと
なんだろうとどうにもできない。
virtual じゃなくても、子クラスとして呼び出した場合はオーバーライドした方の
メソッドが呼ばれちゃうし。

効率はリファクタリングのときに考えること。
初めから非 virtual にしたらたぶん効率がいいだろうと仮定してやみくもにする人、いるんだよね。
ちゃんと、プロファイルしてからオーバーヘッドの高い部分だけを絞り込んで、効率が上がる方法で
リファクタすること。エンジニアリングなんだから、気分じゃなくて、
測定して行うこと。


109 :デフォルトの名無しさん:03/04/21 07:01
普通は安全にしておいて、必要なところだけ穴を開けるんだよ。
こんな常識もわからんの?
パフォーマンスのチューニングは全然話が違う。
Javaはアホ用の言語だからしかたないが、それが開発の常識だと勘違いするな。

110 :デフォルトの名無しさん:03/04/21 07:04
>>109
セキュリティの話?


111 :デフォルトの名無しさん:03/04/21 07:05
ふつうはポートを塞いでおいて必要なところだけあける。


112 :デフォルトの名無しさん:03/04/21 07:06
>>109
馬鹿だなあ。Java の方が final 指定ができるからメソッドのオーバーライドを
言語レベルで禁止できるんだよ。

113 :デフォルトの名無しさん:03/04/21 07:07
>>109 は馬鹿だから、セキュリティの話で煙に巻こうとしていまつ。


114 :デフォルトの名無しさん:03/04/21 07:08
final デフォルトにしろって話でしょ。
何でもオーバーライドできるのが最高ってのはマヌケすぎると。

115 :デフォルトの名無しさん:03/04/21 07:08
ちなみにC++で、virtual じゃないメソッドをオーバーライドする奴は氏ね。
オーバーライドしちゃいけないメソッドに、バーチャルつける奴は氏ね。

116 :デフォルトの名無しさん:03/04/21 07:09
>>109
> パフォーマンスのチューニングは全然話が違う。

効率の話はそっちが最初にしてきたと思はれ。

117 :デフォルトの名無しさん:03/04/21 07:11
やっぱりJava真理教だな

118 :デフォルトの名無しさん:03/04/21 07:11
そうか。Java でやる場合は、なんでもかんでも final にしておいて、
必要になったら final をはずしていくということでつね。


119 :デフォルトの名無しさん:03/04/21 07:13
>>118
書かなければ final、必要なら virtual と書くが望ましいだろうな。

120 :デフォルトの名無しさん:03/04/21 07:22
C++ で、オーバーライドするとエラーにできるような書き方ってないかな?



121 :デフォルトの名無しさん:03/04/21 07:24
Delphi だと、オーバーライドしてもいい関数は virtual をつけて、
それをオーバーライドする段で override をつけて、それが一致しないと
エラーになる。
Java だと、final をつけたのはオーバーライドするとエラーになる。


122 :デフォルトの名無しさん:03/04/21 07:26
> Delphi だと、オーバーライドしてもいい関数は virtual をつけて、
> それをオーバーライドする段で override をつけて、それが一致しないと
> エラーになる。
理想的だね。

123 :デフォルトの名無しさん:03/04/21 16:36
finalの話とは微妙にずれるが、JavaもC#みたく
オーバーライドするときは、overrideとかのキーワード
つけるようにしたほうが便利だと思うんだが。
コンパイル時にシグネチャが合ってるかチェックできるし、
オーバーライドしてるんだって一目でわかるし。

124 :デフォルトの名無しさん:03/04/21 17:39
オーバーライドに関する認識が随分様変わりしたね。
Javaが出た頃は
「C++はvirtualをつけないとオーバーライドできない。
それに比べJavaはデフォルトでオーバーライドできる。
これこそ真のオブジェクト指向言語だ」
みたいな論調があったからね。
最近はオーバーライドに限らず、
継承一般に関して反動的(?)な意見が主流になってる。
時代による認識の変化は面白い。


125 :デフォルトの名無しさん:03/04/21 22:32
昔はC++にもoverride指定子があったよなぁ...
と思いつつ、望洋先生の本を眺めてみたけど見つからなかった。

かわりに overload 宣言子をみつけた。
overload func;
int func(int);
int func(char*);
などのように使うらしい。
きっと、これを間違って覚えていたんだな。

オブジェクト指向とは何の関係も無いので下げ。

126 :デフォルトの名無しさん:03/04/22 00:53
>96
オブジェクト指向は言語ではなくて考え方。
よく言われるけどオブジェクト指向言語はオブジェクト指向的な考え方を
支援するための道具でしかないよ。
#C++≠OO、C++≒OOという比較は、比較する質が違っているから
#あんまり意味無いと思う。

ただ、使う道具によってどのようなプログラミングをするのか制限されてしまうから、
オブジェクト指向を学習するときは正しい道具を使って学習するのが非常に重要。

C++って基本的にプロフェッショナルツールだから、学習用として使用させるのは
とても危険だとおもう。
#山の素人をいきなり冬の日本アルプスに叩き込むようなもんだよね……

127 :デフォルトの名無しさん:03/04/22 01:20
>>126
本気で学習用にするなら、大学の講義で言えば、
1年間くらい黒板と原書(笑)輪読で勉強して、
それから半年実習やって、というくらいの覚悟
でやらないと駄目だよな。

128 :デフォルトの名無しさん:03/04/22 01:29
C++厨は懲りずに必死になってJavaを馬鹿にしようとしているようだが
5年遅すぎたようだな。

いまどきJavaは遅いといっている奴は時代遅れ

129 :デフォルトの名無しさん:03/04/22 22:06
96です。思ったより話が膨らんでびっくりしてまつ。
色々と参考になりました。ありがとうございます。
一番判りやすかったのは126さんかも(w

130 :デフォルトの名無しさん:03/04/23 03:49
>>128
そういや、Java 用のネイティブコンパイラが GCC に入ったっけ?
>>128 は JIT コンパイラのことを言ってると思うのだが、
 最初の1回はどうしても遅くなるので速度的には没。
 用途的には◎だけど)

131 :デフォルトの名無しさん:03/04/24 00:38
JavaはJITのおかげでだいぶ早くなったのは認めるけど、
起動の遅さとメモリ喰いなのは相変わらずだよね。
やっぱデスクトップアプリケーションには向かないな。

132 :デフォルトの名無しさん:03/05/01 23:51
歯のシコウには、ワロタ!

もはや、オブジェクト失効か?

ところで、Lyeeってオブジェクト指向ですか???


133 :デフォルトの名無しさん:03/05/02 14:40
20倍の奴ですか?

134 :デフォルトの名無しさん:03/05/02 22:56
>>132
あれはスカラー波指向

135 :デフォルトの名無しさん:03/05/21 19:00


136 :山崎渉:03/05/28 12:54
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

137 :名無しさん@Linuxザウルス:03/06/26 23:58


138 :デフォルトの名無しさん:03/06/27 01:08
hosgu

139 :デフォルトの名無しさん:03/06/27 01:27
GeHosyu

140 :デフォルトの名無しさん:03/06/29 00:41
フーン

141 :デフォルトの名無しさん:03/06/29 07:24
Javaがアホ用の言語だと思っている香具師は、プログラミング言語Javaの第3版でも読みなされ。


142 :山崎 渉:03/07/15 10:26

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

143 :山崎 渉:03/08/02 02:53
(^^)

144 :デフォルトの名無しさん:03/08/11 20:03
成功する設計では継承よりもコンポジションが多用されるようなことを聞いたんですけど
コンポジションってのは確か has-a のことですよね?結局昔からの設計のほうが仕事
はうまくいくってことなのかな?職業プログラマの皆さんどう思いますか?

どこに書いていいのかわからないためage

145 :デフォルトの名無しさん:03/08/11 20:11
MFCやOWLが失敗したのも継承を多用するからだろうね。

146 :デフォルトの名無しさん:03/08/11 20:16
沢村いわく
ポリモフィズム=OO
継承を多用しないということはポリモフィズムを行わないということか

つまり沢村は間違ってると

147 :沢口靖子:03/08/14 08:06
ヌヒよ、ポリモーフィズムが生きるのはインターフェイスや抽象クラスだな
その程度の継承は許されてると思うよ。
継承の多用=ポリモーフィズムじゃないので沢村が間違ってるとも言い切れない

ただ何でもかんでも汎化するのはあたしゃすきじゃありません


148 :マリーナの夏:03/08/14 10:03
http://life.fam.cx/a011/

149 :デフォルトの名無しさん:03/08/14 17:19
>>147
おまいは、早く結婚しろ!


150 :山崎 渉:03/08/15 15:25
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

55 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)