オブジェクト指向ってクソじゃね？

**デフォルトの名無しさん** · 2018/08/24(金) 13:32:09.36

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96

**デフォルトの名無しさん** · 2018/10/16(火) 18:13:44.49

いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん

本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな

**デフォルトの名無しさん** · 2018/10/16(火) 18:57:36.52

言われたらそうだなｗ盲点だった

**デフォルトの名無しさん** · 2018/10/16(火) 19:03:13.54

そこででてくるのがプロパティだよ
ageは属性かメソッドかといったら属性だろ？

一見属性にアクセスしているようで、内部では
いろんな処理を行って値を返す。
それがプロパティ

**デフォルトの名無しさん** · 2018/10/16(火) 19:04:22.70

>>825
盲点でも何でも無いよｗ

例えば、Configクラスであっても、いつの時点のConfigかわからんだろ？
一年前の設定がほしいかもしれない。

**デフォルトの名無しさん** · 2018/10/16(火) 19:12:47.50

>>826
引数が渡せるプロパティじゃないとね
c#使いなんだけどｃ#は引数を渡せない

**デフォルトの名無しさん** · 2018/10/16(火) 19:22:26.29

状態状態ってよく悪者にされるけど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;
}
ログの有効無効なんかをこうやって切り替えるのって
そんなに悪いこと？

**デフォルトの名無しさん** · 2018/10/16(火) 19:24:41.24

Delphiなら配列の構文で引数付きプロパティを扱えたりするが
そんなことするぐらいならpersonからはbirthdayだけ見せて
今何歳かなんて呼び出し側で勝手に計算しやがれって思うわw

**デフォルトの名無しさん** · 2018/10/16(火) 19:26:14.38

読み取りのプロパティは冪等であるべきじゃないの？

**デフォルトの名無しさん** · 2018/10/16(火) 19:27:08.86

Nameも不変じゃないし身長体重性別だって不変じゃない
商品の値段も不変じゃない
不変のものなってまず無いだろう。

つまりは、オブジェクトの状態の過去のスナップショットを
オブジェクト自身に持たせるのが正しい設計かという話

**デフォルトの名無しさん** · 2018/10/16(火) 19:30:01.71

>>831
だから>>824は時刻を引数で与えるよう提案しているわけだ。最初からそういう話
personクラスが中で勝手に現在時刻を取得してたりしたら複数インスタンスのageの基準がずれたりして
使い辛くてかなわんだろう

**デフォルトの名無しさん** · 2018/10/16(火) 19:33:44.42

>>833
その理屈だと結婚などでNameが変わることもあるから
Nameにも日時を与えるようにしないといけなくなる

**デフォルトの名無しさん** · 2018/10/16(火) 19:34:54.98

話がずれてる
本質が理解されてないらしい

**デフォルトの名無しさん** · 2018/10/16(火) 19:35:57.94

本質は>>832に書いたとおり

> つまりは、オブジェクトの状態の過去のスナップショットを
> オブジェクト自身に持たせるのが正しい設計かという話

**デフォルトの名無しさん** · 2018/10/16(火) 19:37:46.55

誕生日だけが提供されていたらコードのあちこちで年齢を出すメソッドが別々に書かれるかもしれない
同じ処理が複数で書かれてそれも同じ処理とも限らない

ロジックが散らばるのはよくないからクラスが持つべきではないかと思う

**デフォルトの名無しさん** · 2018/10/16(火) 19:38:15.60

大小比較のアルゴリズム自体を引数で渡したり、
オブジェクト指向っぽくてエレガントに見えはするけど、
一般プログラマには可読性低いなー
と思ったり。

一昔前のオブジェクト指向設計が売りの会社たちは、
オナニー会社として、まるで奮わなかったもんな

やっぱ適正レベルってもんが大事だよね

**デフォルトの名無しさん** · 2018/10/16(火) 19:40:14.57

