アカウント名:
パスワード:
私感だけど、オブジェクト指向というのは、再利用するライブラリを作成する場合は威力を発揮するのはよく分かる。しかし、再利用しない場合は不要だし、多人数で開発する場合は他人とのインタフェース部分だけオブジェクト指向的にすれば十分だと思う。他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。
他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。
確かに必要なコーディング量は増える傾向にはあると感じますが、一時的なコーディング量の削減より恒久的な修正のしやすさを優先したほうがよいと思っています。 可読性に関しては、どういうコード設計になっているかというドキュメントをつけるだけでかなり向上しますよ。
他人に見せる部分はしっかりとオブジェクト指向的に作らなければならないと思いますよ。だから、見せる必要のない変数はちゃんとprivateにして不正な操作から防止しなけりゃならなりません。
一方、他人に見せない部分というのは、逆に言うと、自分が把握できている部分です。この部分では、そこまで厳密に防御する必要は無いと思います。スコープの管理にしても、たとえばメソッド内の自動変数とクラス変数の使い分けでかなりの規模まで対処できると思いますが。
ここでいう「他人」は数ヶ月後(場合によっては数日後)の自分を含みますよね? ね?
ここでいう他人とは、作成したクラスを使う人のことなので、自分を含まないこともありえます。私は可読性を犠牲にして良いとは書いておりません。オブジェクト指向の方が可読性が落ちる場合があるのではないかと書いております。
将来の変更に備えるのならば、コメントをしっかり書けば良いと思います。内部までオブジェクト指向にする必要は無いと思います。
単体テストをしっかり作っていれば、作成するクラスを使う人に自分が含まれるのは 100% のはずですが……?
オブジェクト指向というのは、再利用するライブラリを作成する場合は威力を発揮するのはよく分かる。
発揮しません。再利用性で重要なのは、汎用性のある仕様です。オブジェクト指向で作ろうが、使えないものは使いたくありません。
オブジェクト指向というか、カプセル化はきっちりした方がいいですよ。一人で書く場合も重要。書いているうちに共通部分が次第に見出せてくるので、そういうものをクラスに分離。そうして
>発揮しません。レイヤが違います。たとえ、仕様がちゃんとしていても、クラス変数の操作がアクセサで防御されていなければ、ダメでしょう。オブジェクト指向ってライブラリの使用者に不正な操作をさせないための工夫が随所に盛り込まれています。
>書いているうちに共通部分が次第に見出せてくるので、そういうものをクラスに分離。単に、共通部分を private メソッドに切り出すだけではダメですか?また、細かい話ですが、このようなサブルーチン化はカプセル化とは違うものです。
>特にいらないのがアクセサ。オブジェクト指向的には、格別な理由が無い限り、アクセサを使用すべきです。たとえ、もらった値をクラス変数に設定するだけのアクセサであってもです。さらに...
>多態性や動的束縛は爆弾を仕込むことになることもあるので、よく考えて使ったほうが吉。だなんて、私と同じく、あなたもオブジェクト指向の濫用には反対だったりしませんか?
クラス変数の操作がアクセサで防御されていなければ、ダメでしょう。
何故に「クラス変数」の場合に限るのでしょうか。何か特定の言語のお話?
オブジェクト指向ってライブラリの使用者に不正な操作をさせないための工夫が随所に盛り込まれています。
最初の発言では「再利用」と言っておきながら、いつのまにか「利用」の話にすりかわってますね。
とりあえず、私(#1886035)はオブジェクト指向プログラミングの信奉者ではありません。また、カプセル化については推進派ですが、アクセサに関しては不要派です。
再利用性ついて、オブジェクト指向である必要性はありません。Cにもライブラリはありますよね。カプセル化については、Cのモジュールでも実現できます。それだと、再利用が難しいですか?再利用性に、オブジェクト指向は不可欠ではありませんし、プログラミング言語という道具だけの問題ではないのです。
単に、共通部分を private メソッドに切り出すだけではダメですか?また、細かい話ですが、このようなサブルーチン化はカ
>カプセル化については、Cのモジュールでも実現できます。
それは、C言語上でオブジェクト指向的な設計を実践しただけのことです。いわゆるオブジェクト指向言語でなくてもオブジェクト指向な設計は実践可能です。それで私は、再利用しない、他人に見せない部分では、構造化設計のレベルで十分(オブジェクト指向設計はやり過ぎ)ではないかと考えております。
>処理だけなら、privateメソッドにしていいですよ。でも、「クラス」と書いたのはデータと処理のどちらかではなく、組合せを念頭においているからです。
結局は程度論になるのでしょうけど、ひとりで把握できている範囲ならばデータと処理が分離しても良いと考えてます。データと処理の関連性を意識したいならば、変数名関数名で関連性を持たせれば十分ではないかと思います。
>でも、アクセサは処理からデータを切り離す手段なので、データに誤った処理を書く確率が高まります。
アクセサは誤った処理ができないようにするためのものだと思いますが。アクセサ内で入力をチェックして、不正な値ならば拒絶すれば良いですね。
>また、カプセル化がきっちり出来たクラスのオブジェクトは、アクセサで取り出そうが、メンバ変数で取り出そうが、本質的には同じことです。
どうも誤解されているようですが、アクセサとはカプセル化を行うための手段なので、このコメントは矛盾しているように思います。外部に対してリードオンリーな属性(変数)を実現するにはアクセサを使わざるを得ないと思いますが。
アクセサ介さずにデータまでpublicとして見せるのはオブジェクトのユーザが、オブジェクトの具体的なデータ構造まで意識したい場合くらいですね。
逆だよ。アクセサを使うときは、オブジェクトの具体的なデータ構造まで意識したい場合。
例えば、符号無しの多倍長整数を扱うクラスを作るとしよう。メンバ変数は、何らかの形で表現されたunsigned intの配列と、必要ならその配列の長さを保持するint型の変数としよう。そのとき、アクセサは必要?
表示のためには、文字列を返すメソッドを作ればいい。四則演算はそのためのメソッドを作ればいい。それ以外の演算に
符号無しの多倍長整数を扱うクラスを作るとしよう。メンバ変数は、何らかの形で表現されたunsigned intの配列と、必要ならその配列の長さを保持するint型の変数としよう。そのとき、アクセサは必要?
そういう「アクセサが不要」なクラス設計で「アクセサが不要」と言われても、「一般論としてアクセサは不要」とは言えないでしょう。
たとえば、アクセサと隠蔽の例によく挙げられるものとして複素数クラスがありますが、複素数クラスで、その実部と虚部にアクセスするアクセサは不要なものですか?
こういうクラスでデータをpublicで見せるのは、デカルト座標形式な内部表現限定な「具体的なデータ構造まで意識したいデータ構造」だし、これをpublicとして見せずにアクセサとして用意しておけば、たとえば「内部表現が極形式の複素数クラス」でも複素数クラスとしては気にせずに同じように使うことができます。
そういう「直接データを持っているとは限らないし、持ってないとも限らない」ような「オブジェクトの状態」情報へのアクセス手段の提供こそがアクセサの出番でしょう。
複素数クラスで、その実部と虚部にアクセスするアクセサは不要なものですか?
はい。不要です。「アクセサ」の定義次第ではありますが。
例えば、一般的なクラスにおいて、isZero()やisEmpty()がアクセサであるというのであれば、アクセサが不要などと言うことは言いません。そういうものは積極的に書くべきです。そういうものがないと、C++では、"obj == 0"と言うコードがあった時に泣けます。
複素数クラスで、メンバ変数が不可変ではないのに、setReal()がなくて、getReal()だけでもアクセサと言うのであれば、アクセサが不要などと言うことは言いません。
でも
この段落以降や#1886499 [srad.jp]あたりをよむと、アクセサの公開ではオブジェクトの具体的なデータ構造は(メンバ変数の公開ほどは)意識させない。メンバ変数の公開はオブジェクトの具体的なデータ構造まで意識してでも効率的に動かしたい場合に使う、という使い分けしてるように読めるんだが。
class Function {public: virtual int apply(int argument) = 0;};
class FunctionAdd : public Function {private: int value;
public: FunctionAdd(int value) { this->value = value; } int apply(int argument) { return argument + value; }};class FunctionDiv : public Function {private: int value;
public: FunctionDiv(int value) { this->value = value; }
私としては多態さえあれば他は要らないくらいなんですが。再利用なんか考えないプログラムでも多態は多用します。個人的にはオブジェクト指向において一番重要な機能だと考えています。なので再利用しなくてもオブジェクト指向は必要です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
再利用しなけりゃオブジェクト指向は不要 (スコア:1)
私感だけど、
オブジェクト指向というのは、再利用するライブラリを作成する場合は威力を発揮するのはよく分かる。
しかし、再利用しない場合は不要だし、多人数で開発する場合は他人とのインタフェース部分だけオブジェクト指向的にすれば十分だと思う。
他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:2, 参考になる)
他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。
確かに必要なコーディング量は増える傾向にはあると感じますが、一時的なコーディング量の削減より恒久的な修正のしやすさを優先したほうがよいと思っています。
可読性に関しては、どういうコード設計になっているかというドキュメントをつけるだけでかなり向上しますよ。
Re: (スコア:0)
Re: (スコア:0)
たとえば、変数のスコープといいますか、影響範囲を明確にすることができますし、何らかの共有変数を包みこんでやることで、想定外の変更を防止することも容易になります(Singletonとかですね)。大規模開発の現場では、えてして他チームの内部用変数を操作しようとするPGが現れたりするものなので、そういう問題に対する防御策にもなります。
また、クラスを引数に取ることは、状態と操作とをセットにして受け渡せることを意味するので、簡素なコードで柔軟な表現が可能になります(Strategyとかですね)。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
他人に見せる部分はしっかりとオブジェクト指向的に作らなければならないと思いますよ。だから、見せる必要のない変数はちゃんとprivateにして不正な操作から防止しなけりゃならなりません。
一方、他人に見せない部分というのは、逆に言うと、自分が把握できている部分です。この部分では、そこまで厳密に防御する必要は無いと思います。スコープの管理にしても、たとえばメソッド内の自動変数とクラス変数の使い分けでかなりの規模まで対処できると思いますが。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:2, すばらしい洞察)
ここでいう「他人」は数ヶ月後(場合によっては数日後)の自分を含みますよね? ね?
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
ここでいう他人とは、作成したクラスを使う人のことなので、自分を含まないこともありえます。私は可読性を犠牲にして良いとは書いておりません。オブジェクト指向の方が可読性が落ちる場合があるのではないかと書いております。
将来の変更に備えるのならば、コメントをしっかり書けば良いと思います。内部までオブジェクト指向にする必要は無いと思います。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
単体テストをしっかり作っていれば、作成するクラスを使う人に自分が含まれるのは 100% のはずですが……?
Re: (スコア:0)
発揮しません。再利用性で重要なのは、汎用性のある仕様です。オブジェクト指向で作ろうが、使えないものは使いたくありません。
オブジェクト指向というか、カプセル化はきっちりした方がいいですよ。一人で書く場合も重要。書いているうちに共通部分が次第に見出せてくるので、そういうものをクラスに分離。そうして
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
>発揮しません。
レイヤが違います。たとえ、仕様がちゃんとしていても、クラス変数の操作がアクセサで防御されていなければ、ダメでしょう。オブジェクト指向ってライブラリの使用者に不正な操作をさせないための工夫が随所に盛り込まれています。
>書いているうちに共通部分が次第に見出せてくるので、そういうものをクラスに分離。
単に、共通部分を private メソッドに切り出すだけではダメですか?
また、細かい話ですが、このようなサブルーチン化はカプセル化とは違うものです。
>特にいらないのがアクセサ。
オブジェクト指向的には、格別な理由が無い限り、アクセサを使用すべきです。たとえ、もらった値をクラス変数に設定するだけのアクセサであってもです。さらに...
>多態性や動的束縛は爆弾を仕込むことになることもあるので、よく考えて使ったほうが吉。
だなんて、私と同じく、あなたもオブジェクト指向の濫用には反対だったりしませんか?
Re: (スコア:0)
クラス変数の操作がアクセサで防御されていなければ、ダメでしょう。
何故に「クラス変数」の場合に限るのでしょうか。何か特定の言語のお話?
オブジェクト指向ってライブラリの使用者に不正な操作をさせないための工夫が随所に盛り込まれています。
最初の発言では「再利用」と言っておきながら、いつのまにか「利用」の話にすりかわってますね。
Re: (スコア:0)
とりあえず、私(#1886035)はオブジェクト指向プログラミングの信奉者ではありません。また、カプセル化については推進派ですが、アクセサに関しては不要派です。
再利用性ついて、オブジェクト指向である必要性はありません。Cにもライブラリはありますよね。カプセル化については、Cのモジュールでも実現できます。それだと、再利用が難しいですか?再利用性に、オブジェクト指向は不可欠ではありませんし、プログラミング言語という道具だけの問題ではないのです。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
>カプセル化については、Cのモジュールでも実現できます。
それは、C言語上でオブジェクト指向的な設計を実践しただけのことです。いわゆるオブジェクト指向言語でなくてもオブジェクト指向な設計は実践可能です。それで私は、再利用しない、他人に見せない部分では、構造化設計のレベルで十分(オブジェクト指向設計はやり過ぎ)ではないかと考えております。
>処理だけなら、privateメソッドにしていいですよ。でも、「クラス」と書いたのはデータと処理のどちらかではなく、組合せを念頭においているからです。
結局は程度論になるのでしょうけど、ひとりで把握できている範囲ならばデータと処理が分離しても良いと考えてます。データと処理の関連性を意識したいならば、変数名関数名で関連性を持たせれば十分ではないかと思います。
>でも、アクセサは処理からデータを切り離す手段なので、データに誤った処理を書く確率が高まります。
アクセサは誤った処理ができないようにするためのものだと思いますが。アクセサ内で入力をチェックして、不正な値ならば拒絶すれば良いですね。
>また、カプセル化がきっちり出来たクラスのオブジェクトは、アクセサで取り出そうが、メンバ変数で取り出そうが、本質的には同じことです。
どうも誤解されているようですが、アクセサとはカプセル化を行うための手段なので、このコメントは矛盾しているように思います。外部に対してリードオンリーな属性(変数)を実現するにはアクセサを使わざるを得ないと思いますが。
Re: (スコア:0)
カプセル化という意味では、クラスが持っているデータを直接触らせないというのは非常に重要です。
例えばgetHoge()というアクセサを用意した場合、hogeがどうやって得られるかをオブジェクトのユーザに意識させずに済むわけです。インスタンス変数かもしれないし、定数かもしれないし、別モジュールへ問い合わせた結果かもしれないし、何らかの計算結果かもしれないけど、とりあえずgetHoge()すればhogeが得られる。
さらに重要なのは、何らかの理由でクラスの仕様を変える必要が発生して、例えばいままでクラス変数として保持していたのを別のモジュールへの問い合わせに変更したとしても、getHoge()の仕様さえ変わらなければオブジェクトのユーザのコードは変える必要がないということですね。
アクセサ介さずにデータまでpublicとして見せるのはオブジェクトのユーザが、オブジェクトの具体的なデータ構造まで意識したい場合くらいですね。
Re: (スコア:0)
逆だよ。アクセサを使うときは、オブジェクトの具体的なデータ構造まで意識したい場合。
例えば、符号無しの多倍長整数を扱うクラスを作るとしよう。メンバ変数は、何らかの形で表現されたunsigned intの配列と、必要ならその配列の長さを保持するint型の変数としよう。そのとき、アクセサは必要?
表示のためには、文字列を返すメソッドを作ればいい。四則演算はそのためのメソッドを作ればいい。それ以外の演算に
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
そういう「アクセサが不要」なクラス設計で「アクセサが不要」と言われても、「一般論としてアクセサは不要」とは言えないでしょう。
たとえば、アクセサと隠蔽の例によく挙げられるものとして複素数クラスがありますが、
複素数クラスで、その実部と虚部にアクセスするアクセサは不要なものですか?
こういうクラスでデータをpublicで見せるのは、デカルト座標形式な内部表現限定な「具体的なデータ構造まで意識したいデータ構造」だし、
これをpublicとして見せずにアクセサとして用意しておけば、たとえば「内部表現が極形式の複素数クラス」でも複素数クラスとしては気にせずに同じように使うことができます。
そういう「直接データを持っているとは限らないし、持ってないとも限らない」ような「オブジェクトの状態」情報へのアクセス手段の提供こそがアクセサの出番でしょう。
Re: (スコア:0)
はい。不要です。「アクセサ」の定義次第ではありますが。
例えば、一般的なクラスにおいて、isZero()やisEmpty()がアクセサであるというのであれば、アクセサが不要などと言うことは言いません。そういうものは積極的に書くべきです。そういうものがないと、C++では、"obj == 0"と言うコードがあった時に泣けます。
複素数クラスで、メンバ変数が不可変ではないのに、setReal()がなくて、getReal()だけでもアクセサと言うのであれば、アクセサが不要などと言うことは言いません。
でも
Re: (スコア:0)
この段落以降や#1886499 [srad.jp]あたりをよむと、アクセサの公開ではオブジェクトの具体的なデータ構造は(メンバ変数の公開ほどは)意識させない。メンバ変数の公開はオブジェクトの具体的なデータ構造まで意識してでも効率的に動かしたい場合に使う、という使い分けしてるように読めるんだが。
Re: (スコア:0)
class Function {
public: virtual int apply(int argument) = 0;
};
class FunctionAdd : public Function {
private:
int value;
public:
FunctionAdd(int value) { this->value = value; }
int apply(int argument) { return argument + value; }
};
class FunctionDiv : public Function {
private:
int value;
public:
FunctionDiv(int value) { this->value = value; }
Re: (スコア:0)
htmlという事を忘れて<をエスケープしてなかったのが原因か?
int getSum() {
int sum = 0;
for (int i = 0; i < size(); i++) sum += get(i);
return sum;
}
Abstract1DMatrix* assign(Function *f) {
for (int i = 0; i < size(); i++) set(i, f->apply(get(i)));
return this;
}
Re: (スコア:0)
私としては多態さえあれば他は要らないくらいなんですが。
再利用なんか考えないプログラムでも多態は多用します。
個人的にはオブジェクト指向において一番重要な機能だと考えています。
なので再利用しなくてもオブジェクト指向は必要です。
Re: (スコア:0)