50個もの項目にいちいちゲッターセッター作る奴w
オブジェクト指向の末路wwwwwwww
オブジェクト指向がお得意な皆さんはこの問題をどう対処するんだよ、できるものなら解決してみろよ
50個も列があって一度DB側で定義している
くっそ長い列名を、プログラ側でフィールドとして
羅列する意味って何？
わざわざコンストラクタ定義して大量のフィールドに引数を
移し替える意味ってなんですかwwwwww?
ポリモーフィズムとかカプセル化とかインタフェースとか
そんなご大層なことほざく前に、くっそバカバカしいこと
してるのに気付けや
プログラムの前にDB設計が脳死で無能だったらなんの意味もないって気づけやwwwwwwww
オブジェクト指向盲信してる奴よりstaticおじさんの方が
100倍賢いわwwwwwwwwwww オブジェクト指向の問題じゃなくそんなコードを書くやつとそれがオブジェクト指向のの問題だとおもう>>1がバカ そういうコード書かされる現場にいるんだろうな。
かわいそうに。 >>1
いちいち人間が作ると思ってるのか？
そういうのはな、ロボットに作らせるんだよ
ロボットに作らせるんだよ 業務用のアプリケーションだとそういうもんかね。
レコードのフィールドそのまま全部プロパティにしたら、こうなっちゃったみたいな。 データベースのテーブルから自動的に生成されたクラスってだけだろ
だれがそんなもん手動で書くんだよ 1つのクラスにあっていいフィールド数や
メソッド数はだいたいどれくらいが最適なんや？
まずそこの前提からハッキリさせようや
あとメソッドやコンストラクタが要求する引数の
個数もある程度決めようや
そうしないとマジで>>1みたいなバカをやるやつが
出るんやで >>14
最近の言語GoやRustなどはクラスがそもそもない
構造体などのフィールド数の問題は同じだが数が多ければ構造体を分割して構造化する
何もしないゲッターセッターならフィールドを公開して直接アクセスで十分 ゲッターはまだしも、セッターをパブリックにする必要あるか？ >>16
だからクラスでも構造体でもどっちでもいいが
適切なフィールド数とメソッド数は何個までが
適切なんだよ
あと、分けるってどう分けるの？
外部キーで紐付けるの？ バカは自分で考えることができないから
○個までって言われなきゃ何もできない
そういうのがゲッターセッターを作るんだよ
作れって言われたら、その意味とか理由も考えずに
ロボットのように同じことを繰り返す
バカやろ？ そういうEntityClasみたいのは
自動で作成出来るものも多いよね
Javaとかは出来ないの？
ならEXCELに一覧書いといて
VBAでファイルを吐き出すようなのを
作っとくといいよ。
自分が作った訳でもない
DBのテーブルに引っ掻き回されるのも
イヤでしょ？ >>18
個数じゃ決められないよ
10個でも不適切な場合もあれば100個でも適切な場合もあるから
基本的な分割基準は役割と凝集度と結合度と生存期間
性能や管理する手間を考慮して分割しないという判断もある
適切な分割には設計の知識と経験の両方が必要 >>18
ケースによるが構造体のフィールドに別の型の構造体を入れるだけで
それぞれのフィールド数もメソッド数もその分だけ減少していく
それが多段階になることもある ・下駄
木をくりぬき、歯を作りつけにし、台部に三つの穴をあけて鼻緒をすげた履物。歯はふつう2本で、別の材を差し込むものもある。
・雪駄
竹皮草履ぞうりの裏に革をはった履物。底が痛みにくく、また、湿気が通らない。千利休が工夫したと伝えられる。後には、かかとに尻鉄しりがねを打つことが流行した。 セッターゲッターは所詮出入り口の管理だから
生はらめぇとかそこは出口専用なのぉな穴以外には作らなくていいよ セッター:バレーボールにあってロボットにないもの
ゲッター:ロボットにあってバレーボールにないもの はやっていた当時から変なの！と思っていたが
初心者向け教育ではいまだ金科玉条のように
インチキ講師がシロウトだまして食い物にしてます >>1はオブジェクト指向が何なのかを理解していないのにオブジェクト指向の批判をしていることに気がついたほうがいい >>20
それな
でもそういう連中に限ってEXCELやVBAを忌み嫌う 