>>837
そこは、年齢に限らず単に時刻の差を計算する処理として
dateクラスのメソッドかグローバル関数であるべきでは

**デフォルトの名無しさん** · 2018/10/16(火) 19:41:53.17

C++はベターCとして、文字列いじるときとか楽できればいいんじゃね？

でもmallocとかメモリ管理が面倒だから、C#やJavaに流れるよね
要員確保できるもの

**デフォルトの名無しさん** · 2018/10/16(火) 19:43:35.70

>>839
間違っても年齢を出す処理はdateクラスに持たせるべきではない

誕生日から年齢を出すのは実は結構めんどくさい
日本での年齢は日本の法律にのっとって決まってる

**デフォルトの名無しさん** · 2018/10/16(火) 19:43:50.71

だいたいそういうのは業務共通クラスとしてstaticメソッドてんこ盛りで置いておくよね

**デフォルトの名無しさん** · 2018/10/16(火) 19:46:28.35

つーか簡単だろ？

日付クラス。もしくは日付補助クラスに
2つの日付の差を年で返すメソッドを追加する

Personクラスには、誕生日とageプロパティをもたせ
ageプロパティは、誕生日と今日の日付の差を
さっきの年で返すメソッドを呼び出すだけにする

テストは日付クラスのメソッドはそのまま年計算のメソッドのテストを書けばいいし
Personクラスのテストは、単体テストの観点から日付クラスが
外部モジュールになるので年計算のテストは不要（すでにやってる）
年計算のメソッドを期待したとおりの引数で呼び出していることの確認と
返り値をそのまま戻しているかを確認すればいい

特定の年月日の年齢が知りたいなら、誕生日プロパティと特定の日付から
日付クラスの年計算メソッドを呼び出して差を計算するか、
適切な場所があるならそこにメソッドをおけばいい

**デフォルトの名無しさん** · 2018/10/16(火) 19:47:01.66

>>841
> 間違っても年齢を出す処理はdateクラスに持たせるべきではない

理由ぐらい書けよな

**デフォルトの名無しさん** · 2018/10/16(火) 19:47:46.46

dateクラスに持たせるべきではないというのなら
年齢計算クラスに持たせればいいだけだな

**デフォルトの名無しさん** · 2018/10/16(火) 19:47:59.81

>>841
すまん、ならdateクラスは撤回する
国にも依るとなると尚更personにも持たせたくないな
単にグローバル関数にするか、いっそそれ用のクラスツリーをでっち上げて後々多態できるようにするか、かなあ

**デフォルトの名無しさん** · 2018/10/16(火) 19:48:53.47

>>843
じーちゃん132歳とか出るパターンじゃね？

**デフォルトの名無しさん** · 2018/10/16(火) 19:49:01.40

国によって年齢計算のアルゴリズムを変えたいというのなら
ストラテジーパターンの出番だなｗ

**デフォルトの名無しさん** · 2018/10/16(火) 19:54:14.32

みんな賢いねぇ

**デフォルトの名無しさん** · 2018/10/16(火) 20:36:04.05

俺やったらageプロパティやageオブジェクト作るんじゃなくて
ageクラス作ってpersonのデリゲートメソッドにageクラスオブジェクト返すものを作る。これで年齢とはそもそもなんぞや定義はの面倒な過程の話にも対応出来る
だが書く途中でゲッターですませやとキレだすと思う

**デフォルトの名無しさん** · 2018/10/16(火) 20:39:51.39

普通に考えたら person と基準日を表すオブジェクトから年齢を返す関数を作るってことになると思うんだが。

**デフォルトの名無しさん** · 2018/10/16(火) 20:42:25.71

>>850
定義もわからんもの作んなカスwwww

**デフォルトの名無しさん** · 2018/10/16(火) 21:14:56.44

>>852
定義がわからんからオブジェクト指向やろう
というか俺はプロパティで済ますわ

**デフォルトの名無しさん** · 2018/10/16(火) 22:05:40.03

