- PR -

class or interface ?

投稿者投稿内容
Jun
大ベテラン
会議室デビュー日: 2003/08/25
投稿数: 141
投稿日時: 2003-09-03 17:02
引用:

Astmildさんの書き込み (2003-09-03 12:29) より:
引用:

Junさんの書き込み (2003-09-03 10:56) より:
これは, いってしまうと同意は出来かねるというところなのですが
それ以前にその仮定(狭義の仕様, 広義の仕様)というところがどうも
理解できなかったのでどういっていいのか良くわからなかったのです


これは私の表現が良くありませんでした。失礼しました。

広義の仕様として、「要求を分析した結果作成され、どのような動作を
するのか、どのような構造をしているのかを示すもの」、
狭義の仕様として、「ソースコードを起こせる状態まで突き詰めたもの」
という意味で使用しました。

同じ「仕様」として表現するには違う気がする、けどほかに上手い表現が
思いつかなかったので「広義」「狭義」で分けてしまいました。


ところで、これは別の発言へのレスなのですが、
>最初からある程度設計を頭の中で描いて作ることは難しいので
>作り直しながら開発を進めています
もしかしてクラスの全体図ができる前にソースコード(もしくはそれに近い詳細設計)
を作っている、と言っています?


[ メッセージ編集済み 編集者: Astmild 編集日時 2003-09-03 12:55 ]


恥ずかしながらまったくそのとおりです
最近はソースコードをまず書いてしまってから考えるようになってしまいました.
これはよくないことかなと思っています

Jun
大ベテラン
会議室デビュー日: 2003/08/25
投稿数: 141
投稿日時: 2003-09-03 17:30
引用:

ほむらさんの書き込み (2003-09-03 12:40) より:
-------------
interfaceについて話がすれ違い気味ということがあるので本質的にという
単語にもすれ違いがあるかもしれません。
僕的には
仕様の公開性ということと, アクセスの公開性とは、
仕様の公開性と動作の公開性という表現でいいかえられ。
それが、公開性(公開の必然性)という意味で異なるものだとおもいます。

多態性に関する制限については、動作の公開性に属するものとして
同じと考え結果 仕様・動作の公開性という二つにおいて考えたとき。
前者 仕様の公開性については仕様という点から何ができるのかを宣言する都合で
   外部との橋渡し的な意味もあり、すべてにアクセスできる必要があると考えます。


その場合の仕様と言うのは要するに外部仕様ではないでしょうか
しかし仕様というものには型の概念も含まれるように思います.
その場合外部からアクセスできるメソッドに限定するというような制限は出てこないの
ではというように思います.
引用:

後者 動作の公開性については動作という点から何をするのかを宣言する都合で
   内部での利用が出来ればよいということから決して
   すべてにアクセスできる必要性はないと考えます。
   ただし、外部からの入力が必要な場合には公開される必要あるでしょう。
つまり、ここで大切なことは可視性を実現する上でキーワードなわけで
privete,protected,publicについては
C++もJAVAも同じ物であるとおもいます。

同じ意味ならば、同じ言葉を使用したほうが道理にかなっていますよね。


同じ意味と考えてしまえば確かに今のようになるのでしょうが
引用:

某MS社のようにおなじ略語にまったく別のものを
わりあててしまうのは問題だと思いますけど


私もそう思います.これに限らずこの業界全体として特定のコミュニティにのみ
通じる言い回しを作りたがる傾向があるように感じられますが, いかがでしょう
故意によるか無知によるかはともかく, 今までに無い概念を説明するのに
どんどん新しい用語が生まれるのは仕方ない面もあると思いますが
引用:

あとJavaの場合defaultなんて(暗黙的な)アクセス修飾子もあるみたいですね。。。。
C++でなれている僕にはこれのほうがややこしいです。

#ちなみに、オーバーロードは多態性(いろんな動作)を
#実現するものではないと思っています。


私もまだこの感覚にはなれていませんので使っていません
本当は使うべきところには使ったほうがいいのでしょうけど
Jun
大ベテラン
会議室デビュー日: 2003/08/25
投稿数: 141
投稿日時: 2003-09-03 18:22
引用:

ぽんさんの書き込み (2003-09-03 11:18) より:
Junさん、「2003-09-02 16:14」へのご回答ありがとうございます。

引用:

Junさんの書き込み (2003-09-03 10:45) より:
もちろん方法はあって実際に私はパターンについては何も知らないのですが
実際にこのような場合が発生して同じような方法で解決を試みました.
もっともそれは私の勘違いで実際には別なクラスを継承すればよいとわかったのですが

ただ,interfaceでないものでも私のいったようなことができるとさらに簡単になる
場合があるように思います.


