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

**デフォルトの名無しさん** · 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/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

るびぃ～すとｗｗｗｗｗ

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

>>918
年齢計算や年数計算は大事な場所じゃ無かったし、言う通り日付クラスに年数計算メソッド付けるべき？が話題の中心だったと思う。

年齢計算や年数計算は
_______日付クラスA = 今日の日付－生年月日(または任意の年月日)
return 日付クラスA.Yaer

とかだった気がする。
うろ覚えだが。

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

難しい物なんだから
話が長くなるのは当たり前
既に知っている事を話す以外だと
相手に解る様に話すのに分量が掛かる
当然だろう

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

>>924
日付（年の差）計算と年齢計算をごっちゃにしてはいけない
日付クラスにつけるのは年の差計算処理
年齢の計算のことは考えてはいけない

Personクラスにつけるのは年齢プロパティ
中で日付クラスを使うかどうかは実装による

年齢計算の方法が複数あるというのなら、ストラテジーパターンを導入し
アルゴリズムを切り替えられるようにしておけばいいだろう
>>843で書いたことの繰り返しだがな

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

いや低学歴知恵遅れは
頭ﾜﾙｲという病気

不治のﾔﾏｲ

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

またワンワンって聞こえる

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

>>927
あなたのその病治らなくて大変ですね

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

>>921
これ言うと元も子もないが、実際にはアカウント作る際に生年月日と年齢を別々に書かされる通り、計算なんて何処もしちゃいない。
気が付いたらユーザーが書き直してねって。

お勉強でもなけりゃ年齢計算はしない。
年計算用途の方が実践で使われてるかもね。

**デフォルトの名無しさん** · 2018/10/18(木) 01:06:50.02

>>926
うーん？
誕生日を生年月日にしただけで、同じ意見に見えるが。。。
閏年に誕生日が～とかも含めるって事？
だから、実際のサイトじゃ年齢も入力させる形なのかね？