もうメンバー変数とメンバー関数が混在するクラスは作るな
関数しかないinterfaceで十分
関数が一つしかないならlambdaでいい

**デフォルトの名無しさん** · 2018/10/16(火) 22:35:26.96

それ、区別する必要あるの？

**デフォルトの名無しさん** · 2018/10/16(火) 22:42:29.73

正直必要かどうかはわからない
ただおまえが欲しい
だめか？それだけじゃ？

**デフォルトの名無しさん** · 2018/10/16(火) 22:45:36.90

その低学歴知恵遅れが作ったﾒｿｯﾄﾞは
うるう年考慮してなさそうで変なﾊﾞｸﾞが入ってそうだわ

2000年10月20日生まれなら
普通にintで
(20181016-20001020)/1000
でしまいだからな

**デフォルトの名無しさん** · 2018/10/16(火) 22:48:30.57

そもそも常識的に
特殊なｹｰｽを除いて日付の引き算で
経過年数がかえってくるという発想はないからな

経過日数はあったとしてもな

**デフォルトの名無しさん** · 2018/10/16(火) 22:52:46.85

(20181016-20001020)/10000
こうだな
危ない。。。

**デフォルトの名無しさん** · 2018/10/16(火) 22:54:43.61

このとおり、
やっぱりな低学歴知恵遅れが
ｵﾌﾞｼﾞｪｸﾄ指向にふれるのは危険

ｵﾚぐらいのﾚﾍﾞﾙがないとﾑﾘ

**デフォルトの名無しさん** · 2018/10/16(火) 23:02:22.64

俺の周りじゃあ
バカほど大喜びで使っているよ

**デフォルトの名無しさん** · 2018/10/17(水) 08:20:36.48

>>832
勝手に変わるか、と言う意味では、生年月日は不変だけど、年齢は変わるんでは？

>>833
なるほど。そもそもそれはプロパティとは言ってなかったんだな。
それはおっしゃるとおり、関数にすべきだと思う。

**デフォルトの名無しさん** · 2018/10/17(水) 08:22:14.61

>>857
年齢はその前日の満了を持って加算される、のルールで抜けるパターンがあるんじゃね？
半角さんは間抜けなの？

**デフォルトの名無しさん** · 2018/10/17(水) 09:03:37.20

半角さんを怒らせたら低学歴知恵遅れにされちゃうよ

**デフォルトの名無しさん** · 2018/10/17(水) 09:56:27.08

大抵の場合、正しく理解せずに中途半端な実装してる案件にぶち当たって嫌な思いした奴がここに集うんだろ？

**デフォルトの名無しさん** · 2018/10/17(水) 10:09:33.91

実装レベルの議論してるやつと設計レベルの議論してるやつ
さらにもーちょい上から俯瞰して物を言ってるやつ
全部ごちゃ混ぜになってて面白いね

**デフォルトの名無しさん** · 2018/10/17(水) 12:01:54.30

自分はプログラムの観点からだけで話してる
上にあった英語の奴もプログラムが主だったなぁ
設計は知らない
話題をスレで分けた方が良いのかねぇ?

**デフォルトの名無しさん** · 2018/10/17(水) 12:20:31.30

設計レベルの話とかでとらんけどw

**デフォルトの名無しさん** · 2018/10/17(水) 14:05:39.44

やっぱ平年の3/1に、うるう年の2/29に生まれた人の年齢が狂うな。
しかしこういう知ったかぶりが、ひどいバグを生んで改修大変になる。
と言うか、これを保存時にやられるとデータ修正ものなので、場合によっては偉いさんが頭下げに行って、出世の道が遠のくパターン。

**デフォルトの名無しさん** · 2018/10/17(水) 14:07:46.09

設計って、機能ごとに必要な処理をリストアップしたら、そのまんまオブジェクト指向なんじゃね？

