オブジェクト指向ってクソじゃね?
■ このスレッドは過去ログ倉庫に格納されています
カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約(頭文字にアンダースコアを付けるなどの命名規則)で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの?
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。 ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね Banana Monkey Jungle Solution
まで読んだ 結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ 現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ アクセス修飾子について分かりやすい説明しているサイトない?
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか >>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない setget時にログ出したいときに一括でできるぐらいか? >>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ
多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい >>816
色々サイトみてるけど不要論も結構あるんだよな
よくわからないけどありがとう 言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね? それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔 今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。 セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う
設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ >>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる >>821
> セットなんちゃらって書く場面を考えると
セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更 いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん
本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな そこででてくるのがプロパティだよ
ageは属性かメソッドかといったら属性だろ?
一見属性にアクセスしているようで、内部では
いろんな処理を行って値を返す。
それがプロパティ >>825
盲点でも何でも無いよw
例えば、Configクラスであっても、いつの時点のConfigかわからんだろ?
一年前の設定がほしいかもしれない。 >>826
引数が渡せるプロパティじゃないとね
c#使いなんだけどc#は引数を渡せない 状態状態ってよく悪者にされるけどOOPの肝はのへんににあると思う
#include <iostream>
struct logger {
std::ostream *out;
logger() : out(0) {}
void p(const char *s) {
if (out) *out << s << std::endl;
}
};
void f(logger &l) {
l.p("foo");
l.p("bar");
}
int main() {
logger g;
f(g);
g.out = &std::cout;
f(g);
g.out = &std::cerr;
f(g);
return 0;
}
ログの有効無効なんかをこうやって切り替えるのって
そんなに悪いこと? Delphiなら配列の構文で引数付きプロパティを扱えたりするが
そんなことするぐらいならpersonからはbirthdayだけ見せて
今何歳かなんて呼び出し側で勝手に計算しやがれって思うわw Nameも不変じゃないし身長体重性別だって不変じゃない
商品の値段も不変じゃない
不変のものなってまず無いだろう。
つまりは、オブジェクトの状態の過去のスナップショットを
オブジェクト自身に持たせるのが正しい設計かという話 >>831
だから>>824は時刻を引数で与えるよう提案しているわけだ。最初からそういう話
personクラスが中で勝手に現在時刻を取得してたりしたら複数インスタンスのageの基準がずれたりして
使い辛くてかなわんだろう >>833
その理屈だと結婚などでNameが変わることもあるから
Nameにも日時を与えるようにしないといけなくなる 本質は>>832に書いたとおり
> つまりは、オブジェクトの状態の過去のスナップショットを
> オブジェクト自身に持たせるのが正しい設計かという話 誕生日だけが提供されていたらコードのあちこちで年齢を出すメソッドが別々に書かれるかもしれない
同じ処理が複数で書かれてそれも同じ処理とも限らない
ロジックが散らばるのはよくないからクラスが持つべきではないかと思う 大小比較のアルゴリズム自体を引数で渡したり、
オブジェクト指向っぽくてエレガントに見えはするけど、
一般プログラマには可読性低いなー
と思ったり。
一昔前のオブジェクト指向設計が売りの会社たちは、
オナニー会社として、まるで奮わなかったもんな
やっぱ適正レベルってもんが大事だよね >>837
そこは、年齢に限らず単に時刻の差を計算する処理として
dateクラスのメソッドかグローバル関数であるべきでは C++はベターCとして、文字列いじるときとか楽できればいいんじゃね?
でもmallocとかメモリ管理が面倒だから、C#やJavaに流れるよね
要員確保できるもの >>839
間違っても年齢を出す処理はdateクラスに持たせるべきではない
誕生日から年齢を出すのは実は結構めんどくさい
日本での年齢は日本の法律にのっとって決まってる だいたいそういうのは業務共通クラスとしてstaticメソッドてんこ盛りで置いておくよね つーか簡単だろ?
日付クラス。もしくは日付補助クラスに
2つの日付の差を年で返すメソッドを追加する
Personクラスには、誕生日とageプロパティをもたせ
ageプロパティは、誕生日と今日の日付の差を
さっきの年で返すメソッドを呼び出すだけにする
テストは日付クラスのメソッドはそのまま年計算のメソッドのテストを書けばいいし
Personクラスのテストは、単体テストの観点から日付クラスが
外部モジュールになるので年計算のテストは不要(すでにやってる)
年計算のメソッドを期待したとおりの引数で呼び出していることの確認と
返り値をそのまま戻しているかを確認すればいい
特定の年月日の年齢が知りたいなら、誕生日プロパティと特定の日付から
日付クラスの年計算メソッドを呼び出して差を計算するか、
適切な場所があるならそこにメソッドをおけばいい >>841
> 間違っても年齢を出す処理はdateクラスに持たせるべきではない
理由ぐらい書けよな dateクラスに持たせるべきではないというのなら
年齢計算クラスに持たせればいいだけだな >>841
すまん、ならdateクラスは撤回する
国にも依るとなると尚更personにも持たせたくないな
単にグローバル関数にするか、いっそそれ用のクラスツリーをでっち上げて後々多態できるようにするか、かなあ >>843
じーちゃん132歳とか出るパターンじゃね? 国によって年齢計算のアルゴリズムを変えたいというのなら
ストラテジーパターンの出番だなw 俺やったらageプロパティやageオブジェクト作るんじゃなくて
ageクラス作ってpersonのデリゲートメソッドにageクラスオブジェクト返すものを作る。これで年齢とはそもそもなんぞや定義はの面倒な過程の話にも対応出来る
だが書く途中でゲッターですませやとキレだすと思う 普通に考えたら person と基準日を表すオブジェクトから年齢を返す関数を作るってことになると思うんだが。 >>852
定義がわからんからオブジェクト指向やろう
というか俺はプロパティで済ますわ もうメンバー変数とメンバー関数が混在するクラスは作るな
関数しかないinterfaceで十分
関数が一つしかないならlambdaでいい 正直必要かどうかはわからない
ただおまえが欲しい
だめか?それだけじゃ? その低学歴知恵遅れが作ったメソッドは
うるう年考慮してなさそうで変なバグが入ってそうだわ
2000年10月20日生まれなら
普通にintで
(20181016-20001020)/1000
でしまいだからな そもそも常識的に
特殊なケースを除いて日付の引き算で
経過年数がかえってくるという発想はないからな
経過日数はあったとしてもな (20181016-20001020)/10000
こうだな
危ない。。。 このとおり、
やっぱりな低学歴知恵遅れが
オブジェクト指向にふれるのは危険
オレぐらいのレベルがないとムリ >>832
勝手に変わるか、と言う意味では、生年月日は不変だけど、年齢は変わるんでは?
>>833
なるほど。そもそもそれはプロパティとは言ってなかったんだな。
それはおっしゃるとおり、関数にすべきだと思う。 >>857
年齢はその前日の満了を持って加算される、のルールで抜けるパターンがあるんじゃね?
半角さんは間抜けなの? 大抵の場合、正しく理解せずに中途半端な実装してる案件にぶち当たって嫌な思いした奴がここに集うんだろ? 実装レベルの議論してるやつと設計レベルの議論してるやつ
さらにもーちょい上から俯瞰して物を言ってるやつ
全部ごちゃ混ぜになってて面白いね 自分はプログラムの観点からだけで話してる
上にあった英語の奴もプログラムが主だったなぁ
設計は知らない
話題をスレで分けた方が良いのかねぇ? やっぱ平年の3/1に、うるう年の2/29に生まれた人の年齢が狂うな。
しかしこういう知ったかぶりが、ひどいバグを生んで改修大変になる。
と言うか、これを保存時にやられるとデータ修正ものなので、場合によっては偉いさんが頭下げに行って、出世の道が遠のくパターン。 設計って、機能ごとに必要な処理をリストアップしたら、そのまんまオブジェクト指向なんじゃね? 「誕生日の前日が終了する瞬間(すなわち誕生日をむかえる午前0時00分の直前)
に1歳を加えることになる」の部分の解釈には
前日に1日加えると解釈される場合と
当日に1日加えると解釈される場合の2種類がある >>871
一番問題になる学教法にならうべきじゃないんかな。
前日に歳を取る、ただし前日の24:00を使用する。表記や概念的には、って感じで。
だから、4/1生まれは4/2生まれと学年が違う。4/1生まれは、3月中に歳をとってるから。 誕生から1年経過することに1つ年を取るというのが定義であって
誕生日なんて全く関係ありませんよ。人間のクズども。 学校教育法17条 「保護者は、子の満六歳に達した日の翌日以後における最初の学年の初めから・・・」 年齢の扱いをどうするかは法律で強制されているわけじゃないので
システムによって異なってもOK
だからどういう実装でも公平な実装であれば問題ないといえる。
例えば20歳おめでとうキャンペーンで、20歳になっていなくても
その月に20歳の誕生日を迎える人を対象にしても良いわけだ
だから何が正解かを議論することに意味はない
仕事の話をするなら
年齢の計算はどうしましょうか?と客に仕様を聞くべきか
年齢の計算はこのようにしますがよろしいですか?と客に仕様の確認するべきか?
そういったことを考えたほうが良い 式の間違い云々よりも、皆ageはただの例示であることは前提とした上でOOPでどう表現するかの話をしてたのに
いきなり実装に踏み込んでくる思考が謎い Personインスタンスのageのゲッターで計算しとく。
Personインスタンスが無い時にも年齢の計算が必要になったら、クラスメソッドにしてPersonのゲッター内部から使う プロパティが優れているのは
ageのように、
年齢?そんなものオブジェクトのフィールドにしておけばいいだろ?
え?生年月日から計算するようにしたい?
なら、そのフィールドをプロパティにして計算して返すだけだな
とクラスのインターフェースを変えることなく
実装を関数に変更できるところにある >>881
俺もこれ見たよ
肥満の指標・BMIは営利目的で生まれたもので医学的根拠がない?「何を信じれば」と驚愕の声や「そやろな」と納得の声など #初耳学
https://togetter.com/li/1275152 >>882
いやw年齢だとシンプルすぎるかなと思っただけw >>882
マジかよ保険会社最低だな
バレンタイン広めた菓子会社と同じくらい最低 >>876
まあ、わかってて公平な実装と、それで良いと思ってるけど漏れがある実装は、仕様と不具合と大きく異なるけどね。
>>878
ほんといつも、半角さんがでしゃばった上に間違うからこんな事になる。
でもAgeはオブジェクトのプロパティとしては俺はおかしいと思うよ。
環境によって刻々と変わったり、恣意的に変えられる値は、オブジェクトとオブジェクトの演算で出るべきだと思う。
環境オブジェクトなり、指定時刻オブジェクトなりの、時刻を表すオブジェクトと、Personを組み合わせて、初めてAgeが出るんだし。
Personを含む生年月日があるオブジェクト.ageAt(時刻オブジェクト point)で年齢オブジェクトが出るなら理解できる。 言い換えると、オブジェクトのプロパティはそのオブジェクトだけで表現可能なものに縛ったほうが良いと思う。 誕生日はプロパティにしてもよく、年齢は日付けに依存するから関数か 特定の日時の年齢が必要になったら
getAgeからgetAgeAt呼べばいいだけやん
言語によっていろいろやり方あるけどね
getAgeAt(Date.Today)しか書かれてないプログラムとかマヌケじゃん
既存クラスにメソッド追加できる言語なら
最終的にはDateにyears_between何ちゃら書く事になりそうだが それで言ったらPersonオブジェクトがどういう扱いなのかによってもAgeがプロパティか関数か違いそうだな。
データベース的な一回表示するだけだったら関数でも良いけど、ゲームやSNSのアバター的なのだったら、ステータス表示するたびに計算してたら無駄が多い。
誕生日イベントでもない限り1日くらいは1歳違う程度は許容されるなら、オブジェクト作成時(ログイン時)に計算して結果をAgeに入れるだけとか、誕生日イベント発生時に計算して入れるだけとかした方がよくないか?
モバイルゲームとかなら尚更。 くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
それが答えだ バッチが日付またぐけど開始した日で計算したいとなると「当日」をそういう扱いにするようにプログラム書くんだろうがインターフェースを変更する必要は無さそうだな プログラミング系の文章は長いのが多いw
Qiitaも無駄に長いし そらそうよ。
一体何に細かく指示してると思ってんの。
それに比べれば全然短いわ。 保守性がどーでもいいならスマートUI + 振る舞いレスオブジェクト + トランザクションスクリプト + スパゲティクエリで短期的な生産性を上げることができる
保守性と生産性を同時に上げる方法は残念ながらオブジェクト指向しか知らない 言語の解説本でもムダに長いからな
ポケットリファレンス程度でいいのに ■ このスレッドは過去ログ倉庫に格納されています