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

**デフォルトの名無しさん** · 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/12(金) 17:19:28.65

オブジェクト指向信者もDI信者も同じ臭いがするね

【Java】DIコンテナって本当に便利か？
http://mevius.5ch.net/test/read.cgi/tech/1219242206/

次は何を担ぐのやら

外国で流行って育っていくのだから、それなりのメリットはあるんだろうけど、なぜか仕事では恩恵にあずかったことはない

**デフォルトの名無しさん** · 2018/10/12(金) 20:33:03.38

設計のセンスの無い奴はどんな流行が来たって糞な設計しか出来ないんだよなぁ
センスがある奴はなんとなくどんな流行のスタイルでもこなして来るからなぁ

**デフォルトの名無しさん** · 2018/10/12(金) 20:41:34.47

どーでもいーけどコーディングの事設計てゆーのいーかげん恥ずかしくね？w

**デフォルトの名無しさん** · 2018/10/12(金) 20:45:43.93

は？
設計はコーディングじゃねーよw
四角い箱描いて矢印や電線で繋げて遊ぶ奴だぞ。

**デフォルトの名無しさん** · 2018/10/12(金) 20:45:57.27

ある一定以下に対して理解できるような教範が出てこない
だから一部の人しか使えないようになってる
結局は出来る人の間で持て囃されるだけになってしまう
この何か新しいやり方を創造するのと一般に使えるようにする
というのは本来両輪なんだけど
普通以下の人達が使えるようになる教範を作る
というのはかなり難しい上に
それをやる人には余りメリットがないから
なかなか出てこない
だから
オブジェクト指向プログラミングにしても
関数型プログラミングにしてもその他の技術にしても
広く(普通程度以下)使われるのは難しいし
このスレのタイトルみたいな感想を持つしかなくなる
後は自分が出来るけど他の人が出来ないままのほうが出来る人には得だから妨害する
みたいなのが居るくらいだろうかねぇ

**デフォルトの名無しさん** · 2018/10/12(金) 20:48:39.65

あー電線繋げては遊ばないわ、危ないしw
点線の間違いだわ。

**デフォルトの名無しさん** · 2018/10/12(金) 21:12:49.59

ガチでわかっとらん奴やったw

**デフォルトの名無しさん** · 2018/10/12(金) 21:17:29.38

>>772
DIはほんと便利
めちゃくちゃ開発が楽になった

**デフォルトの名無しさん** · 2018/10/12(金) 21:21:05.43

少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない

**デフォルトの名無しさん** · 2018/10/12(金) 21:27:17.84

少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない

**デフォルトの名無しさん** · 2018/10/12(金) 22:41:19.80

>>772
テストしたことないのかい？

**デフォルトの名無しさん** · 2018/10/12(金) 23:12:30.21

日銀短観のDIは便利
池沼あげのDIはtraitsなみにｳﾝｺくさい

**デフォルトの名無しさん** · 2018/10/13(土) 10:26:58.14

今時DIも使いこなせない人材とか組織にとってのリスクでしか無いよ
あっちこっち結合しまくったクソコードを社内リポジトリにばらまくとか悪夢そのものじゃん

**デフォルトの名無しさん** · 2018/10/13(土) 10:58:13.65

DI使っても結合しまくったくそコードはくそのままだ
業務分析の時点でコケて役割分担がぐちゃぐちゃなんだからDI導入したって解決しない

**デフォルトの名無しさん** · 2018/10/13(土) 21:25:17.45

>>785
DIを使わないから業務分析の時点でコケて役割分担がぐちゃぐちゃになるのでは？
設計者にDIを学習させてDIを使う前提で設計させればそのあたりの分担がキレイになるように意識して設計するようになるよ

**デフォルトの名無しさん** · 2018/10/13(土) 22:13:29.66

>>786
それで成功した例なんてあんの？

**デフォルトの名無しさん** · 2018/10/13(土) 22:15:51.44

cのたくさんの構造体にいっぱい変数や関数ﾎﾟｲﾝﾀもたせて
それ入力にして処理するのと同じ