**デフォルトの名無しさん** · 2018/10/17(水) 15:04:16.60

「誕生日の前日が終了する瞬間（すなわち誕生日をむかえる午前0時00分の直前）
に1歳を加えることになる」の部分の解釈には
前日に1日加えると解釈される場合と
当日に1日加えると解釈される場合の2種類がある

**デフォルトの名無しさん** · 2018/10/17(水) 15:32:27.26

2/29日生まれの人は4でわらないとね

**デフォルトの名無しさん** · 2018/10/17(水) 16:00:02.67

>>871
一番問題になる学教法にならうべきじゃないんかな。
前日に歳を取る、ただし前日の24:00を使用する。表記や概念的には、って感じで。
だから、4/1生まれは4/2生まれと学年が違う。4/1生まれは、3月中に歳をとってるから。

**デフォルトの名無しさん** · 2018/10/17(水) 16:02:31.73

誕生から１年経過することに１つ年を取るというのが定義であって
誕生日なんて全く関係ありませんよ。人間のクズども。

**デフォルトの名無しさん** · 2018/10/17(水) 16:08:03.45

学校教育法17条「保護者は、子の満六歳に達した日の翌日以後における最初の学年の初めから・・・」

**デフォルトの名無しさん** · 2018/10/17(水) 16:09:22.06

年齢の扱いをどうするかは法律で強制されているわけじゃないので
システムによって異なってもOK

だからどういう実装でも公平な実装であれば問題ないといえる。
例えば20歳おめでとうキャンペーンで、20歳になっていなくても
その月に20歳の誕生日を迎える人を対象にしても良いわけだ

だから何が正解かを議論することに意味はない

仕事の話をするなら
年齢の計算はどうしましょうか？と客に仕様を聞くべきか
年齢の計算はこのようにしますがよろしいですか？と客に仕様の確認するべきか？
そういったことを考えたほうが良い

**デフォルトの名無しさん** · 2018/10/17(水) 16:10:12.75

ふ、無能共にマジレスしてしまったぜｗ

**デフォルトの名無しさん** · 2018/10/17(水) 16:11:46.81

式の間違い云々よりも、皆ageはただの例示であることは前提とした上でOOPでどう表現するかの話をしてたのに
いきなり実装に踏み込んでくる思考が謎い

**デフォルトの名無しさん** · 2018/10/17(水) 16:15:47.15

Personインスタンスのageのゲッターで計算しとく。
Personインスタンスが無い時にも年齢の計算が必要になったら、クラスメソッドにしてPersonのゲッター内部から使う

**デフォルトの名無しさん** · 2018/10/17(水) 16:18:57.58

プロパティが優れているのは
ageのように、

年齢？そんなものオブジェクトのフィールドにしておけばいいだろ？
え？生年月日から計算するようにしたい？
なら、そのフィールドをプロパティにして計算して返すだけだな

とクラスのインターフェースを変えることなく
実装を関数に変更できるところにある

**デフォルトの名無しさん** · 2018/10/17(水) 16:32:11.49

年齢じゃなくてBMI値の計算にしようぜ

**デフォルトの名無しさん** · 2018/10/17(水) 16:33:10.53

>>881
俺もこれ見たよ

肥満の指標・BMIは営利目的で生まれたもので医学的根拠がない？「何を信じれば」と驚愕の声や「そやろな」と納得の声など #初耳学
https://togetter.com/li/1275152

**デフォルトの名無しさん** · 2018/10/17(水) 16:48:54.97

>>882
いやw年齢だとシンプルすぎるかなと思っただけw

**デフォルトの名無しさん** · 2018/10/17(水) 16:59:07.49

>>882
マジかよ保険会社最低だな
バレンタイン広めた菓子会社と同じくらい最低

**デフォルトの名無しさん** · 2018/10/17(水) 17:15:22.09

>>876
まあ、わかってて公平な実装と、それで良いと思ってるけど漏れがある実装は、仕様と不具合と大きく異なるけどね。