コーディング上「簡単」になっても、オブジェクト指向設計上問題があります。
Javaにはオブジェクト指向設計を犠牲にしてまで「コーディングを簡単にする」という考えが
無いと思います。
(http://www.atmarkit.co.jp/fdotnet/special/java2cs/java2cs_01.html
を読む限りではC#にはあるみたいですが・・・)


デザインパターンを学んでみて下さい、世界が変わりますよ。

[ メッセージ編集済み 編集者: ぽん 編集日時 2003-09-03 11:36 ]


ご紹介どうもありがとうございます
私はC#はまったく知らないのですが, あなたのご紹介くださったページにざっと
目を通してみました.プロパティやメタデータに言及している部分については
なるほどと思うところも私にはありました.
ただ私は基本的にはシンプルな言語仕様を好みます.その面でちょっと
ついていけないかなという感じもします
いずれにせよ食わず嫌いはしたくないのでそのうちC#にも触れる機会があれば
と思います.

デザインパターンについてもいずれ勉強するつもりです

Wata
ぬし
会議室デビュー日: 2003/05/17
投稿数: 279
投稿日時: 2003-09-03 18:53
スレの本題とまったく異なるのですが...
引用:

ぽんさんの書き込み (2003-09-03 11:35) より:
クラス構成の設計は、コーディングの前にやる事だと思うんですが...


必ずしも、そうとは限りません。
ウォーターフォール型プロセスか、それを短く反復させるプロセスだと
そうなのだと思いますが、XPでは逆になります。

XPでは、設計はコーディングのあとにリファクタリングとして行われます。
もっとも、そのためにはXPのほかのプラクティスが重要になりますが...。

XPでは
テスト→コーディング→リファクタリング→テスト(繰り返し)
となります。
#この投稿へのレスは別スレッドで
Astmild
常連さん
会議室デビュー日: 2003/06/09
投稿数: 30
お住まい・勤務地: 大田区
投稿日時: 2003-09-03 21:30
引用:

Junさんの書き込み (2003-09-03 17:02) より:
恥ずかしながらまったくそのとおりです
最近はソースコードをまず書いてしまってから考えるようになってしまいました.
これはよくないことかなと思っています


そうでしたか。
開発規模が小さいうちはそれでも良いのですが、大きくなってくると、変更しようと
したときの手戻り量がつらくなります。

クラスの全体図を作る方法の一つとして、「名詞抽出法」を使用してはいかがでしょう。
要求定義から名詞を抜き出してクラス候補とし、プログラムで処理するべきものなら
クラスとする方法です。
その後、動詞を調べて関連をつなぎ、振る舞い候補を抜き出し・・・
と続いていきます。
名詞の中に is-a 関係や part-of 関係があればそれらを継承や委譲にします。

この方法なら、「乗り物」も「コンピュータ」も名詞ですからクラスになります。

また「マネージャ」や「エージェント」も名詞ですから、そこに制御を集中させることも
できます。これで MVC の分類も行えます。

レイヤリングも考えやすいと思いますよ。


[ メッセージ編集済み 編集者: Astmild 編集日時 2003-09-03 21:31 ]
yamasa
ベテラン
会議室デビュー日: 2003/02/15
投稿数: 80
投稿日時: 2003-09-04 01:45
引用:

Junさんの書き込み (2003-09-03 10:36) より:

レイヤリングを促すのが interface に public しか認めない理由である
というなら納得できます.もちろん他にも理由はあるかもしれませんが

私はだいぶ前にjavaのプロジェクトに関係してからしばらくブランクが
あり,最近またjavaで開発を始めたのですが, 最初からある程度設計を
頭の中で描いて作ることは難しいので作り直しながら開発を進めています.

今作っているものに私が例としてあげたようなものが出てきたのですが
私が直面している実際の例の場合について考えてみても
最終的にはあなたがおっしゃるようにレイヤを分けるのが正しいと思います.
ただレイヤを分けるためには継承関係にあるクラスの系列を別にもうひとつ
用意しなければならないことになってそれだけ手間がかかりますので,
おそらくかなり後の段階にならないと最終的なクラス構成におちつかない
とは思いますが


本来ならレイヤを分けるべきところを一時の手間を惜しんで分割せずに
放っておいても、結果として依存関係の複雑化により開発効率が落ち、
結局トータルコストが高くなってしまうなんてことはよくあります。

もちろん、その効果が最大限に発揮されるのは、開発の初期に
適切なレイヤリングを行なうことができた場合ですが、
それを実践するのはなかなか難しいです。
そこで私がお勧めするのは、RUPやXPといった開発手法の考えを
取り込むことです。
http://www.atmarkit.co.jp/fjava/devs/process02/process02_1.html
特に
・反復型開発
・アーキテクチャ中心
・リスク駆動
といった部分は、開発の早い段階でしっかりとしたシステムの構造を固めるのに
非常に有効です。
# これは、私自身RUPで開発してきた経験にもとづく感想です。

> おそらくかなり後の段階にならないと最終的なクラス構成におちつかない
> とは思いますが
などと最初からあきらめずに、より良い開発手法について研究してみては
どうでしょうか。
Jun
大ベテラン
会議室デビュー日: 2003/08/25
投稿数: 141
投稿日時: 2003-09-04 13:25
たぶん開発手法として皆さんのおっしゃるような方法を取り入れる必要は
あるのだろうという感じがします.
ただ私はそういったことに関しては不勉強ですのでそれについてのコメントは
控えます.
それについては皆さんのご紹介くださったことを参考に勉強したいと考えています.

スキルアップ/キャリアアップ(JOB@IT)