アカウント名:
パスワード:
> 「使い回し」が可能
前書いたコードからコピペすればいいと思っているので、そんなの問題じゃないんです。
まあマジレスしちゃうと、バグを含むコードがコピペされて地雷だらけになったり、コピペの過程でエンバグしたり、コードの重複によって保守性を大きく損ねることになるので、コピペプログラミングほど危険なものもないんだがな。
> 綺麗にコーティングすると「使い回し」が可能な点です。
同意です。もっともオブジェクト指向で無くとも同様のことは可能です。可能ですが、オブジェクト指向の言語の方がより、簡単に綺麗に表現できますね。まあ、いくら道具が良くても使う人の力量以上のことはできないので、筆者の勉強不足のように感じます。かくいう私もオブジェクト指向の良さが理解できたのはデザインパターンを知ってからでしたが...
> おぶっじぇくと志向の利点は> 綺麗にコーティングすると「使い回し」が可能な点です。
良くある間違いですね。
あなたが言っていることは、「構造化プログラミング」の手法を使えば「使い回し」可能なコードが実装できるよ、という話で、オブジェクト指向とは関係ない話です。
構造化プログラミングってのは、サブルーチンとか手続きといった処理の組合わせ、使い回しでシステムを設計したり実装する方法。要は printf みたいな便利な関数、ライブラリはどんどん使い回しましょう、という話。
オブジェクト指向は、この処理の組合わせとか使い回しを、オブジェクト中心で考えるように方針転換しましょう、って話ですね。
| …オブジェクト中心で考えるように…
は、恐らく前者でしょう。一方後者のオブジェクト指向プログラミングは、C言語での関数ポインタやvoidポインタ等を明示的に使わないで「似ているもの」を「同じもの」と「異なるもの」とに容易に分離した記述(コーディング)を可能とし、「同じもの」の記述を複数行わない((バグも)コピペしない)ことを容易に達成できる言語仕様及びそれを使ったコード作成技法です。「オブジェクト指向設計」されたものの実装に「オブジェクト指向プログラミング」を用いることは至極自然です。一方「オブジェクト指向設計」を考慮していない設計への「オブジェクト指向プログラミング」の適用も、有用です。
構造化言語の「使い回し」ったらそうだろうけど、オブジェクト指向言語の「使い回し」ったら継承でしょ。
継承だけでなく集約も大事ですよ。
データ構造とメソッドがパックになったオブジェクトが再利用の単位になったことで複雑なデータ構造や複雑な状態管理を必要とする処理の再利用が容易になりました。（細かいことを言えばこれはオブジェクト指向というよりオブジェクト・ベースの話ではありますが。）
そのため構造化時代の中心であったサブルーチン・ライブラリのようなものだけでなく、コンテナ・ライブラリや通信プロトコルのような応用のライブラリ化が容易になりました。
オブジェクトコンポジションの方が重要だよ。
『オブジェクト指向言語では、使いまわし（再利用）のために「継承」する』といういい加減な説明による誤解が生んだ、えも言われぬ設計のクラスをいくつも見てきました。
ユーザー extends 会社
みたいな。曰く、「どちらもコードと名称があるから（get/setCode、get/setNameの再利用）」とか。もちろん、ユーザークラスでは年齢とか性別とかが「拡張」されてます。
オブジェクト指向なんだからちゃんとオブジェクトを宣言して活用しないといけない なんてことはないけれど、おぶっじぇくと志向の利点は 綺麗にコーティングすると「使い回し」が可能な点です。
実際にいろんな現場を体験してると、こう言う「理想論」的な話には違和感を感じてしまいます。 かといって元記事の話は、著者の無知がひどすぎで擁護不可能ですが。
綺麗にコーティングすると「使い回し」が可能な点です。 実際にいろんな現場を体験してると、こう言う「理想論」的な話には違和感を感じてしまいます。
綺麗にコーティングすると「使い回し」が可能な点です。
実際にいろんな現場を体験してると、こう言う「理想論」的な話には違和感を感じてしまいます。
そうなんですよね。自分がはじめてJavaのプロジェクトに参加したときのことです。S2DAOを使っていたんですが、テーブルのコードをクラスごとに定数宣言していてめまいを感じた覚えが。いろいろとWebを調べてenumを使えるようにしたのですが、時間がかかったのでクラスに反映できませんでした。
それでも、他の会社のソースと比べるとましだったんですが。
本当に隠蔽化されてしまったクラスの「使い回し」の恐ろしさをしらないなんて
でも問題のコラムではクラス変数とインスタンス変数（あるいはモジュール/パッケージとオブジェクト）の区別がちゃんとついていない気配があるので、継承やら使いまわし以前にデータ構造が定義できないと思う。あの理解だとクラス、オブジェクト以前に構造体（C言語）ですらきちんと使えるかどうか怪しい。
オブジェクト指向言語と関数型言語の比較ではなく、オブジェクト指向言語を使うことを前提としてオブジェクト指向的な書き方をしないことの是非を話しているんじゃないのかな?(全関数に「public static」を付けるなど)
逆に言えば、修正スパンの長いものに採っては余り利益も無いって事でも有る。下手すりゃ次に触るときには言語仕様が変わって居るなんて事も有るし。
多人数での開発なら、新規でも再利用性が生かせるけど、個人でのプロジェクトじゃね。
きちんと分割できていればクラスの作り直しで済むのがオブジェクト指向の利点でしょうね。public staticであらゆる場所が依存しあっていたら常に全体の作り直しになります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
オブジェクト指向でそれを活用しないのは・・・ (スコア:0)
なんてことはないけれど、おぶっじぇくと志向の利点は
綺麗にコーティングすると「使い回し」が可能な点です。
そう言う意味では、オブジェクト指向の開発でそれを使わないのは
チームで開発したことの無い一匹狼のようなプログラマーです。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:3, すばらしい洞察)
> 「使い回し」が可能
前書いたコードからコピペすればいいと思っているので、そんなの問題じゃないんです。
Re: (スコア:0)
まあマジレスしちゃうと、バグを含むコードがコピペされて地雷だらけになったり、コピペの過程でエンバグしたり、コードの重複によって保守性を大きく損ねることになるので、コピペプログラミングほど危険なものもないんだがな。
Re: (スコア:0)
プロジェクト内でのコピペプログラミングが厳禁なのと同じくらい、プロジェクトをまたがった共有ライブラリ化は御法度にすべきだろ。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
> 綺麗にコーティングすると「使い回し」が可能な点です。
同意です。
もっともオブジェクト指向で無くとも同様のことは可能です。
可能ですが、オブジェクト指向の言語の方がより、簡単に綺麗に表現できますね。
まあ、いくら道具が良くても使う人の力量以上のことはできないので、
筆者の勉強不足のように感じます。
かくいう私もオブジェクト指向の良さが理解できたのはデザインパターンを知ってからでしたが...
Re: (スコア:0)
こういうのはオブジェクトしこしこって言うんじゃない？
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
> おぶっじぇくと志向の利点は
> 綺麗にコーティングすると「使い回し」が可能な点です。
良くある間違いですね。
あなたが言っていることは、「構造化プログラミング」の手法を使えば「使い回し」可能なコードが実装できるよ、という話で、オブジェクト指向とは関係ない話です。
構造化プログラミングってのは、サブルーチンとか手続きといった処理の組合わせ、使い回しでシステムを設計したり実装する方法。要は printf みたいな便利な関数、ライブラリはどんどん使い回しましょう、という話。
オブジェクト指向は、この処理の組合わせとか使い回しを、オブジェクト中心で考えるように方針転換しましょう、って話ですね。
オブジェクト指向 (スコア:2)
| …オブジェクト中心で考えるように…
は、恐らく前者でしょう。一方後者のオブジェクト指向プログラミングは、C言語での関数ポインタやvoidポインタ等を明示的に使わないで「似ているもの」を「同じもの」と「異なるもの」とに容易に分離した記述(コーディング)を可能とし、「同じもの」の記述を複数行わない((バグも)コピペしない)ことを容易に達成できる言語仕様及びそれを使ったコード作成技法です。
「オブジェクト指向設計」されたものの実装に「オブジェクト指向プログラミング」を用いることは至極自然です。一方「オブジェクト指向設計」を考慮していない設計への「オブジェクト指向プログラミング」の適用も、有用です。
Re: (スコア:0)
プログラミング＝言語仕様＋技法ですか。珍しい方ですね。
常識人なら設計とプログラミングとコーディングはなんとなく区別しているでしょうし、このストーリーでも今のところ混乱している様子はないようですよ。
Re: (スコア:0)
構造化言語の「使い回し」ったらそうだろうけど、オブジェクト指向言語の「使い回し」ったら継承でしょ。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1)
継承だけでなく集約も大事ですよ。
データ構造とメソッドがパックになったオブジェクトが再利用の単位になったことで
複雑なデータ構造や複雑な状態管理を必要とする処理の再利用が容易になりました。
（細かいことを言えばこれはオブジェクト指向というよりオブジェクト・ベースの話ではありますが。）
そのため構造化時代の中心であったサブルーチン・ライブラリのようなものだけでなく、
コンテナ・ライブラリや通信プロトコルのような応用のライブラリ化が
容易になりました。
Re: (スコア:0)
オブジェクトコンポジションの方が重要だよ。
Re: (スコア:0)
『オブジェクト指向言語では、使いまわし（再利用）のために「継承」する』という
いい加減な説明による誤解が生んだ、えも言われぬ設計のクラスをいくつも見てきました。
みたいな。
曰く、「どちらもコードと名称があるから（get/setCode、get/setNameの再利用）」とか。
もちろん、ユーザークラスでは年齢とか性別とかが「拡張」されてます。
Re: (スコア:0)
おそらくは親クラスのメソッドを子クラスから呼び出すことしか考えていないんだろうけど、そんなものはなくても、継承は可能だ。
継承は、メソッドのインタフェースを共有するための手段である。ポリモルフィズムって聞いたことないか :-p
Re: (スコア:0)
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1, 興味深い)
実際にいろんな現場を体験してると、こう言う「理想論」的な話には違和感を感じてしまいます。
かといって元記事の話は、著者の無知がひどすぎで擁護不可能ですが。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
そうなんですよね。
自分がはじめてJavaのプロジェクトに参加したときのことです。
S2DAOを使っていたんですが、テーブルのコードをクラスごとに定数宣言していてめまいを感じた覚えが。
いろいろとWebを調べてenumを使えるようにしたのですが、時間がかかったのでクラスに反映できませんでした。
それでも、他の会社のソースと比べるとましだったんですが。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1, すばらしい洞察)
本当に隠蔽化されてしまったクラスの
「使い回し」の恐ろしさをしらないなんて
再利用以前 (スコア:1)
でも問題のコラムではクラス変数とインスタンス変数（あるいはモジュール/パッケージとオブジェクト）の区別がちゃんとついていない気配があるので、継承やら使いまわし以前にデータ構造が定義できないと思う。あの理解だとクラス、オブジェクト以前に構造体（C言語）ですらきちんと使えるかどうか怪しい。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:1)
私は関数型言語の方が綺麗に書けると思うんですけどね。
まぁ、でも、ソースが綺麗かどうかは言語ではなく人に依存することではないかと思いますけど。
> 「使い回し」が可能
関数も使い回しできますよ？
むしろオブジェクト指向言語で同じクラスを使う事より、
関数型言語で同じ関数を使う事の方が多いのでは？
オブジェクト指向の利点は多人数作業の場合に分担作業のパーツの切り分けがしやすいことだと思います。
Re: (スコア:0)
オブジェクト指向言語と関数型言語の比較ではなく、
オブジェクト指向言語を使うことを前提として
オブジェクト指向的な書き方をしないことの是非を
話しているんじゃないのかな?
(全関数に「public static」を付けるなど)
Re: (スコア:0)
逆に言えば、修正スパンの長いものに採っては余り利益も無いって事でも有る。
下手すりゃ次に触るときには言語仕様が変わって居るなんて事も有るし。
多人数での開発なら、新規でも再利用性が生かせるけど、個人でのプロジェクトじゃね。
Re: (スコア:0)
クラスの作り直しになった。
Re:オブジェクト指向でそれを活用しないのは・・・ (スコア:2)
きちんと分割できていればクラスの作り直しで済むのがオブジェクト指向の利点でしょうね。
public staticであらゆる場所が依存しあっていたら常に全体の作り直しになります。