>>878
ほんといつも、半角さんがでしゃばった上に間違うからこんな事になる。

でもAgeはオブジェクトのプロパティとしては俺はおかしいと思うよ。
環境によって刻々と変わったり、恣意的に変えられる値は、オブジェクトとオブジェクトの演算で出るべきだと思う。
環境オブジェクトなり、指定時刻オブジェクトなりの、時刻を表すオブジェクトと、Personを組み合わせて、初めてAgeが出るんだし。
Personを含む生年月日があるオブジェクト.ageAt(時刻オブジェクト point)で年齢オブジェクトが出るなら理解できる。

**デフォルトの名無しさん** · 2018/10/17(水) 18:34:11.00

言い換えると、オブジェクトのプロパティはそのオブジェクトだけで表現可能なものに縛ったほうが良いと思う。

**デフォルトの名無しさん** · 2018/10/17(水) 18:41:50.33

誕生日はプロパティにしてもよく、年齢は日付けに依存するから関数か

**デフォルトの名無しさん** · 2018/10/17(水) 18:58:38.46

特定の日時の年齢が必要になったら
getAgeからgetAgeAt呼べばいいだけやん
言語によっていろいろやり方あるけどね
getAgeAt(Date.Today)しか書かれてないプログラムとかマヌケじゃん

既存クラスにメソッド追加できる言語なら
最終的にはDateにyears_between何ちゃら書く事になりそうだが

**デフォルトの名無しさん** · 2018/10/17(水) 19:05:52.01

それで言ったらPersonオブジェクトがどういう扱いなのかによってもAgeがプロパティか関数か違いそうだな。
データベース的な一回表示するだけだったら関数でも良いけど、ゲームやSNSのアバター的なのだったら、ステータス表示するたびに計算してたら無駄が多い。
誕生日イベントでもない限り1日くらいは1歳違う程度は許容されるなら、オブジェクト作成時(ログイン時)に計算して結果をAgeに入れるだけとか、誕生日イベント発生時に計算して入れるだけとかした方がよくないか？
モバイルゲームとかなら尚更。

**デフォルトの名無しさん** · 2018/10/17(水) 19:07:22.09

お前らQiitaでも喧嘩してんのかよｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/10/17(水) 19:21:58.46

くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
それが答えだ

**デフォルトの名無しさん** · 2018/10/17(水) 19:41:36.97

バッチが日付またぐけど開始した日で計算したいとなると「当日」をそういう扱いにするようにプログラム書くんだろうがインターフェースを変更する必要は無さそうだな

**デフォルトの名無しさん** · 2018/10/17(水) 19:45:33.46

プログラミング系の文章は長いのが多いｗ
Qiitaも無駄に長いし

**デフォルトの名無しさん** · 2018/10/17(水) 19:48:24.97

そらそうよ。
一体何に細かく指示してると思ってんの。
それに比べれば全然短いわ。

**デフォルトの名無しさん** · 2018/10/17(水) 19:49:12.51

保守性、生産性なんてどーでもいいみたいだなw

**デフォルトの名無しさん** · 2018/10/17(水) 20:48:03.60

保守性がどーでもいいならスマートUI + 振る舞いレスオブジェクト + トランザクションスクリプト + スパゲティクエリで短期的な生産性を上げることができる
保守性と生産性を同時に上げる方法は残念ながらオブジェクト指向しか知らない

**デフォルトの名無しさん** · 2018/10/17(水) 21:11:18.05

>>893
いわゆる職業病だな

**デフォルトの名無しさん** · 2018/10/17(水) 21:15:15.43

言語の解説本でもムダに長いからな
ポケットリファレンス程度でいいのに

**デフォルトの名無しさん** · 2018/10/17(水) 21:29:59.95

http://livedoor.4.blogimg.jp/hatima/imgs/c/d/cdb5756f.gif