**デフォルトの名無しさん** · 2018/10/18(木) 06:47:29.90

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) { ...

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

>>912
その質問は暗黙に(今の)が入ってるんじゃない？

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

半角さんは設計スキルないんだからもう書き込むなよ。
実際間違った実装を想定して設計の話ししただろ？

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

>>930
電子カルテだとまあまず患者マスタに年齢は持たないよ。
いつ時点に、何歳か、って方が大事だから。
どのタイミングで年齢計算するかとなると、入院中に歳を取るパターンがあるので結局毎日計算するハメになる。

それこそ業務によると思うが。
ただ普通のウェブサイトでも、生年月日聞くところで年齢を聞かれる事はあんまり無いんじゃないかな。

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

>>935
なるほど、カルテだったら閏年で何歳ってより、生物として生まれて何年目、的な意味合いの方が重要だし、有りかも。

年齢まで求める場所減ってるか知らないけど、情報的な価値は低いかもね。
統計的に扱うだろうから、生年月日で何年生まれか分かれば十分だし。

**デフォルトの名無しさん** · 2018/10/18(木) 11:41:18.85

手術した日から何年経ったか表示してと言われて裏で誕生日クラスが使われる

**デフォルトの名無しさん** · 2018/10/18(木) 12:26:47.14

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

これで解決する議論をぐだぐだとまあ…
何がしたいんだ？
年齢にまつわる宇宙の真理をクラス化したいのか？

**デフォルトの名無しさん** · 2018/10/18(木) 12:45:03.88

>>936
何歳って概念も結構大事で、6歳未満にはできない、とか、6歳未満だからいくら、とか結構決まり事があるんよ。
それ守らないと保険組合からお金がもらえない。
暦の上の、いわゆる法律上の年齢も無視できないんよ。
それは、医師の指示を実施した日で計算するとか、日付の取り方も色々ある。

医学的に必要になってくるとすると、何ヶ月早産児の何ヶ月児が、正規産だと何ヶ月児だよ、とか。
こっちは、だいたい週計算する。

**デフォルトの名無しさん** · 2018/10/18(木) 12:45:24.34

日付クラスを継承して誕生日クラスとか作り出す奴がいるから無駄に複雑になる。

**デフォルトの名無しさん** · 2018/10/18(木) 13:23:27.88

無駄にクラス化しようとする奴も同罪。だからオブジェクト指向がクソと言われる。

**デフォルトの名無しさん** · 2018/10/18(木) 14:01:33.21

だから業務共通クラスの１メソッドにしとくんだろ、普通

バッチが日跨ぎしても基準日は変えないとか、業務やシステムの要素と切り離しできるなら話も変わるけど

**デフォルトの名無しさん** · 2018/10/18(木) 14:13:24.19

クラスもいいけど、共通処理は単なる関数ライブラリの方がありがたいよな。

**デフォルトの名無しさん** · 2018/10/18(木) 14:59:01.57

>>940
継承は間違い
日付型のフィールドを持つだけの誕生日値オブジェクトクラスを作るのが正解だな

**デフォルトの名無しさん** · 2018/10/18(木) 15:25:24.79

Person.birthday.dateなの？

**デフォルトの名無しさん** · 2018/10/18(木) 16:59:23.38

２つの日付けを引数にしてその日数を返す関数あれば、それだけでよくね？
変にクラス内に閉じ込めてもメリット無いと思うんだけど？
少なくともpersonクラスには誕生日を返すくちがあればそれでいいと思うよ。
それをどう加工するかは、表示クラスだったり年金計算クラスだったりでやればいいんだよ。

**デフォルトの名無しさん** · 2018/10/18(木) 17:52:04.62

>>946
コンピュータの立場で考えるのではなく
人間の立場になって考えるようにしましょう

Personクラスはどういう属性を持っているか？
それを考えるのが設計。実装のことは一旦忘れましょう

**デフォルトの名無しさん** · 2018/10/18(木) 17:55:05.67

関数型や手続きだとこんな議論にならん辺りやっぱオブジェクト指向はアカンな

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

誕生日から年齢導くだけの処理に、幾つのファイルとどの位のコストが必要なのかねぇ。
保守性とはホント真逆だわ。

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

>>949
年齢を整数のまま扱うといつか誰かが
Xピクセル=10歳+50kg
みたいな奇妙な演算をやらかす
それは困るからクラス化して保守性をあげよう

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

それよりも複雑化によるデメリットの方が計り知れない。
そもそもコード量を減らすためにクラス化とかあるのに逆に増えるってどんな呪いだよ。

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

>>951
重複コードがほぼ一掃されるので全体のコード量は減る
利用者側は年齢にまつわる詳細なルールを知らなくても使えるようになるから複雑性も解消される

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

棒グラフにするの大変やな

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

平均年齢もきつい

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

設計がおかしいとおかしなクラスが乱造される

一クラス一機能をつら抜いてFileRemoverとかFileRenamerクラス作ってる人は死んだほうがいい
MultiFileRemoverとか本当に必要なら作れよと思う

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

>>952
だから呪い。実際、出来上がってるものの大半は真逆の事になってるんじゃないかね。

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

オブジェクト指向は書く量と段取りを増やすデメリットをもって
パーツや責任関係の切り分けを行う作業と理解しております

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

それならわかる。

**デフォルトの名無しさん** · 2018/10/18(木) 19:06:46.96

日付型とかあるじゃん
あれ中身はただの整数値だけどだからってじゃあ整数値のままでいいじゃんとはならない
なぜなら整数値を日付とみなして注意深く扱うよりも
さっさと日付型を作ってしまったほうが間違いが減って問い合わせや演算が楽になり理解しやすくなるから
同じことをドメインでもやりましょうというだけの話なんだけど何をそんなに恐れてるのだろう

**デフォルトの名無しさん** · 2018/10/18(木) 19:25:21.20

架空言語にて

private Name name=new Name()

public Person(string name){
Name tmpName=new Name(name);
if(tmpName != null){
this.name=tmpName;
}
}

**デフォルトの名無しさん** · 2018/10/18(木) 19:26:39.70

>>947
そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
ある程度はどっちに比重置くか考えて作った方がいい。
そういう所こそ設計の腕の見せ所。

**デフォルトの名無しさん** · 2018/10/18(木) 19:30:01.60

> そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。

全く無関係の話をされても困るんだが？

**デフォルトの名無しさん** · 2018/10/18(木) 19:39:03.88

理想と現実は違うって事。
人間のこと考えたいけど、仕様変更繰り返すうちにグダグダになる。
出来る事は破綻しない様に事前に想定される事に対処して、その後も破綻しない様に管理することだけ。

**デフォルトの名無しさん** · 2018/10/18(木) 19:50:43.92

>>963
だからオブジェクト指向が必要なんだよね

**デフォルトの名無しさん** · 2018/10/18(木) 19:54:07.63

>>964
そう。
そのはずだ。
入門書でAnimalクラスを継承してDogクラスとCatクラスが～とか例えた弊害か、人間の事をとかなる。
人間の事を考えるなら顧客の事だ。

**デフォルトの名無しさん** · 2018/10/18(木) 19:54:59.16

従業員かもしれんし、何を言ってんだお前は？

**デフォルトの名無しさん** · 2018/10/18(木) 20:37:26.00

>>938
エキスパートと思われる人にヒアリングしたら
そいつが「年齢にまつわる宇宙の真理」とか求め出すというクソ案件はたくさんある。

**デフォルトの名無しさん** · 2018/10/18(木) 21:17:00.48

>>947
だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
それじゃ無いと、様々な業務に適用させる度に微妙に違う属性を返さなきゃならんくなるだろ？

**デフォルトの名無しさん** · 2018/10/18(木) 21:24:05.33

> だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。

Personクラスはそもそも業務に特化したクラスだろう？

現実世界の人間を完全シミュレートする。それがオブジェクト指向だって
考えてるのはお前だけやで

**デフォルトの名無しさん** · 2018/10/18(木) 21:25:37.05

>>969
いや、そもそもオブジェクト指向はパーツの使い回しがテーマだからな。

**デフォルトの名無しさん** · 2018/10/18(木) 21:26:42.98

パーツの使い回しはオブジェクト指向じゃなくてもできるんで
それは全然違いますー

**デフォルトの名無しさん** · 2018/10/18(木) 21:28:20.39

いやはや驚きだ。これが馬鹿というものか

まさか、どんな業務にでも通用する
Personクラスを想定していたとは

世界にたった一つPersonクラスがあれば
ゲームから業務まで何でも使えるものを想定していたとはな

愚かとしか言いようがない

**デフォルトの名無しさん** · 2018/10/18(木) 21:32:01.02

少なくとも会社や自分の作るアプリで使い回す為にオブジェクト指向で作るんだからな。
おまえみたいに毎回特定業務に特化してフルスクラッチから作るとかバカしかやらんぞ。

**デフォルトの名無しさん** · 2018/10/18(木) 21:33:57.36

>>973

え？お前こういったじゃん

> やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。

お前は、使い回すために業務クラス作ってんのか？
どんな業務でも汎用的に使えるもの = 業務クラスだったのか？

**デフォルトの名無しさん** · 2018/10/18(木) 21:35:16.82

使い回さ（せ）ないもの = 業務クラス
Personクラスは使い回せない = 業務クラス

俺はこう言ってるだけなんだが、
こいつは何を言ってるんだろうか？

**デフォルトの名無しさん** · 2018/10/18(木) 21:37:02.39

アホに構ってしまった。
personなんて一般的な名前で個別に特化したクラスを作るあほは社会の迷惑だからしんでくれ。

**デフォルトの名無しさん** · 2018/10/18(木) 21:38:08.80

>>976
キミはネームスペースというものを知ったほうが良いぞ
多くの言語ではクラスはネームスペースの中に入れるから
一般的な名前が使えるんだよ

**デフォルトの名無しさん** · 2018/10/18(木) 21:43:24.79

それじゃ解決できねーんだよw

**デフォルトの名無しさん** · 2018/10/18(木) 21:59:23.07

マクロ使ってスコープ無視してるんじゃね

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

つうか、使いまわせないから却下。

**デフォルトの名無しさん** · 2018/10/18(木) 22:20:46.14

名前空間内に入っていてその業務に特化したpersonという標準クラスはok派。
それを継承して使いまわしてもいいじゃない。

**デフォルトの名無しさん** · 2018/10/18(木) 22:53:19.65

名前空間のせいで型名が長い
その反動で関数名は短すぎるから型を省略したら情報が少なすぎて読めない

型を宣言する言語としない言語の対立が最も激しくなる仕組み

**デフォルトの名無しさん** · 2018/10/18(木) 23:03:48.89

personに関わる宇宙の真理を考えてる奴がマジでいてクソワロタwww