オブジェクト指向ってクソじゃね？
レス数が950を超えています。1000を超えると書き込みができなくなります。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 普通に考えたら 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月中に歳をとってるから。 誕生から１年経過することに１つ年を取るというのが定義であって
誕生日なんて全く関係ありませんよ。人間のクズども。 学校教育法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に入れるだけとか、誕生日イベント発生時に計算して入れるだけとかした方がよくないか？
モバイルゲームとかなら尚更。 くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
それが答えだ バッチが日付またぐけど開始した日で計算したいとなると「当日」をそういう扱いにするようにプログラム書くんだろうがインターフェースを変更する必要は無さそうだな プログラミング系の文章は長いのが多いｗ
Qiitaも無駄に長いし そらそうよ。
一体何に細かく指示してると思ってんの。
それに比べれば全然短いわ。 保守性がどーでもいいならスマートUI + 振る舞いレスオブジェクト + トランザクションスクリプト + スパゲティクエリで短期的な生産性を上げることができる
保守性と生産性を同時に上げる方法は残念ながらオブジェクト指向しか知らない 言語の解説本でもムダに長いからな
ポケットリファレンス程度でいいのに 低学歴知恵遅れは日付ｸﾗｽにそんな頭悪いｺｰﾄﾞを入れると書いてるからな
>>843 ← このとおり 普通に考えてな
日付ｸﾗｽにそんな頭悪いｺｰﾄﾞなんかいれない
低学歴知恵遅れはいろんなもんに利用する日付ｸﾗｽに
年齢求めるｺｰﾄﾞをいれると書いてる
低学歴知恵遅れがｸﾗｽを設計（）すると
こういうﾊﾞｶな作りになるという典型的な例といっていい
この板にいるような低学歴知恵遅れにはやっぱりな
ｵﾌﾞｼﾞｪｸﾄ指向なんかﾑﾘ ただの起算日の違いの問題だからな
計算方法はかわらない
そもそも日付ｸﾗｽ（）なんかやるようなもんじゃない >>901
日付クラスに入れるのは、年の差を計算するロジックやで？
日付同士の差を求める演算。結果の年だけを取得する
誰が年齢の差のはなししてるんだよｗ 確かになー。。。
と言うか、大抵のフレームワークに日付クラスがあるのに、わざわざ改造して年齢計算メソッド付けるって発想が浮かばない。
普通はPersonに付けるだろうし、スマホゲームとかならクライアントに計算させてバッテリー減り過ぎも困るから、場合によっては鯖側に管理クラス作ってそっちに付ける。 アタマが悪いと短いレスすら誤解して読んでしまうらしい
ほんとかな？ >>906
日付クラスに入れるのは日付の計算（もちろんすでに入ってるのならそれを使う）
年齢はPersonクラス、仕様が一致してるなら日付クラスのメソッドを呼ぶだけでいい
日付の計算と年齢の計算は（仮にロジックが一致していたとしても）別物
そういうことを考えるのが抽象化 >>909
入ってるのは今の所見たことないけど、メソッドにする程か？
日付クラス同士の足し算引き算出来るはずで、年数計算って結局ただの引き算やぞ。
別に駄目とは言わんが、Ageメソッド内で「今日の日付−生年月日」するのと、「日付クラス.年数計算(今日の日付,生年月日)」するのと手間は同じ。
むしろ長くなる。 operator - が日付クラス内で定義されてる例なんていっぱいあるでしょ >>910
Personクラスの属性にしていれば、
内部の実装が変わってもインターフェースを
変えなくてすむんだよ。
それにオブジェクト指向の特徴だが人間のメンタルモデルに近いから
理解しやすい。例えば「あなたの年齢は？」みたいに聞くだろう？
年齢を知りたいときに、あなたの生年月日は？って聞いてからわざわざ計算しないだろ？
"あなた"が知っていることは、"あなた"に問い合わせればよい。
というのが人間にとって一番理解しやすいんだよ 日付ｸﾗｽの - ｵﾍﾟﾚｰﾀｰで
経過日数ではなく経過年数を返す作りになるのか。。。
さすが低学歴知恵遅れがいうことは斬新だわ やっぱり低学歴知恵遅れって感じ
もうすぐに分かってしまう
まともな教育を受けてればでてここないような発想が
ﾎﾟﾝﾎﾟﾝでてくる
低学歴知恵遅れのﾚｽってすぐにわかる
いちいち低学歴知恵遅れですと自白するからな。。。 ﾊﾞｶはﾊﾞｶであることに気づけない
ﾎﾝﾄになよくわかるわ 関数型論者だったら「人」はDNAだけで表し、生まれた日、場所、その他その瞬間の宇宙の諸環境をすべて引数で与えて最後に経過時間も与えるのかな？
なんだ、関数型論者って決定論者だったんだな。 >>910が日付の計算が日付クラスのメンバーになっているのを見たことがないと言っているので
それに対して俺は>>911で知らないうちに演算子オーバーロードの恩恵を受けているのではと言っているだけ
「今日の日付−生年月日」は日数で「日付クラス.年数計算」の「年数」とは一致しないが
そんな事は気にせずに単にdateの計算をどこに置くかの話をしているだけ
繰り返すが日付自体がただの例示だから、単位だの閏年だの細部を詰めることに意味はないと皆わかってる
そこから一人実装を始めたり短絡的にoperator -で年数を返すと変な結びつけ方をしたりして
自分が作り上げた架空の敵相手に憤ってしまうのがもうね >>917
それは関数型論者でなくて適切な抽象度が理解できないただの抽象馬鹿だろ。 >>913
あれ？日付クラス(Date)の中にYaer、Man、Dayって年クラス、月クラス、日クラスって無かったっけ？
すまんね。
だいぶ離れてて、うろ覚え。
>>912
うん？
だからPersonクラスがAgeプロパティだかメソッド持つんだろ？
日付クラスだか時間クラスだかが年数計算メソッド持つ必要は無い。
時間はただ時間、日付はただ日付。
年齢もただ年齢ってのもある意味じゃ正しい。
システム上不都合なら管理クラスに計算させて、結果を受け取るだけでも良い。
オブジェクト指向は、必ずしも現実と同じ区分けでなくて良い。
責任分担をキッチリするための道具でしかない。
保守性に問題なければ、システムの特性に合わせてどちらが管理するのか決めれば良い。
(むしろ現実と離れることが多いから、あんまり現実だとこうだから〜とか、こだわり過ぎない方がいい) 生年月日は、属性・インスタンス変数
年齢は、computed・算出プロパティ Ruby で、年齢をクラス化したもの
誕生日から年齢を計算するhappybirthday gemをリリースしました
https://takanamito.hateblo.jp/entry/2018/05/15/091820 >>918
年齢計算や年数計算は大事な場所じゃ無かったし、言う通り日付クラスに年数計算メソッド付けるべき？が話題の中心だったと思う。
年齢計算や年数計算は
_______日付クラスA = 今日の日付 − 生年月日(または任意の年月日)
return 日付クラスA.Yaer
とかだった気がする。
うろ覚えだが。 難しい物なんだから
話が長くなるのは当たり前
既に知っている事を話す以外だと
相手に解る様に話すのに分量が掛かる
当然だろう >>924
日付（年の差）計算と年齢計算をごっちゃにしてはいけない
日付クラスにつけるのは年の差計算処理
年齢の計算のことは考えてはいけない
Personクラスにつけるのは年齢プロパティ
中で日付クラスを使うかどうかは実装による
年齢計算の方法が複数あるというのなら、ストラテジーパターンを導入し
アルゴリズムを切り替えられるようにしておけばいいだろう
>>843で書いたことの繰り返しだがな いや低学歴知恵遅れは
頭ﾜﾙｲという病気
不治のﾔﾏｲ >>921
これ言うと元も子もないが、実際にはアカウント作る際に生年月日と年齢を別々に書かされる通り、計算なんて何処もしちゃいない。
気が付いたらユーザーが書き直してねって。
お勉強でもなけりゃ年齢計算はしない。
年計算用途の方が実践で使われてるかもね。 >>926
うーん？
誕生日を生年月日にしただけで、同じ意見に見えるが。。。
閏年に誕生日が〜とかも含めるって事？
だから、実際のサイトじゃ年齢も入力させる形なのかね？ class Age {
public DateTime BirthDay { get; }
private DateTime Today { get; }
public int Years { get {
int b = BirthDay.Year * 10000 + BirthDay.Month * 100 + BirthDay.Day;
int t = Today.Year * 10000 + Today.Month * 100 + Today.Day;
return (t - b) / 10000; }}
public Age(DateTime b, DateTime t) { ...
class Person {
public DateTime BirthDay { get; set; }
private DateTime Today { get; set; }
public Age Age => new Age(BirthDay, Today);
public Person(DateTime b, DateTime t) { ... >>912
その質問は暗黙に(今の)が入ってるんじゃない？ 半角さんは設計スキルないんだからもう書き込むなよ。
実際間違った実装を想定して設計の話ししただろ？ >>930
電子カルテだとまあまず患者マスタに年齢は持たないよ。
いつ時点に、何歳か、って方が大事だから。
どのタイミングで年齢計算するかとなると、入院中に歳を取るパターンがあるので結局毎日計算するハメになる。
それこそ業務によると思うが。
ただ普通のウェブサイトでも、生年月日聞くところで年齢を聞かれる事はあんまり無いんじゃないかな。 >>935
なるほど、カルテだったら閏年で何歳ってより、生物として生まれて何年目、的な意味合いの方が重要だし、有りかも。
年齢まで求める場所減ってるか知らないけど、情報的な価値は低いかもね。
統計的に扱うだろうから、生年月日で何年生まれか分かれば十分だし。 手術した日から何年経ったか表示してと言われて裏で誕生日クラスが使われる >>891
＞くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
＞それが答えだ
これで解決する議論をぐだぐだとまあ…
何がしたいんだ？
年齢にまつわる宇宙の真理をクラス化したいのか？ >>936
何歳って概念も結構大事で、6歳未満にはできない、とか、6歳未満だからいくら、とか結構決まり事があるんよ。
それ守らないと保険組合からお金がもらえない。
暦の上の、いわゆる法律上の年齢も無視できないんよ。
それは、医師の指示を実施した日で計算するとか、日付の取り方も色々ある。
医学的に必要になってくるとすると、何ヶ月早産児の何ヶ月児が、正規産だと何ヶ月児だよ、とか。
こっちは、だいたい週計算する。 日付クラスを継承して誕生日クラスとか作り出す奴がいるから無駄に複雑になる。 無駄にクラス化しようとする奴も同罪。だからオブジェクト指向がクソと言われる。 だから業務共通クラスの１メソッドにしとくんだろ、普通
バッチが日跨ぎしても基準日は変えないとか、業務やシステムの要素と切り離しできるなら話も変わるけど クラスもいいけど、共通処理は単なる関数ライブラリの方がありがたいよな。 >>940
継承は間違い
日付型のフィールドを持つだけの誕生日値オブジェクトクラスを作るのが正解だな ２つの日付けを引数にしてその日数を返す関数あれば、それだけでよくね？
変にクラス内に閉じ込めてもメリット無いと思うんだけど？
少なくともpersonクラスには誕生日を返すくちがあればそれでいいと思うよ。
それをどう加工するかは、表示クラスだったり年金計算クラスだったりでやればいいんだよ。 >>946
コンピュータの立場で考えるのではなく
人間の立場になって考えるようにしましょう
Personクラスはどういう属性を持っているか？
それを考えるのが設計。実装のことは一旦忘れましょう 関数型や手続きだとこんな議論にならん辺りやっぱオブジェクト指向はアカンな 誕生日から年齢導くだけの処理に、幾つのファイルとどの位のコストが必要なのかねぇ。
保守性とはホント真逆だわ。 >>949
年齢を整数のまま扱うといつか誰かが
Xピクセル=10歳+50kg
みたいな奇妙な演算をやらかす
それは困るからクラス化して保守性をあげよう それよりも複雑化によるデメリットの方が計り知れない。
そもそもコード量を減らすためにクラス化とかあるのに逆に増えるってどんな呪いだよ。 レス数が950を超えています。1000を超えると書き込みができなくなります。