**デフォルトの名無しさん** · 2018/10/17(水) 22:12:39.18

低学歴知恵遅れは日付ｸﾗｽにそんな頭悪いｺｰﾄﾞを入れると書いてるからな
>>843 ←　このとおり

**デフォルトの名無しさん** · 2018/10/17(水) 22:16:19.44

普通に考えてな
日付ｸﾗｽにそんな頭悪いｺｰﾄﾞなんかいれない

低学歴知恵遅れはいろんなもんに利用する日付ｸﾗｽに
年齢求めるｺｰﾄﾞをいれると書いてる

低学歴知恵遅れがｸﾗｽを設計（）すると
こういうﾊﾞｶな作りになるという典型的な例といっていい

この板にいるような低学歴知恵遅れにはやっぱりな
ｵﾌﾞｼﾞｪｸﾄ指向なんかﾑﾘ

**デフォルトの名無しさん** · 2018/10/17(水) 22:18:11.61

>>891
契約時年齢だって

**デフォルトの名無しさん** · 2018/10/17(水) 22:21:21.35

ただの起算日の違いの問題だからな
計算方法はかわらない

そもそも日付ｸﾗｽ（）なんかやるようなもんじゃない

**デフォルトの名無しさん** · 2018/10/17(水) 22:26:45.89

ともかくあきれるぐらい頭が悪い

**デフォルトの名無しさん** · 2018/10/17(水) 22:29:57.57

>>901
日付クラスに入れるのは、年の差を計算するロジックやで？
日付同士の差を求める演算。結果の年だけを取得する

誰が年齢の差のはなししてるんだよｗ

**デフォルトの名無しさん** · 2018/10/17(水) 22:30:36.34

確かになー。。。
と言うか、大抵のフレームワークに日付クラスがあるのに、わざわざ改造して年齢計算メソッド付けるって発想が浮かばない。
普通はPersonに付けるだろうし、スマホゲームとかならクライアントに計算させてバッテリー減り過ぎも困るから、場合によっては鯖側に管理クラス作ってそっちに付ける。

**デフォルトの名無しさん** · 2018/10/17(水) 22:30:39.23

ﾎﾝﾄ頭悪いわ

**デフォルトの名無しさん** · 2018/10/17(水) 22:35:00.27

アタマが悪いと短いレスすら誤解して読んでしまうらしい
ほんとかな？

**デフォルトの名無しさん** · 2018/10/17(水) 22:35:22.24

>>906
日付クラスに入れるのは日付の計算（もちろんすでに入ってるのならそれを使う）
年齢はPersonクラス、仕様が一致してるなら日付クラスのメソッドを呼ぶだけでいい

日付の計算と年齢の計算は（仮にロジックが一致していたとしても）別物
そういうことを考えるのが抽象化

**デフォルトの名無しさん** · 2018/10/17(水) 22:54:19.67

>>909
入ってるのは今の所見たことないけど、メソッドにする程か？
日付クラス同士の足し算引き算出来るはずで、年数計算って結局ただの引き算やぞ。

別に駄目とは言わんが、Ageメソッド内で「今日の日付－生年月日」するのと、「日付クラス.年数計算(今日の日付,生年月日)」するのと手間は同じ。
むしろ長くなる。

**デフォルトの名無しさん** · 2018/10/17(水) 23:03:02.79

operator - が日付クラス内で定義されてる例なんていっぱいあるでしょ

**デフォルトの名無しさん** · 2018/10/17(水) 23:05:08.82

>>910
Personクラスの属性にしていれば、
内部の実装が変わってもインターフェースを
変えなくてすむんだよ。

それにオブジェクト指向の特徴だが人間のメンタルモデルに近いから
理解しやすい。例えば「あなたの年齢は？」みたいに聞くだろう？
年齢を知りたいときに、あなたの生年月日は？って聞いてからわざわざ計算しないだろ？

"あなた"が知っていることは、"あなた"に問い合わせればよい。
というのが人間にとって一番理解しやすいんだよ