**デフォルトの名無しさん** · 2018/10/13(土) 22:29:25.59

DIはたしかにきれいな設計になるが、めんどくて工数がかかる。
作業者にはYAGNIのほうが優先度高いから勝手に採用できない

だからそういうのはトップエンジニアが最初に管理方針としてきめとくもんだ
末端のプログラマーに責任押し付けるのは酷

**デフォルトの名無しさん** · 2018/10/13(土) 22:38:19.49

今のDIはめんどすぎる
既存コードをいじらないで中身をすげかえる
もっと楽な方法はないものか

**デフォルトの名無しさん** · 2018/10/13(土) 22:42:51.86

DIは言語自体に組み込まれるべきもの
高級言語はどんどん高級になるべきだが
ガベコレ搭載あたりで停滞してしまったからね

本来はDIやデザインパターンやユニットテストや
フレームワークまで高級言語の仕様に含めなきゃいけない

**デフォルトの名無しさん** · 2018/10/13(土) 22:44:08.09

ｲﾝﾀｰﾌｪｰｽを決め打ちにしたﾃﾝﾌﾟﾚｰﾄ作る間抜けな作りと
大してかわらないからな

**デフォルトの名無しさん** · 2018/10/13(土) 22:48:54.83

使用者との合意の無いインターフェースほどクソなモンは無い
独りよがりで考えたものは全部クソなので誰にも見られないうちに捨てて欲しい

**デフォルトの名無しさん** · 2018/10/13(土) 22:54:18.52

逆に言えば使用者との合意のあるインターフェースは問題ない
ということになってしまう。

**デフォルトの名無しさん** · 2018/10/13(土) 22:59:41.42

>>794
もちろんそうだろ

**デフォルトの名無しさん** · 2018/10/13(土) 23:21:29.03

>>795
あ、そうだって認めたねｗ

つまり、お前はインターフェースに問題があるとしようとしていたようだが、
俺はインターフェースには問題ないという話への誘導に成功したわけだ

**デフォルトの名無しさん** · 2018/10/13(土) 23:38:37.37

ｸｿが余計なことをして
余計にｸｿなｺｰﾄﾞを生産するｻｲｸﾙが途絶えることはない

**デフォルトの名無しさん** · 2018/10/13(土) 23:45:30.90

SEが余計なことをして
クソコードを量産することになるのは
よくある話だな

**デフォルトの名無しさん** · 2018/10/14(日) 11:01:28.22

DIを使わないと結合部分に余計なコードが入り乱れて大変なんだよな

**デフォルトの名無しさん** · 2018/10/14(日) 12:27:39.55

え？どんなコードが入るの？
ありえないのに

**デフォルトの名無しさん** · 2018/10/15(月) 20:24:46.22

なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの？
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。

**デフォルトの名無しさん** · 2018/10/15(月) 20:30:03.66

ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった

**デフォルトの名無しさん** · 2018/10/15(月) 21:16:54.08

　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

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

この記事拍手の数すげぇな。まだ伸び続けてる
Goodbye, Object Oriented Programming
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

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

誰か和訳してよ

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

オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね

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

Banana Monkey Jungle Solution

まで読んだ

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

Elm最高まで読んだ

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

結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ

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

現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ

**デフォルトの名無しさん** · 2018/10/16(火) 11:00:52.85

アクセス修飾子について分かりやすい説明しているサイトない？
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか

**デフォルトの名無しさん** · 2018/10/16(火) 11:06:30.91

>>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる

**デフォルトの名無しさん** · 2018/10/16(火) 11:07:25.98

ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない

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

あとから処理をフックできるぞ！

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

setget時にログ出したいときに一括でできるぐらいか？

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

>>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ

多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい

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

>>816
色々サイトみてるけど不要論も結構あるんだよな

よくわからないけどありがとう

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

言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね？

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

それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔

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

今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。

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

セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う

設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ

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

>>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる

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

>>821
> セットなんちゃらって書く場面を考えると

セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更

**デフォルトの名無しさん** · 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種類がある