オブジェクト指向ってクソじゃね？
レス数が1000を超えています。これ以上書き込みはできません。
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>936
何歳って概念も結構大事で、6歳未満にはできない、とか、6歳未満だからいくら、とか結構決まり事があるんよ。
それ守らないと保険組合からお金がもらえない。
暦の上の、いわゆる法律上の年齢も無視できないんよ。
それは、医師の指示を実施した日で計算するとか、日付の取り方も色々ある。
医学的に必要になってくるとすると、何ヶ月早産児の何ヶ月児が、正規産だと何ヶ月児だよ、とか。
こっちは、だいたい週計算する。 日付クラスを継承して誕生日クラスとか作り出す奴がいるから無駄に複雑になる。 無駄にクラス化しようとする奴も同罪。だからオブジェクト指向がクソと言われる。 だから業務共通クラスの１メソッドにしとくんだろ、普通
バッチが日跨ぎしても基準日は変えないとか、業務やシステムの要素と切り離しできるなら話も変わるけど クラスもいいけど、共通処理は単なる関数ライブラリの方がありがたいよな。 >>940
継承は間違い
日付型のフィールドを持つだけの誕生日値オブジェクトクラスを作るのが正解だな ２つの日付けを引数にしてその日数を返す関数あれば、それだけでよくね？
変にクラス内に閉じ込めてもメリット無いと思うんだけど？
少なくともpersonクラスには誕生日を返すくちがあればそれでいいと思うよ。
それをどう加工するかは、表示クラスだったり年金計算クラスだったりでやればいいんだよ。 >>946
コンピュータの立場で考えるのではなく
人間の立場になって考えるようにしましょう
Personクラスはどういう属性を持っているか？
それを考えるのが設計。実装のことは一旦忘れましょう 関数型や手続きだとこんな議論にならん辺りやっぱオブジェクト指向はアカンな 誕生日から年齢導くだけの処理に、幾つのファイルとどの位のコストが必要なのかねぇ。
保守性とはホント真逆だわ。 >>949
年齢を整数のまま扱うといつか誰かが
Xピクセル=10歳+50kg
みたいな奇妙な演算をやらかす
それは困るからクラス化して保守性をあげよう それよりも複雑化によるデメリットの方が計り知れない。
そもそもコード量を減らすためにクラス化とかあるのに逆に増えるってどんな呪いだよ。 >>951
重複コードがほぼ一掃されるので全体のコード量は減る
利用者側は年齢にまつわる詳細なルールを知らなくても使えるようになるから複雑性も解消される 設計がおかしいとおかしなクラスが乱造される
一クラス一機能をつら抜いてFileRemoverとかFileRenamerクラス作ってる人は死んだほうがいい
MultiFileRemoverとか本当に必要なら作れよと思う >>952
だから呪い。実際、出来上がってるものの大半は真逆の事になってるんじゃないかね。 オブジェクト指向は書く量と段取りを増やすデメリットをもって
パーツや責任関係の切り分けを行う作業と理解しております 日付型とかあるじゃん
あれ中身はただの整数値だけどだからってじゃあ整数値のままでいいじゃんとはならない
なぜなら整数値を日付とみなして注意深く扱うよりも
さっさと日付型を作ってしまったほうが間違いが減って問い合わせや演算が楽になり理解しやすくなるから
同じことをドメインでもやりましょうというだけの話なんだけど何をそんなに恐れてるのだろう 架空言語にて
private Name name=new Name()
public Person(string name){
Name tmpName=new Name(name);
if(tmpName != null){
this.name=tmpName;
}
} >>947
そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
ある程度はどっちに比重置くか考えて作った方がいい。
そういう所こそ設計の腕の見せ所。 > そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
全く無関係の話をされても困るんだが？ 理想と現実は違うって事。
人間のこと考えたいけど、仕様変更繰り返すうちにグダグダになる。
出来る事は破綻しない様に事前に想定される事に対処して、その後も破綻しない様に管理することだけ。 >>963
だからオブジェクト指向が必要なんだよね >>964
そう。
そのはずだ。
入門書でAnimalクラスを継承してDogクラスとCatクラスが〜とか例えた弊害か、人間の事をとかなる。
人間の事を考えるなら顧客の事だ。 >>938
エキスパートと思われる人にヒアリングしたら
そいつが「年齢にまつわる宇宙の真理」とか求め出すというクソ案件はたくさんある。 >>947
だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
それじゃ無いと、様々な業務に適用させる度に微妙に違う属性を返さなきゃならんくなるだろ？ > だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
Personクラスはそもそも業務に特化したクラスだろう？
現実世界の人間を完全シミュレートする。それがオブジェクト指向だって
考えてるのはお前だけやで >>969
いや、そもそもオブジェクト指向はパーツの使い回しがテーマだからな。 パーツの使い回しはオブジェクト指向じゃなくてもできるんで
それは全然違いますー いやはや驚きだ。これが馬鹿というものか
まさか、どんな業務にでも通用する
Personクラスを想定していたとは
世界にたった一つPersonクラスがあれば
ゲームから業務まで何でも使えるものを想定していたとはな
愚かとしか言いようがない 少なくとも会社や自分の作るアプリで使い回す為にオブジェクト指向で作るんだからな。
おまえみたいに毎回特定業務に特化してフルスクラッチから作るとかバカしかやらんぞ。 >>973
え？お前こういったじゃん
> やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
お前は、使い回すために業務クラス作ってんのか？
どんな業務でも汎用的に使えるもの = 業務クラスだったのか？ 使い回さ（せ）ないもの = 業務クラス
Personクラスは使い回せない = 業務クラス
俺はこう言ってるだけなんだが、
こいつは何を言ってるんだろうか？ アホに構ってしまった。
personなんて一般的な名前で個別に特化したクラスを作るあほは社会の迷惑だからしんでくれ。 >>976
キミはネームスペースというものを知ったほうが良いぞ
多くの言語ではクラスはネームスペースの中に入れるから
一般的な名前が使えるんだよ 名前空間内に入っていてその業務に特化したpersonという標準クラスはok派。
それを継承して使いまわしてもいいじゃない。 名前空間のせいで型名が長い
その反動で関数名は短すぎるから型を省略したら情報が少なすぎて読めない
型を宣言する言語としない言語の対立が最も激しくなる仕組み personに関わる宇宙の真理を考えてる奴がマジでいてクソワロタwww オブジェクト指向で作った時点で失敗
メンバ変数の状態の数だけパターンが増えていく
これを仕様で固定せず
オブジェクトの状態数×オブジェクトの状態数
の工数爆発を汎用性による品質の向上とか思ってるキチガイばっかで救いようがない
無限の汎用性とは無限のバグ数を持っていることを悟るべき > オブジェクト指向で作った時点で失敗
いきなり結論ありきｗ 人類ｸﾗｽからﾎﾓｸﾗｽを導出するぐらい頭ﾜﾙｲことを平気でするからな オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない >>973-974
あー。。。
オブジェクト指向は素晴らしいかもしれん。
だがな。
納期に追われた焦った脳で扱うには手が余る。
精々次の一回使い回せたら使えたってのが現実。
(と言うか、そんなんだから継承は悪とか言われるわけで)
上で誰かがライブラリ的な方が嬉しいとか書いてたろ？
あれが真実。(誓って書いたのは俺じゃあない)
流石にまんま関数をライブラリにしなくて、関数とクラスをまとめたライブラリにするが。(むしろ気持ち悪いかこれは)
だから言ったろ？
現実と理想は違うって。
理想を追い求めて納期間に合わなくて、クビになったら元も子もないやろ？
いつかは。。。とか思いつつ、その連続よ。 >>988
お前の現実の話なんか
他人には関係ない 一番頭ﾜﾙｲやつが大量にﾚｽしてるわ。。。
まさに典型的な頭の悪さ >>988
Personのような業務クラスは使いまわしできるわけがないのは常識で
どうせ作る力ないんだから作るな。使え。
オープンソースなんかの汎用クラスを使え
見事にオブジェクト指向で世界中使い回し出来てるんだから。 業務でどこの馬の作ったか分からんような
ちゃんと試験されたかどうかすらわからんようなｺｰﾄﾞを使うとかな
ｺｲﾂは間違いなくﾆｰﾄ ちゃんと試験すればいいだけじゃね？
どうせ自分で作っても試験するんだから
他人が作ったものを試験するほうが
作るコストが節約できる
第一そもそも作る能力がないレベルなんだから
他人のが使えませんと言っても
自分で作ることもできませんっていうのが落ちだろう ｸｿﾆｰﾄの世界では手続きとういもんがないのは分かる ダメな奴は
できる方法を考えるのではなく
できない理由を考える ｵﾏｴはこのｽﾚで頭わるいことばっかり書きこむまえに
ﾊﾛﾜへいく必要がある >>984
状態をクラスにカプセル化することによって独立性を保てる境界ができる
すると状態の組み合わせ数が激減するんだよ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 55日 10時間 15分 8秒 レス数が1000を超えています。これ以上書き込みはできません。