**デフォルトの名無しさん** · 2018/10/17(水) 23:05:26.01

日付ｸﾗｽの - ｵﾍﾟﾚｰﾀｰで
経過日数ではなく経過年数を返す作りになるのか。。。

さすが低学歴知恵遅れがいうことは斬新だわ

**デフォルトの名無しさん** · 2018/10/17(水) 23:07:02.95

やっぱり低学歴知恵遅れって感じ
もうすぐに分かってしまう

まともな教育を受けてればでてここないような発想が
ﾎﾟﾝﾎﾟﾝでてくる

低学歴知恵遅れのﾚｽってすぐにわかる
いちいち低学歴知恵遅れですと自白するからな。。。

**デフォルトの名無しさん** · 2018/10/17(水) 23:09:12.35

弱い犬ほど？

**デフォルトの名無しさん** · 2018/10/17(水) 23:09:52.03

ﾊﾞｶはﾊﾞｶであることに気づけない
ﾎﾝﾄになよくわかるわ

**デフォルトの名無しさん** · 2018/10/17(水) 23:17:38.65

関数型論者だったら「人」はDNAだけで表し、生まれた日、場所、その他その瞬間の宇宙の諸環境をすべて引数で与えて最後に経過時間も与えるのかな？
なんだ、関数型論者って決定論者だったんだな。

**デフォルトの名無しさん** · 2018/10/17(水) 23:30:29.90

>>910が日付の計算が日付クラスのメンバーになっているのを見たことがないと言っているので
それに対して俺は>>911で知らないうちに演算子オーバーロードの恩恵を受けているのではと言っているだけ

「今日の日付－生年月日」は日数で「日付クラス.年数計算」の「年数」とは一致しないが
そんな事は気にせずに単にdateの計算をどこに置くかの話をしているだけ
繰り返すが日付自体がただの例示だから、単位だの閏年だの細部を詰めることに意味はないと皆わかってる

そこから一人実装を始めたり短絡的にoperator -で年数を返すと変な結びつけ方をしたりして
自分が作り上げた架空の敵相手に憤ってしまうのがもうね

**デフォルトの名無しさん** · 2018/10/17(水) 23:33:06.41

>>917
それは関数型論者でなくて適切な抽象度が理解できないただの抽象馬鹿だろ。

**デフォルトの名無しさん** · 2018/10/17(水) 23:48:24.78

>>913
あれ？日付クラス(Date)の中にYaer、Man、Dayって年クラス、月クラス、日クラスって無かったっけ？
すまんね。
だいぶ離れてて、うろ覚え。

>>912
うん？
だからPersonクラスがAgeプロパティだかメソッド持つんだろ？
日付クラスだか時間クラスだかが年数計算メソッド持つ必要は無い。
時間はただ時間、日付はただ日付。
年齢もただ年齢ってのもある意味じゃ正しい。
システム上不都合なら管理クラスに計算させて、結果を受け取るだけでも良い。

オブジェクト指向は、必ずしも現実と同じ区分けでなくて良い。
責任分担をキッチリするための道具でしかない。
保守性に問題なければ、システムの特性に合わせてどちらが管理するのか決めれば良い。
(むしろ現実と離れることが多いから、あんまり現実だとこうだから～とか、こだわり過ぎない方がいい)

**デフォルトの名無しさん** · 2018/10/17(水) 23:55:39.80

生年月日は、属性・インスタンス変数

年齢は、computed・算出プロパティ

**デフォルトの名無しさん** · 2018/10/18(木) 00:04:29.24

Ruby で、年齢をクラス化したもの

誕生日から年齢を計算するhappybirthday gemをリリースしました
https://takanamito.hateblo.jp/entry/2018/05/15/091820

**デフォルトの名無しさん** · 2018/10/18(木) 00:08:50.77

るびぃ～すとｗｗｗｗｗ