Javaはスパゲッティになりがちとか言うけど

それってclassを作成する他の言語にも言えることだろ
何でJavaだけが取りざたされるんだよ

いやclassってスパゲティにならないためにあるもんだけど…

ガベージコレクションなんてのに頼るせいで、ところ構わずnewして、
その都度おかしなタイミングでコンストラクタが動いたりするのだろう。

母数が多い分ゴミコードの割合も多いから

初めて聞いたわ
java使っている現場の絶対数が多いからそう錯覚してるだけで、javaの言語仕様とスパゲッティソースの因果関係は無いと思う

>>2
だいたいのJavaの現場のコードって、クラスに1個main的なメソッドがあって
その中に大量の分岐を含む数千行のコードが書かれてグッチャグチャってのが現実じゃない？
もちろんJava自体のせいじゃないけど

Javaで糞コードが多いのは20年ほど前に未経験でほぼ教育もされずに現場に突っ込まれたPGが未だ多く残っているからだよ
そいつらはプログラミングに興味ないし仕事もやる気ないし、なにより発達障害持ちばかりだから一切改善されない
採用基準が手と足と目が付いていれば何でもいいって基準だった奴らだから仕方がない

補足だが20年前にJavaブームがあって大量のJava案件が発生してバブル状態になって、とりあえず人を突っ込めばアホみたいに儲かった時期があった

>>6
Javaでそんなクソコードみたことない
20年前に自分が最初に書いたやつでももっとマシ

なおASP

継承できてコードを再利用できるから効率的という触れ込みなのに
使えば使うほど正反対の方向に突っ走っていく

アクセス制御できるから安全でバグが減るはずが、そこを迂回しなけりゃならなくなってバグを生み出す原因に

一番の不幸はこんな筋の悪い言語が、用途を限定しない汎用言語だったことだと思う
あらゆるものにオブジェクト指向、オブジェクト指向で全て解決、そしてそうはならなかった

ブラウザでやれる事が本当に多くなったからなあ
Linuxでも動く、Windowsでも動く、みたいなJAVAの利点はもう終わった技術
生き残るのはCとスクリプト言語って組み合わせなんだよ
中途半端にCとスクリプト言語を融合させて中間的なのを作っても一次的で終わる

よっぽど変なコードしかやってないんやな

Javaがスパゲッティになる理由は巨大プロジェクトで使われるから
元々の処理が複雑なんだろ
それでも動くのがJavaだけどな

馬鹿の影響を狭めるために色々やってるわけでみんな天才ならアクセス制限なんて要らんわけだけど

例え天才でもアホな瞬間はあるからな

システムってよっぽど金があるところじゃないと、一度作ったら最後10年20年と秘伝のタレのように継ぎ足しながら延命していくわけで
その中で玉石混交のマが触っていくことで地獄が作り出されるんだ

Javaはもう業務開発でよくみる言語としてCOBOLの次に歴史があるといってもいいので
その分長生きしてて酷いことになってるのもよく見ると思う

Javaで酷いならASPとかVBとか見たらショック死するで

Java+Springで便利だからって下手にメンバ変数持たせると終わるからな
シングルトンだから他のユーザーの情報上書きされる可能性あるし
大規模なプロジェクトでアクセス演算子やらローカル変数やメンバ変数の定義はしっかりやらないとマジでシステムごと破綻する

Twitterも最近激重なんだが、思えばScala使ってんだったな
なんかブラウザ版もスマホ版も挙動不審な動きするようになった
一定量の負荷かけると文字が■■■■■■■■■■なってるバグとかも理解不能過ぎる Twitter以外で見たことがない
あれってやっぱ何らかの変数が想定以上までメモリー食った結果なんだろか

スパゲティって奇跡のコードだと思う
河原で石をバランスよく積み上げたみたいな
誰も触りたくない芸術作品だよ

スパゲティを作る人はほぼアスペかADHD
逆ギレするからすぐわかる

>>3
GC言語はどうしてもそうなるね
非GC言語で鍛えてある人だと避けられるけれど

その辺学ぶのってC言語で数年くらい車輪の再発名でもし続けないとセンスつかないからな
でもユーザー自身がおかしなタイミングでガベコレ起こして重くなるアプリでも
あまりその辺に文句言わずに使ってる現状あるしなあ
広告とか、オシャレ感とかいうものでゴミコード動いてるアプリを使う

1レスのまま落ちること期待してたんだが
スレ立てたゴミの自演レスに釣られて20レスも以上もついたかｗ

自演という証拠は？

スパゲッティはgotoが無いと作れないだろ

スパゲティ書けって言われたらどうやって書く？

>>18
スパゲティにならないようにオブジェクト指向が産まれたんだと思うんだけど違うの？

オブジェクト指向作者「えっ？」

スパゲッティにならないようにするために作られたのは構造的プログラミングじゃねえかな

一度でいいから思うがままにスパゲティコードを書いてみたい

オブジェクト指向でスパゲティになる理由がわからんのだが…
クラス使わんとさらにぐちゃぐちゃにならん？

初心者がちまちま書いてるクラスって、本来そのクラスやファイルごと不要ってのが多いから
まず初心者コードってのはメソッドと状態保存用変数が多すぎるからクラス化してスコープ作ってカプセル化の必要が出てくるわけで
容易く、関数、変数、クラスなどの定義をしないのを心がけると良いと思う

初心者といっても一つのメソッドに処理書きまくるタイプと無駄に処理を分割させまくるタイプおるからなぁ
クラスやメソッドごとの役割分担をハッキリさせて適切に定義できてれば問題ないと思う

特に何もしてない関数作ってたから何で？って聞いたらいずれ必要だからって言われて半年後に変更指示が出てその関数にあれこれ足してた未来人がいたわ

>>34
すげー

相手とのやり取りがメソッド呼び出しだけしか無いんだから
スパゲッティなんて作れないんだよなぁ

gotoだらけの本物のスパゲッティ見た事無いんだろうなぁ

>>31
クラスやその継承などはデメリットの方が多いと分かってきて定説となったため
最近のプログラミング言語であるGoやRustなどはクラスや継承などが存在しない

俺は継承流行ってた頃からほとんど使ってなかった
必要なのはメタプログラミングをコンパイル前に静的に素早くエレガントに行うような代物でしょう

まだ自演でスレ伸ばしてる・・・ｗ

自演に見えるのか…

適切ではないクラス設計
メソッドの相互呼び出し
深すぎる継承
interfaceの乱用

gotoとはちょっと違うけど
無茶苦茶になる

実際javaゲッティーあるからな
盛り上がれば良し
自演とか知らん

自演と言っているのはアスペルガーの人だから適当に揶揄ってあげるといいよ

やっぱデータ構造　＋　アルゴリズム　＋　マークアップで書けるな
クラスはその3種類が混ざっている概念

クラスは何でも突っ込み投げ入れてしまいゴミ箱状態で整理できていない遺物の構造

オブジェクト指向終わってしまった

Gotoでスパゲッティになるのはソースコードではなくフローチャート図なんだってことに気づいてないプログラマは少なくない
GOTO?8ビットマイコンのBASICとかでしょ、とにかく邪悪だから使っちゃいけない悪の根源でしょ
みたいな浅い知識のやつ

まあ道具はなんだっていいんだけどバカが使うとグチャグチャになりやすいからなりにくい物を提供してるのにバカが使うとグチャグチャになりやすいからなりにくい物を…

例外ならむしろgoto使えよって論争あったな
20年前だったかな

>>31
クラス作りまくってあっちに飛んだりそっちに飛んだりして
こっちを修正したらあっちもそっちも壊れましたなんて作りになってるオブジェクト指向もあるんよ

>>37
実際クラスは存在しないけど、継承とかmixinできちゃうからな

goto文は余計な事ごちゃごちゃ考えずにジャンプ出来るからマジ便利

gotoって見るとコロナとか、汚い利権とか二階とか頭にチラつくから嫌だ
ただでさえストレスの多い現場だぞ
もうアンチパターン認定でいいだろ

クロージャラムダつかう事が増えて
関数の中のreturnがやりたいreturnと違うっていうのがそこそこある現状なんでgotoは今一度実装されるべきだと思ったり

super break
super continue
super return

必要なのってこの辺だな
super breakはperlにあった気がする

そんな話聞いたことない

>>51
GoにもRustにもクラスの継承にあたるような継承というものはありません
それらは害悪であると決着しているため
新たなプログラミング言語であるGoやRustでは排除されました

>>57
どっちが正しいか知らんけど害悪として決着ついたという根拠へのリンクとかはある？

良いものなら導入されてただろうないってことは悪いってことさ帰納的推理でおｋ

しかし、継承を使わずにまともなGUIが作れるとは思えない

こんなふわふわが帰納的なら星占いも帰納的やな

そうだな、星占いとは全然違うけどな

帰納的推理を星占いとラベリングする詭弁がいままさにこの場で行われているわけであります

いや前提が正しければ星占いも帰納的で全然ありえるだろ

帰納的の意味わかっとるか？

星占いが帰納的であることを主張されてるわけであります、頑張っておられるのであります
このスレを星占いのスレに変えようとしてるのでありましょうか、おうし座の僕の運命はいかに

次の2つは全然違う命題なのであります
・帰納的推理は星占い
・星占いは帰納的推理

聖闘士星矢世代だと人気はそこそこやな

つまりプログラミングには、
一回書いたものを、二回目書かず、別の場所から参照する仕組みっていうただソレが必要なだけ

継承とかいう新しい形にするまでもなく
class B{}

class A{
　classB_wo_load_suru_function()
}
これでおｋ
あるいは

a = A.new
a.include( class_B_wo_include_suru_function() )

これで良い
function({option})とかだって自由に入れられるね

誰か>>52にツッコミ入れてくれよ
こういう安易な考えでgoto文使いまくるから悪質なスパゲッティコードが出来上がる、
といういい例じゃないか

>>69
今時の言語でそんな自由に飛べるgotoてあったかなと
Cだと簡単にメモリトラブル起こすから逆に使われないし

言うほどgoto使った悪質コード見かけないしな
大半のgoto使ったコードは低級レイヤーの処理速度上げるために仕方なく使ってるのが多く
そういうコードに触れる機会ほとんどないし
あっても読むだけで編集なんてしない

goto はスタックと相性が悪いからな

>>1
スパゲッティになりがちな言語というのは気軽にコードが書ける、改修しやすい言語という事
Ｊａｖａは対局にある言語でありスパゲッティとは一番遠いところに位置する

そもそもＪａｖａはしっかり設計された上でコーディングする場合が多いはずだ
Ｊａｖａでスパゲティを作るのはベテランスパゲティ建築士じゃないと難しい

>>8
今でも「Ｊａｖａ勉強して儲けよう」みたいなスクールが流行ってるけど
儲かってるの？

JAVAはもう終わったよ
次いこうね

PythonでもGoでも書き手がクソなら作り出されるコードもクソになる
それはJavaでなくても一緒

昔、Pythonのプロジェクトやってる隣のチームで中途が入ってきたけど、Pythonは遅いからクソとか言い出した。

で、そいつがC#のほうがマシだと言うからリーダーが仕方なくC#で書かせたらループの中で不要なループ書くわ、ループの中で一件ずつSQL発行するわで注意されまくってたけど、1ヶ月もしないうちにチームから消えてた。

こういうの見てからは、言語に文句を言ってるやつはそいつ自身のスキルに問題があると思ってる。

>>77
ループの中で一件ずつSQLは普通にマズイ
初心者すぎ
初心者すぎる故、言語にケチつけるのだろうけど

>>77
二重ループはどのように回避すべき？
sqlの方は一括で取ってメモリ上で扱えば良さそうだけど

まぁPythonがクソ遅いのは事実だけどね

pypy

すまんSQL初心者なんだがどうやって一括で発行するもんなの？
Listを一つづつAddしていってforループ向けたあとにListで発行？

> ループの中で一件ずつSQL発行するわで
pythonがどういった理由で遅いって言ってたのかにもよるんで何とも言えないけど、これは間違いなくクソ
今の現場にもいるけど、自分はイケてると思ってて痛々しい
未だにjoinが重いとか思ってんのかなぁ。。。。

>>83
へー
どうやって一括で発行するの？
List化してListで発行する感じ？

ループを回すってことは条件の値を変えてるんでしょ

たとえば

こうやって1件ずつ取得してるのを
select id, name from user where id = ?

これでまとめて取得するとかじゃないかな
select id, name from user where id in (...)

insertやupdateならバッチ更新を使ったりとか

>>84
最初にリスト化したやつをループで取得するのっていわゆるN+1問題でコスト高い
のでモデルで定義した関連を含めてjoinした結果をORマッパー使ってマッピングして扱う
何言語なの
springならOneToManyとかrailsならhas_manyとか書いて無い？

joinに時間がかかるかは環境による一概に問題ないとは言えないかなあ
育ってきた環境が違ってカルチャーフィットするのに時間がかかることはままあることよ

in句は上限数があったり、インデックス使えなくてパフォーマンスに影響したりするから
個人的には、積極的に使用しないかな
joinでテーブル作って条件で絞り込んだ後にバッチ挿入/更新がいいと思う

どんな環境か気になる
よほどDBの設計が特殊なのか?
今の現場は、単純に遅いjoinのチューニング方法分かってなかった

さすが自演スレだけあってバカしかいなくて笑えるｗ
>ループの中で一件ずつSQLは普通にマズイ

こんなもん状況によるし一件ずつ流すほうが正解の場合のほうが多いのもわからないって相当経験浅いゴミ
こんなゴミスレはとっとと削除依頼出してこいゴミ

>>90
具体的にどんな状況で？

そもそも1件ずつっていうのはCUDのこと言ってるだろうし
CUDの場合は1回でSQL発行なんてできねーからな
どんだけバカスレだよ
とっとと削除依頼出してこいゴミ

まあデータ量やDBによるかな

>>90
普通で常識的なアンチパターンなんだがw
そんなことすら知らないの？

この口汚いアホが小規模案件しかやったことがない事が良く判ったよ

どこの世界にSELECTで条件1件ずつ作って流すバカいるんだよアホ
はよ削除依頼出してこい

ほらホームラン級糞バカ>94様がすべてのＳＱＬ1回で発行してくれるぞ
糞バカ同士ホームラン級の糞バカを崇めよ
とっとと削除依頼出してこい糞バカ

>>95
取得されるデータが少量なら別にいいっしょ

>取得されるデータが少量なら別にいいっしょ
頼むからもう会社に行くなバカ
自演でスレ加速させるなくそばかゴミ

バッチ処理じゃなくてWebのリアルタイム処理なら1トランザクションあたりに扱うデータ量は限られるからね

この口汚い奴は友達ゼロ・童貞・無職だから相手にする必要なし

あげるなバカ！
はよ削除依頼出してこいゴミ

>>98
やだ、元気に出勤する

反論できないからホームラン級のバカが逃げたｗｗｗ
バカなんだから思い付きでレスつけるな糞バカが
ほんとこういうバカスレってバカしかいないからレスつけたくなかったんだが
あまりにバカすぎてレスつけずにはいられなかった
とっとと削除依頼出してこいゴミ！！！

N+1問題もしらないんだwwwwwww

少なくても自演ってのは間違ってるぞw

>>104
こういうふうに名前を覚えてドヤるのは違うと思う
名前を知ってるからなんなのって思う

>>104
それなw

ほらほらほらホームラン級糞バカ>104様がすべてのＳＱＬ1回で発行してくれるぞ
糞バカ同士ホームラン級の糞バカを崇めよ！！！！！
いまだにSELECTとＣＵＤ混同してる伝説のホームラン級池沼様だぞ！！！！
おぼえたてのN+1問題で一生懸命反論してるつもりだぞ！！！！！
ＣＵＤのN+1問題が世界のどこにあるか探してこい糞バカの同士たちよ！！！！

とっとと削除依頼出してこい糞バカ池沼！！！！！！！

本当に知らなかったのかよ....

常識的とかアンチパターンというのも誰かが作った価値観に便乗してるだけで
自分で考えてない感じがしてもにょる

一人で一生懸命SELECTのループの話してるホームラン級の池沼早くだれか引き取ってやれ糞自演バカども

バカすぎる糞スレ
とっとと削除依頼出してこい糞バカ池沼！！！！！！！！！！！！！！！！！！！！！！！！！！！

ループでインサート！アップデート！デリート！！！

池沼「アンチパターンだ！！！！！！！！！！！！！！！！」
池沼「Ｎ+１問題だ！！！！」


管理者「この池沼クビな」

とっとと削除依頼出してこい糞バカ池沼！！！！！！！

>>111
DBで一番時間がかかるのはSELECTなんですよ

>>108
SQLの発行回数を少なくすれば良いっていう状況もあるけど
複雑なSQLを分割してSQLの発行回数を増やしたが良い状況もあるので
1つのSQLにすれば良いんだっていうのはバイアスでしかないかな

まあ普通にinでも最近はindexが効くからそれでいいんだけど

全件取ってきて配列でループさせる方法もある

他には対象idを一時テーブル作ってぶっ込んでindex貼って対象テーブルとjoinで一発とか

更新系はbulk処理で

inでindex効かなかった時代があるん？
not inでindexが使われないのはわかるけどinでそういうことあるん？

>>116
昔のMySQLはindex効かなかったよ
だいぶ前の話だけど

>>117
へー

DBはいっさい信用ならんから条件文取り払ってデータ全部ぶっこ抜いてきて
テキストファイルに出力してテキストファイルをループで処理したりはよくやるけどね
削除依頼君にもおすすめの処理方法

わざわざテンポラリテーブル作るのって何で？
普通に自己結合しとけばいいじゃないの？
in句の中身多くなるとフルスキャンになるとかはあるけど

>>119
信用ならんDBって何使ってるんだw

ループでSQLを発行して1件ずつ処理するやり方はメモリの使用量を最小化できる方法でもあるので
アプリケーションサーバのメモリがカツカツで時間がかかってもよいので
とにかくメモリの使用量を抑えたいってときには有効

>>121
Oracleですね、サーバはオンプレミス
ハードが貧弱なせいもあるけどね

だってクエリ発行して応答が返ってこないんだもん
フィルタリングもソートも自前でやったが速い環境を僕は知っている

>>122
なるほどね
ええやん

>データ全部ぶっこ抜いてきて

これが超スーパーホームラン級池沼の出したN+1問題の解決法
今の現場の新卒がプログラムでこれやってて全部書き直させた
ほんとこの世から消えてくれ糞ごみ
はよこの糞スレの削除依頼出してこい糞バカ池沼！！！！！！！

>>120
別に結合一発で済むならそれでいいけど、一件一件SQLを発行しているとなるとDB以外の外部要因が絡んでいるだろうから
あと複雑なサブクエリでindexが効かないとき等も一時テーブルに結果を一旦逃げしたりする

>>126
データを全部抜くのはDWH構築や分析でも良く使われているが

>>123
oracle詳しく無いけどメモリ増幅、ssdとかfusion io使うでほとんど解決よ

>>126
今の現場っておまえ派遣かSESだろw

プログラムで全ぶっぱするゴミの話してるのに分析にすり替える池沼
もういいからレス付けないでとっとと削除依頼出してこいゴミ！！！！
SQLでできることをプログラムで書くなキチガイ池沼！！！

>>131
マイクロサービスでも似たような処理になるよ
知らないの？

反論できないからっていちいち話そらすな糞バカ池沼
おまえレス返す価値もないほどのバカって自覚あるのか？糞ゴミバカ
どうせお勉強中の無職のバカだろうけど
もういいからレス付けないでとっとと削除依頼出してこいゴミ！！！！

>>133
はいおまえの負け

SQLなら2、3行で済む処理をプログラムで分岐させて格納して100行近い超大作のゴミコード書いちゃう池沼がお前ら
マジで世界から消えてくれ
池沼専用の平行世界で好きだけ池沼コードでも書いてろゴミ
もういいからレス付けないでとっとと削除依頼出してこいゴミ！！！！

>>131
SQLで書いたら応答が返って来ないの！そんな状況でも業務を回さないといけないの
SQLで書くべきだなんてしょせんは綺麗事ですわ
たとえ醜かろうが業務を回せるのならそれで良いって状況を僕は知っている

>>127
なるほどね〜
バッチ処理型でしか使わないindexをパフォーマンス要求されるところで貼るのもなーって感じはする

マイクロサービスはそうなるね

>>135
> SQLなら2、3行で済む

2,3行で済んでも処理が終わらなかったら元も子もないよ
プログラムの行数を減らすのが仕事じゃないからね
泥水すすってでもやり遂げる気持ちが大事

>>139
そうそう、泥水吸うような処理になるときがあるね
他人から見たら理解されないような意味不明なロジックになるので説明が大変

どれもこれも完全に状況次第なのでなんとも

ぶっこぬきも小さなマスターテーブルで絶対にデカくならない確信があるならありだし
1000万件でやってたらアホだし

そうそう顧客の課題解決が重要だぞ

明日もみんなジャバゲッティ作るのかい？
自分はrubyとtsだが

>>130
僕もSESだよ、ちなみにOracleを実装した人もそうだよ

>>143
作るねえ、作っちゃうねえ～

バッチのフレームワークってみんな何使ってる？SpringBatchとか？
ちなみに僕は使ってないPlain Javaでゴリゴリ系

バッチはシェルとか

aws batchでゴリゴリ

まぁよくわからんけど良い意見交換できてよかったね

SQLってどこで学べばいいんだろ？
なんか色々やり方あるみたいだしそういうの勉強しときたい

>>150
こういう入門書読んで実際に触ってみるといんじゃないかな
https://www.oreilly.co.jp/books/9784873119588/

>>151
ふむふむサンクス

>>150
プログラマのためのSQL 第4版

SQL出来ますって言ってるやつに100億件のデータ渡したら処理に1時間かかるコード書きそう
データ件数が膨大になって単純な検索ではやれなくなってきたところから技術力が影響する
100万件のデータくらいなら小学生でもいけるっつーの

100億は多いな、インデックスが使えれば問題ないだろうけど

100億だと昨今はRedShiftなりBigQueryなりTDにぶち込むから小学生SQLでも充分

そんなビッグデータ扱うチャンス無いだろ？

ユースケースによるかな
50億レコードの基盤システムをmysql(オンぷれ)で捌いてたけど責務を分割して機能をシンプルにできたからってのが大きい
分析に使うんだったらbigquery, redshift, athenaでいいと思う
aurora mysqlとかだったとしてもパラレルクエリの使い方知ってさえいれば簡単に高速化できちゃうんだからな。。。
技術力必要なシーンがawsに取って代わられてるぜ

うっかり全件取得してしまってクラウド破産

1日1拠点で多いところだと100万件ぐらいデータ発生してたな
しかも朝夕に集中するから波もある
今思えばけっこうな量だわ
SELECT COUNT(*) FROM hogeとかでも数分かかってたよ
うかつにSELECTするなって言われてた

>>160
独学で学習中だけど、こういう場合は別のテーブル(集計用のテーブル)に作っておいてそこにアクセスするって感じでok?
(select count(＊)を使うくらいなら)

脳死でexplainつける
予算割けるならユーザーに影響しないように分析用のリードレプリカ作る
物理削除しないならmax関数使えないか考える

気にしてるのが負荷だったら分析用テーブル作っても問題解決されないなぁ

count(*)って今はオプティマイザがいい感じにidだけ指定に変えてくれたりする
show warnings使って最適化後のクエリみた？

javaって文字が見えただけでこの会社やめとこってなる

java17ならいいよ

８以降なら

>>58
Googleでは継承は原則禁止だね

そりゃ優秀だな

グゴったら継承アンチマンの言い分って保守しずらい＆スッパクラス直しずらいっていう雑魚によくいる低次元の主張だった
要件と仕様が明確で遥か先まで見通せるなら別にいくらでも継承してもいいよ
継承かコンポズソンかの違いだけだが馬鹿に合わせて毎回派生クラスにコンポズソンパトゥーンでメンバ持たせるの美しくないし
まぁここのチンパンジーどもにいってもわからんだろうけど

チンパンジジー

継承なんてフレームワーク側が使うもんでしょ

>>166
ムスビ嘘をつけ！

>>168
チンパンジー相手に喜んでいる人生なんて哀れそのものだね

フレームワーク側も使わねーよ
全ての場面でmix-inで十分で、わざわざあえて継承持ってくるのがmix-inよりも適切だって場面が無いと思うけどあるなら例をくださーいｗ

>>173
そんなもん山ほどあるわ、具体的には言えないけど

継承いらなくね？派：　俺、Google
継承は必よう派：　>>174

期待しているよ

俺「Googleは継承使わないんだーへー」
https://github.com/google/guava
俺「継承使いまくっててクッソ受けるんですけどｗｗｗｗｗｗ」

継承いらなくね？派：　お前
継承は必よう派：　>>174、Google

Googleはもう俺の女

JavaだとInterfaceのDefaultメソッドがmix inだが継承使わずDefaultメソッドで全部やるのは狂気の沙汰としか思えない

継承使わずに作られたフレームワークなりライブラリのリポジトリ貼ってくれー

Goにはクラスも継承もないしな
GAFAMが共同でRust Foundationを設立したRustにもクラスと継承ないしな
不要と結論が出ているため最近のプログラミング言語には最初から存在しない
もちろんそれら各々の言語で書かれた各分野のフレームワークがある

バカ乙
GoにはプロモートフィールドがあるしRustにはトレイトがあるわ
継承という言葉を使わなかったら良いってもんじゃないんだよ
継承と同じことをやる継承のようなものがあったらそれは継承だよ
ダック継承だよ

Goにクラスがないっていうのもウソ
クラス構文がないだけでやってることはクラスと同じ
書き方がダサいだけ

あえてダサくすることで俺オシャレとか気にしてませんからと主張しつつも意識しまくりなダサい言語それがGoとRustです

Goにクラス構文が無いって、じゃあオブジェクトを作りたい時
Goではどうしているんですか？

>>184
type Cat struct {
}

func (cat Cat) meow() {
　fmt.Println("にゃーん")
}

func main(){
　cat := Cat{}
　cat.meow()
}

>>185
詳細は分かりませんが、main関数の中でインスタンスを作って、
そのインスタンス由来のメソッド呼び出しをしているような…

>>185
お礼するのを忘れてました、コードを示して頂きありがとうございます

>>171
！！！？？

これからクラス構文あった方が実装しやすい気が…
クラスがないことのメリットがあんまり分からん

自演でスレ伸ばすのやめろゴミ

糖質？

golangではクラスに該当する概念に相当するものがstructということであって存在しないってわけじゃないと思う
swift,c++にはclassとstructが厳密には振る舞いは違うけど同じような場面で使えるようになっていて言葉の定義は非常に曖昧
goではstructで行きますねーって話でしかないような気がする
継承もextendsとか<とかimplementsとか書かないだけで同じような振る舞いはできる
oopの言語パラダイムを否定する要素が何なのかよくわからない

結局javaがやりたくなってるわ

>>192
結局そういうことやし逆に構造体だけ使う利点があんまわからんのよな
場合によってどっちも使えた方が便利じゃねって思う

Goと同様にクラスも継承もないRustが分かりやすいかな
Rustではクラスとはかなり異なるtraitを用いるけど
このtraitは様々な型に対して横断的に適用される

例えば表示が可能な型の集合を考える
これはすなわち文字列化できることも要請されるわけだけど
文字列化可能なスーパークラスを用意してそれを継承するという実現方法は様々な問題がある

Rustではクラスが無いのでこの場合は文字列化可能なことをトレイトを用いてtrait ToStringで表す
このtrait ToStringはStringを返すメソッドto_string()を持つので各型ごとに実装する
ジェネリクスとも相性がよくジェネリックな関数の引数の型Tに対してtrait ToStringの実装をしていることを制約させることで
そのジェネシスな関数内で型Tに対してto_string()を適用可能となる
つまり、「～の操作ができる」ことを意味するために各traitをいくつでも用意しうる
そして各型はそれら多数あるtraitのうち必要とすべきtraitをいくつでも実装していくことでできる

RustはRustでクソな感じがする
第二Javaっつうか

RustはCで書いた時とほぼ同じアセンブリ生成コードとなり速度が同等な点が画期的
Javaとは異なりRustはガベージコレクションが無く高速で省メモリ
その上でRustは常に安全に即座に自動的にメモリ解放されるから使いやすい

>184こういうガチで分かってないのも多いし
クラスのないプログラム組める人全然少ないんだろうな

必要なのはインスタンスが生成出来て、
そのインスタンスの中に状態を保存できる変数がある事
まぁそれでプログラム組めることが良くわからないよーって人達がlambdaをスルーしちゃって
手続き型言語作って、無意味な遠回り30年くらいをIT界隈が過ごしてきたんだけど

よくわからんな

言語の実装なんて宗教論争の塊みたいなものだから継承があろうがなかろうがそれは宗教の宗派の一つでしかなく優劣の材料にはならんよ

var f = new　class or new lambda{ lambda { } }

C言語作者がGO作ってんだよね
Syntaxはどんなカオスでも良い条件でマクロとか関数ポインタ乱用でCでクロージャ・lambdaの実装って出来るんだろか
文字列を読み取ってDSL化するとかってのは無しであくまで静的に

ガベジコレクタがないとクロージャオブジェクトを管理するのは難しそう

"printf"を文字列で関数に渡してprintfが呼び出セル場所まで作れば
あとは引数を保存するだけだな
手続きコードは書けないけどやろうと思えばギリいける

コード保存は無理だから関数名と引数だけを保存して後でまとめてrunって感じか
シンタックスはゴミになりそうだけど一応いけるね

>>202
クロージャ使いまくりのRustはガベージコレクションが無くてC言語とほぼ同じ速さで動くよ

RustにGCがないのは初耳

ライフ管理がキッチリ出来ればガベコレなんかいらないんだよなぁ
ガベコレが定期的にゴミ集めする仕組みの語であればだけど

Rustはムーブセマンティクスを使って参照が一つにしかならないようにするのか
参照を数えてるわけではないので参照カウント方式のGCとは違うわけね
コンパイル時にメモリの解放漏れが検知されるのはすばらしいな

いやなんでlambdaからGCの話になるｗ

ずれてんなぁ

ずれてない話おなしゃす

VBの縦横無尽さに比べたら天国だろ

VBに名前空間とラムダ式を追加して参照渡しをできなくしたらJavaと同じくらい使いやすくなる気がする

vbでもいいコードはあるんだよね

VBは大勢の初心者を受け入れてきた
いま現在ではJavaやPythonに糞コードが多いように
当時の受け皿だったVBに糞コードが多かっただけなんだ
さらにその前はCOBOLにも糞コードが多かったんだ

また、VBシリーズ（そして行番号BASIC）は様々なOSや技術の過渡期に活躍してきた
マイコンからMS-DOS
MS-DOSのコンソールからビジュアル化
MS-DOSからWindowsへ
int21hからwin32APIへ（当時はVCまわりの整備が遅れていたのでVBは救世主だった）
そしてwin32から.NET

全ての技術の変遷をVBシリーズは見守ってきた

これだけの荒波に揉まれても既存のソースを救い続け、そして新しい技術に立ち向かう助けをしてきた
VBこそ現代のモーゼであり箱舟なんだよ

新たなコピペの誕生を見たw

長野オリンピックのシステムは当初Smalltalkでオブジェクト指向を駆使して作ろうとしたんだけど
うまくいかなくてVBで作るよう方針転換して大成功をおさめた

理論がどんなに優れていても実態が伴わないと絵に描いた餅でしかない
VBはSmalltalkよりもオブジェクト指向の機能は少ないけれども現実的な最適解であったように思う

VBやExcelを開発した人たちは天才だよ
どんなバカでも使えるツールというのはそう簡単に作れるもんじゃない

まあ、VBやExcelはバカには使えない

業務でしか使わないようなヘンテコなツール言語規則いくら覚えてても何も凄くない
単なる奴隷の鎖自慢であって
金持ち連中の事情が変われば一気に使わないゴミと化す
そんなもの覚えるために1分でも時間使った時点から負けてる

>>219
有名言語習得してる人なんてほかにいくらでもいるからね
JP1/Script極めてますなんて人のほうがブルーオーシャン狙える

>>219
もしかして：Ja*a

MSはもうVBに新機能を追加することはないって言ってるね

新プラットフォームには対応していくよ
.NETが新しくなってもVBが使えなくなることはない
VBの需要はC#みたいな曲芸じゃないからね

VBはC#みたいな未完成の言語じゃない
すでに完成していて手を加える必要がないからなんだ

MS「んじゃセキュリティパッチもいらないな、コスト削減・・・っと」

外部ネットワークに繋ぐものは.NETで置き換えるでしょさすがに
閉鎖されたネットワーク内で使うぶんにはセキュリティパッチいらんし
工場のシステムなどでほそぼそと使い続けられるんじゃないかね

念のために行っておくけどVBのサポートはずっと続くし
現場の「余計な機能つけんな」って声に対応しただけであって
これからもVBはMSの主力言語だからな

新機能つけない事
サポートが続く事

これらが同時に実行されるのがプログラミング言語史上はじめてなので混乱してると思うが
.NETの新機能はVBでもサポートされる
VBの言語としての新しい文法や機能が追加されないという事

この違いがわからないとまるでVBがなくなったり成長しないかのように錯覚してしまう

ああ、君が言ってるVBはVB.NETだね
僕が言ってるVBは旧VBのことで、僕が言ってる.NETはC#とVB.NETのこと

VB.NETは古い言い方なのか
いまはVBと呼ばれるようになってるのね、知らなかった

旧VBといえばVB6とVB4が主流
今でも稼働しているシステムはVB6だろう

Oracleのクライアントとして活躍した
OracleといえばDelphiも相性が良いとされていて、まさにクライアントサーバ全盛期だった

Windows10でも稼働可能で延命処置が施されてきた
いくつかのバージョンの.NET開発環境があればエラーをモグラたたきのように直すだけで最新のVB.NETに移行できたのも魅力だ

しかしながらWindowsにも32bit切り捨ての波が来てしまった
VB6アプリを64bit環境で動かすのは難しい
本来なら64bitOSでも32bitアプリは稼働してくれるのかもしれない
しかしながらミドルウェアと連携していく上で（おそらくはOracle関連で）つまずくだろう
それでもVB開発者はその知識と問題解決能力でVB6アプリを稼働させ続けるのだ

VB6はその筋に詳しい人たちが延命に力を注いできた
例えネイティブがダメになったとしても仮想化で動き続けるだろう
ファクトリー向けPC9801だってまだ稼働中なのだ
VB6はまだまだ戦えるはずだ

VB6は永遠なのだ

>>226
終了してからだって一定期間はサポートされるが・・・
MSという会社が無償でやってるようなもので
VBのメンテナンスしようが全く金になってないと思うけどね

プログラミング言語を開発するだけでは金にならんよね
企業は開発ツールの販売や実行環境の有償サポートで金稼ぐことになるんだろうな
マイクロソフトもオラクルもようやっとる

Rustはいろんな企業から金銭の援助を受けてるようだ
期待度の高い言語ならではだなー

GoogleのGoはあれは収益に繋がってるのかな
広告で稼いだ金を使って開発してるようではあるけど
優れたプログラミング言語を提供することで
Googleの信頼や名声は高まりそうではある

MSが色々言語出すのはおそらく他企業の作った言語に居座られない為に頭の上抑える目的でリリースしてると思う
俺はMS産言語やIDEについてそういう見方してるからVBはMSの企業戦略という中で見たって役目終えてねーかという

MS OfficeではVBAが使われてるからそのユーザからするとVBの方が使いやすかったりするのかなとは思うけど
VBAがわかるならC#は簡単だと思うんだよなあ

BASIC言語の開発はMS設立時から行われていてMSの出発点でもあるから経営者の思い入れは強いだろうけど

>>231
GAFAMを中心にRustの採用・支援が多い理由は
Rustがプログラミング言語の歴史において革命的な転換点の存在だからのようだね

今までのプログラミング言語は
①『自動的にメモリ解放され安全だがガベージコレクションがあるため少し遅い言語』
と
➁『ガベージコレクションが無くて高速だがプログラマーの責任でメモリ解放を行う必要があり少し危険な言語』（C/C++など）
の
どちらか二種類しか無かったところに
③『自動的にメモリ解放され安全だがガベージコレクションが無くて高速な言語』（Rustのみ）
という良いとこどりの安全で高速な言語が初登場したようだね

まともな言語ならGCオフにして手動開放オプションくらいついてるから・・・

ゴミみたいなスレタイでゴミが立てたスレを伸ばしてんじゃねーよ糞低能ども

面白いオモチャが多いからな

話についていけず発狂してるやつおって草

こういう入門書の1ページに書いてるようなゴミネタで話についていけないとかのたまうのがゴミなｗ
バカなんだからさっさと削除依頼出してこい池沼バカ

効いててワロ

バカが一生懸命ageて書き込んでも無駄
消えろゴミ

A言語にはある　

必死なJava上げの人もいなくなっちゃった
1999年発行Javaで覚えるオブジェクト指向プログラミングの分厚い本は鍋敷きにしてる
光栄に思うがいい

>>243
面白そうな本だーね

20年前のオブシコと今のオブシコどう違うんだろ

昔はソースの行数を減らすのがえらいみたいな風潮だったけど
今は保守性大事だよねって感じじゃね
いわばPerl風からVB風に変わっていったと思ってる

20年前のオブジェクト指向
「これは神に与えられた唯一の正しい手段であり、全ての要素を必ずオブジェクトとして扱い、オブジェクトを継承し再利用されねばならない」

今のオブジェクト指向
「オブジェクトとして扱うと楽になるものと、そうでないものがあるので、使い分けましょう」

Rust上げしてる人から20年前にJavaを崇拝してた人たちと同じ臭いがする

今趣味でブラックジャック(トランプ)作ってるけど、
クラスが無いとコード作成なんて考えられんよ

トランプゲームみたいにオブジェクト有限個数のものはちゃんと考えればコードがすげえ圧縮されるぞ

【逆流性食道炎予防の八箇条】
食の欧米化やストレス社会により新たな国民病となりつつある逆流性食道炎をみんなで予防しましょう　

其の1：食べすぎないよう腹八分目
其の2：消化のよい食事を心がける　
其の3：ゆっくりよく噛んで食べる
其の4：就寝前の食事は避ける（就寝前2～3時間）
其の5：食後すぐに横にならない（逆流を防ぐ）
其の6：肥満に気をつける
其の7：アルコール・甘い炭酸飲料を控える
其の8：喫煙を控える

チャーハン下さい！

>>239
とゴミが申しております

なりがちって聞いたこと無いな

とにかく継承を使いまくって差分プログラミングバンザイの時代があったんよ
Timestamp型がリスコフの置換原則を満たしてないのがその名残
標準ライブラリでさえ迷走していた時代
一般のアプリはもっと酷かったしオブジェクト指向を語る技術書もだいぶあれだったよ
とにかく全部オブジェクトにするのが正義って書いてある本もあった
僕はそれを読んで実践して大爆発した

Javaみたいに強制的にクラスを定義させる言語はプログラミング初心者にドメインモデル貧血症みたいな勘違いオブジェクト指向(オブジェクト指向では無い)コードを量産しやすい印象はある

以前、オブジェクト指向を理解していない人が関数型プログラミングをオブジェクト指向の代替パラダイムと勘違いしてドヤ顔で語ってる人がいたが、その人の提示するオブジェクト指向のサンプルコードってほぼドメインモデル貧血症

ドメインモデル貧血症だからダメなのだは思考停止だと思う
それこそオブジェクト指向の神格化でスパゲティが量産されてたころの考えかたじゃないかな
僕は好きですよドメインモデル貧血症
マーチン・ファウラーの功罪

ラムダ式、Stream、Record、パターンマッチ
Javaは関数型プログラミングに舵を切ってるね
オブジェクト指向を90年代からとことんやって限界が見えたってことだと思う

>>256 >>257
こういう勘違いしている奴がいるから困る

>>256
https://en.m.wikipedia.org/wiki/Anemic_domain_model

アンチパターンって十分考察されたから名前が付いてるんやで
思考停止ちゃう

>>258
んだとおらあ！ぶっ殺すぞてめえ、はい論破

>>259
90年代の考えかただよそれ

トマトは昔欧米で毒リンゴと呼ばれていたけど
いまでは健康的な野菜の筆頭でしょ
ドメインモデル貧血症はトマトということですね

アンチパターンというのも考えものだよね

オブジェクト指向によるスパゲティコードがよく作られていた頃は
デザインパターンが重宝されてとにかくたくさんのデザインパターンを
使うことが良いことだとされていたけれどもそうして作られたプログラムは
オブジェクト指向迷路であった

パターンと名のつくものに杓子定規に従えば良いものができると思い込む
物事の表っ面しか見ない浅はかな人たちがスパゲティを作り出した

そうした人たちはアンチパターンと言われているんだからきっと悪いものだ
アンチパターンが使われてるからこれはダメなコードだとなんの疑いもなく
思い込んでしまうのだろうなと僕は思いましたよ

自分で考えずにパターンに従おうとするのがダメ
自分で考えてパターンと同じ結論に至ったから適用するならわかるけどね
誰かがきっと考えたんだろう自分もそれに従っておこうなんて受け身の付和雷同的姿勢では
いつまでたってもスパゲティ製造工場の作業員レベルだよ、出世したとしても工場長だよ

もっとアグレッシブに自分が新しいパターンを見つけ出してやる他の人にはわからなかったことも
自分ならわかる、自分はいますべてを理解したナウシカだ、とそういう攻めの気持ちでいかないと
おいしいトマトでミートソース作ってこ

オブジェクト指向によるスパゲティの良い例、スパゲティ屋さんになりたい人は手本にしたが良い
https://github.com/Hello-World-EE/Java-Hello-World-Enterprise-Edition

マーチン・ファウラーという頭の禿げたエッチな顔したおっさんが
ドメインモデル貧血症はアンチパターンと言った
だからきっと正しいに違いないと思ってるに過ぎないよね
それってただ権威にすがってるだけだよね

マーチン・ファウラーの悪口を言ってやろうと思って
Wikipediaを読んでみたけど特に何も悪く言うようなところはなかったわ
マーチンはマーチンなりに頑張ってる僕は応援してる

90年代オブジェクト指向の可能性が未知で期待に満ち溢れていたころに
プログラマーとして仕事をして2000年にトートワークスでコンサルタントになったんだってすごいね

二十数年前といえばXMLがもてはやされてこれからはXMLの時代だと言われたころでもあるなあ
工業では重厚長大なんて言い方があるけど、ITでは90年代のオブジェクト指向やXMLが重厚長大にあたるのかもしれない
関数型プログラミングやJSONは軽薄短小

設定ファイルにマークアップ文書用のタグを使うとか考えたやつを呪い殺したい

>>265
貴方は呆けてるので病院行ったほうがいいよ

>>265
セッターとゲッターだけの無意味なクラスをオブジェクト指向と勘違いしている人がいるってだけの話なのによくそこまで妄想膨らませて俺に対して権威にすがってるとかいえたね
糖質か何かか？

ドメイン貧血症はアンチパターン
アンチパターンを驀進中です

>>269
セッターとゲッターだけの無意味なクラスをオブジェクト指向と勘違いしている人がいるってだけの話なのかよ、浅すぎるだろ、なめてんのか

考えが浅いのが根本的な問題なんだよ
セッターゲッターだけのクラスがあるからダメなんだと思ってるわけだろ
それって結局はマーチン・ファウラーがドメインモデル貧血症はアンチパターンだと言った
ただそれだけを根拠にダメだと思い込んでるだけだよね
マーチンの威光にすがって盲目的に信奉してるだけだよね
オブジェクト指向を宗教化して自分が考えないことを正当化して安心してるだけだよ
多くの人がオブジェクト指向を崇めそして大失敗したことの原因が如実に表れている

ドメインモデル貧血症は1990年代後半～2000年代前半にかけて流行った考え方だが
オブジェクト指向によるシステムの開発が増えるにつれてドメインモデル貧血症を避けることが
むしろオブジェクトの密結合を招き保守困難なオブジェクト指向迷路を作る原因となることが明らかになった

実際にはスリムなドメインモデルは柔軟で扱いやすく現実に即している
ドメインモデル軽量パターンと呼んでも良く現代では積極的に使うべきパターン

ドメインモデル貧血症がアンチパターンだと思ってる人は
20年前の考え方をアップデートせずに現世をさまよってるゾンビ野郎だよ
もしくはスパゲティ工場の工場長だよ

ドメイン層以外って完全に自動生成してくれてもよくね？
なんでいまだにプログラマが頑張って作ってるんだ

Javaはどうでもいい設計思想にこだわるやつがいるから迷惑

クラス継承依存症の人は
今どきの言語GoやRustなどの継承を排除して無くした言語でパニクるだろうな

PHPのスパゲッティ具合には勝てんだろ

>>271
文脈読めない無能

単純に変数に入れるだけのセッターゲッターなんてアホみたいに作ってる化石みたいな奴まだいるのかな？

すごいことしたな

守備がガタガタやったし攻撃もサラーが覚醒終わってる

この前レインボーが爆笑に「横転したらそらスタッフの無言の帰宅か…人生何が？
誰が一番身体検査しろよ
コロナ壺田どーすんのが

ゾウより首長くして待ってるよ
ゲストにジャニーズとAKB系ばっかり呼ぶのやめーや
キャンプみたいな感じなんだ試験中じゃんびびって損した
トラネキサム酸が届いた

山田くんと鈴木くんは属性が同じなのでクラスを作って
それぞれインスタンスを立てることにした
しかし山田くんの情報を設定して鈴木くんのインスタンスに入れても
引数のクラスが同じなのでエラーにはならない

山田くんは結婚したので家族のクラスを作って
パーソンにぶら下げる(extend)ことにした
鈴木君は養子になったので養子のクラスを作って
パーソンにぶら下げた(extend)

追加仕様
佐藤君は結婚していて養子になっている
しかし家族と養子のクラスはパーソンにぶら下がっているので
2つの親からぶら下がることができない
結局、パーソンの下に家族+養子のクラスを作ってぶら下げるしかない

一般的にはクラスを捨てて継承関係をなくして共通メソッドはその機能群毎にインターフェイスを定めて各々が必要な機能のインターフェイス群を実装するのが正しい
そのためモダンなプログラミング言語はクラスを持たないものが増えているが既存のクラス依存言語では難しい面もある

エクリプス+マーベンで
java開発を半年経験して分かったこと

エ「ここ間違ってるぞ、fixするか？」
俺「おk」

エ「fixしたらおかしくなったぞ、fixするか？」
俺「よろしく」

エ「fixしたらプラグインが足りないぞ、importするか？」
俺「うん」

エ「ここも間違ってるから以下略」
俺「はい」

そしてグチャグチャのコードが出来上がった。

クラス継承なんていうダメな機能を使っていると起きる

◼︎IDEのない頃のプログラム開発
補完もシンタックスエラーチェックも何もないので
自力で調べてコードを書く
バグれば全て自己責任、必死に調べて無駄のない
コーディングスキルがついていく

◼︎IDEベッタリのプログラム開発
とりあえずIDEのエラーがなければオッケー
コードを見直すこともなく
そしてぐちゃぐちゃなコードが出来上がっていく

特にJavaのIDEは開発はこの傾向が顕著に見られる
もちろん、誰でも作れる敷居は下がったが
その代償として素人感覚のゴミコードが
大量に生み出されていく

おちんちんがお好きでしょう
もう少ししゃぶりましょう

Java脳

それってプロパティに書いてアブストラクトで
インぺリメントとかすればいいんだよね

↑
何一つ全く理解していない上にいちいち
マウントしようとしてくるバカがいるのだが(笑)

継承は悪

Java脳
「スロー！スロー！スローすればいいじゃん！」

は？大量のファイルをループ処理して
こけても次のファイルを処理するのに
例外飛ばせってか

親でキャッチしろ？
構わないが、これで5段の入れ子キャッチになるぞ

安易なトライキャッチで
ほんとJavaってスパゲッティになるな

修正するjavaプログラムのimport見ると
100以上あるんだけど(笑)
こんなフランケンシュタインのライブラリ依存なら
スパゲッティーで動かなくなるよね
メソッド名が重複して別のライブラリ見てたりするし(笑)

米高いからスパゲティにするわ

Javaの稼ぎだけでは国産米は厳しいからパスタ

Javaって
ランタイムのバージョンは乱立してるし
ライブラリもバージョン変われば全滅するし
IDEで動いててもサーバーに持ってたら動かなくなるし
コードを書くより動くための整合性を取る方が
労力かかるな

>>297
1990年代後半に使われだしたものを批判しても意味はない

Javaプログラマさん毎日スパゲティ食ってるのかと思った

お米が買えないからスパゲティよ！

本来のスパゲッティコードとは構造化プログラミングにすらなっていないようなコード。

8ビットパソコン時代のBASICなんて何がなんだかわからないコードだらけだった。

今はクラスの依存関係がぐちゃぐちゃで
「なんでそんなところにそんなメソッドがあるの？」
みたいなコードを言う

あと、クラス変数もクラス内だとグローバル変数と変わらず
至るところで値が書き変わってロジックが追えなくなる

>>302
それはオブジェクト指向設計を理解していないだけ
しかも、あなたもオブジェクト指向がわかっていない

さらに設計書を作ることを軽視しすぎている

>>302
それはスパゲッティコードではなくて、センスの悪い設計だ。

>>302
Javaは多重継承をあえてできないプログラミング言語にしている

オーバーライドができるクラスを作ってオーバーライドをするのが普通というプロジェクトはプロジェクトがおかしい。

あなたの言っているようなことが発生しないように規約を作る。
規約がなかったり、規約を守らなかったりするプロジェクトでは、無秩序になる。
コードだけを見てわかりにくいものを「スパゲティ」と呼んでいる人間は、コードという成果物だけを見ている。
結果だけを見て原因を考えていない。

スパゲッティコードは単に初心者があまり考えずに作ってしまい、メンテナンスが難しくなっただけだ。

水気の足りないそうめん

麺がスパゲッティのように絡まっていることからそう言われたのにただのわかりにくいコードをスパゲッティと呼ぶのは全然、違うしな。

mavenがすべてを解決するはずだったのに
取ってこないように設定しても勝手にリポジトリから取ってくるという
信じがたいクソ仕様をぶちこまれて天国は崩壊した
後を引き継いだのは意味不明なスクリプトども

obj1=obj2;
の後obj2を変更すると
obj1が書き換わってしまってびっくり

>>309
？

>>309
参照型とプリミティブ型を理解していない
参照渡しができない言語しか使用したことが無いのかな？

あーなんとなくわかるわ
Javaより古い言語をやってると値渡しと参照渡しは
明確に書き方が違うから戸惑うわ

ジャワティーがスパゲティにヘンソン

やばいソースなんだけど
クラス内の変数やオブジェクトはグローバルだからといって
ありとあらゆるメソッドで書き換えられててクソすぎるわ

値を取って戻ってきたらセットしてくれよ
取りに行ってその先の先の先の末端メソッドでセットとか
気が狂うわ

そういうのってファイルごと捨てて書き直したほうが速いんじゃないの

>>314
そんな見通せない巨大クラスは捨てて分割しろよ

意味がよく分からないんだけど、ゲッターの内部処理がネストしてるの？
それなら普通じゃない

何を言ってるんだね君は

>>314
逆だろ
メソッドは内部の動きカプセル化して外に対して抽象化するためにあるんだよ
わざわざゲッターで取得してセッターで更新する必要があるのはそれに反しているアンチパターン

何を言ってるんだね君も

極端な話
返り値のないpublic voidだらけなんだよ
すべて呼んだ先でクラス変数値を書き換えていると言う
これに大規模に手を入れてバグらないようにと言われてるんだけど
無理ゲーだ

【貧困】稼げないSEを退治しろ【非婚】

☆高負担で低速度で低生産だろ！☆
★文書でなく会話で作業をしろ！★

プログラマー作業を減らして
オペレーター作業を増やすな！

低技術で低収入は高技術で高収入の
技術者に迷惑だからIT業界から失せろ！

https://listen.style/p/readmaster/mcqg3wwz

>>321
カプセル化されたプログラムが優秀
セッターが露出しているプログラムは劣る

JAVA使いしかセッターとかゲッターとか言ってないんだよね
どの言語にもその概念はあるのにな

「getter/setter書いてね」
「lombokとか入れないですか？」
「？」
「いちいち書かなくていいやつ」
「なにそれ、getter/setter書いてね」

内部のカプセル化が目的なのに
何でもセッターで外部から更新していたら本末転倒だよね

人の仕事に横槍入れて余計な手間ばかり増やす奴は
いくらカプセル化してもそれを突き破ってくるんだけど

すべてのクラスの内部にアクセスできる。
っていうのもナシじゃねーけど変更ログをとるためにゲットセットをソースコード上に書かずに
外部ツール,外部モジュールincludeするなりして対応すりゃいいのに
アホルールに縛られてるのまさに奴隷言語

eclipseに追放されたlombokがいいものなはずがない！

スパゲッティーコードだらけのプロジェクトに入った
今更共通化したりリファクタリングすることもできず
既存のメソッドは依存が強すぎて使いまわすこともできず
亜種のメソッドが大量に生まれていく

正直、Java系のプロジェクトは一斉に素人集団を採用したから
結果、手の施しようのないツギハギだらけのフランケンシュタインプログラムが
大量に生まれていると痛感させられる

設計で共通化されてないものを勝手に共通化するなっつってんだろが
どうせテスト工数がボトルネックになるんだ

ドカタは後工程のことが見えてなくていかん

どうでもいい奴がどうでもいいソフト作ってる界隈
ソースコードにもその製品にも特に意味なんてない

くやしい

JAVAプログラマはチェックのシャツをズボンの中に入れてるやつが多い

外国人かな？

いろんなプロジェクトで
いろんな言語のソースコードを見てきたが
Javaで書かれたコードが1番ぐちゃぐちゃ

なんでなんだろうな

なんか小学生が自由気ままに描いた絵のような感じ
後からメンテするやつが地獄を見ている

それは人次第、とわからないやつはバカ

そう
その通り
そしてレベルの低い奴らが
大量に集まっているのが
Java

スパゲッティーで
ぐちゃぐちゃなコードを作っても
誰も指摘しないのが
Java

いろいろなプロジェクトみてると、設計からドヘタ。
メーカーさんが設計するからまともなもになっていない。
しかもメーカーさんのミドルウェアとかまともな設計になっていない。
javaはオブジェクト指向であって、手続型言語じゃねーぞ。
個人で書いているちゃんと設計したプログラムは、メソッドなんか中身はほとんど1行。
indexとしてのint以外、intやStringなど使わない。
classはほぼイミュータブル。
コンストラクタはprotectedかprivate。

クラスなんか使ってるやつがまともなわけがない

classを使わなければjavaらしいことはひとつもできない。
ものによってはArrays.stream(args).からすべてクラスを変換していって出力を行い、
完結するようなものも作れる。
streamだけでもプログラムを作れるw
もちろんその中を流れるObjectのClassは作らねばならないが。

for のネストを繰り返すよりは
ストリームのほうがいいんだけど
改修しづらいんだよ
大抵はパッチロジック的なコードを入れなきゃならないから
結局、forネストの方が変更しやすい

それは技術力が低いから

うん、その通り
しかし、初心者にもメンテさせていかなければならないこの業界では
何をしているのかわかりやすいコードの方が良い

エクリプスもさ
シンタックスエラーだけじゃなくて
だめなコードを指摘するように進化しろよ
forループの中にログも出さずにreturn入れまくったり
try catchを5重くらい重ねてthrow, throw, throwと連鎖throwする
クソコードとかさ

EclipseはSun(micro systems)の亡霊だから・・・

AIにコードぶん投げるプラグインぐらいあるやろ

だいたい、開発環境で１画面に収まらないようなメソッドは書かないように指導すべき。
意味のあるif else ifの連鎖やswitch文やswitch式はしかたないが、
ガード句がたくさんあったらそれは設計から見直すのがベター。
というか、ガード句を使えよなという場合の方が多い。
基本的にメソッドの本体は１行で、英文のように読めるのがベスト。
unitテストは必ず書く。テストソースはソースと同じ階層のパッケージに置く。

ベタ書きのほうが書きやすいし読みやすい
関数化して
ちょっとしたことを理解するのにあっちゃこっちゃ飛ばされて
どこに何が影響してるかわかんない
リグレッションテストを考えると工数圧縮効果は皆無
なんでみんな関数化好きなの？

呼び出しのたびに変数の読み替えが発生し可読性を下げ
スコープを区切るためだけに無駄な初期化処理や設定が再走し品質も下がる
関数の品質を担保しようとすると
明らかに業務にいらないテストをせざるを得ない

世間の言う事とかなにもかもうそじゃないか

そもそも1関数= 1クラスであるべきだけどな
だからクラスの中はメイン1つで良い
結果、巨大なバッチプログラムなど
インポート文だけで100を軽く超えるw

関数というかメソッドだけど、関数なら基本は第一級関数であるべし。
オブジェクトもワーキングに使う以外はイミュータブルであるべし。
基本的にクラスも関数も隠蔽するためにあるので中まで追いかけなければわからないようなものは
設計ミス。
なんていってみても、現実に存在するjavaプログラムは理想から遠いものばかり。

だってみんなcobolの感覚でjavaコードを書くんだもの

>>349
正しい
巨大な関数を書く人は整理のできない頭の弱い人
読みやすく保守しやすくするために関数を小さくするのが正しい

ガード句なんてあるのSwiftだけだろ
てことはMacだから上っ面重視の田舎者にはふさわしい
好きなだけキラキラコーディングしてろよ

引数に強制的に名前つけるせいで情報量が無駄に多くて脳がつかれるから関数化で畳んでしまいたくなるのはわからんでもないがな！

なんか気がついたら使ったこともないMacアンチになっていた

[[int]]
あほ

あーあ
地雷くんに作らせたら
やはり地雷高原のプログラムが出来上がっちゃったよ

ごめんなさい

そして地雷高原のプログラムの
デバッグをさせられている
地獄すぎる

お腹すいた
Javaでスパゲティ生成するわ

最近はフライパンで作るのが流行りだし、
スパゲッティってスパゲッティというほどにスパゲッティにはなっていないんだよねぇ。
オリーブオイル入れるからつるつるしてるし。
javaにしても、builder形式やらstreamやらでスルッと一本の流れで作るしねぇ。
switchもswitch文だけでなくswitch式が使えるし。
ifによる分岐構造もguard句でスッキリしてるし。
classはrecordかすべてfinalなイミュータブルで、作業用のclassやlistやmapを除けば、
これらもイミュータブルにしてるし。
30年も使ってるとスパゲッティなものってどうやって書くのかわからなくなってきている笑。

結局人間の性格が出るんだよ
1つの変数に全然違うものをどんどん入れ込むやつもいるし
計算した結果を入れる変数に計算する前の値を入れたり
実際に動かさないともうコードが追えない状態

あとIDEはなんでnullで返すメソッドを判定できないんだ
nullで返ってきたオブジェクトにメソッドを呼ぼうとして
ぬるぽが出まくってるんだけど
地雷高原のプログラムは後で改修する人間が本当に辛い目に合う

そおっか、変数を使いまわしするのか。そんな使い方ってすっかり忘れてた。

細かく{}で囲って変数のスコープを区切るのが禁止されててな
新しい変数を宣言しまくらないといけないからそいつらがどんどん増えてずっと残る
それがいいことだと思ったがそれで参照変数間違えたバグったことあるので反省した

tmp変数は毎回上書きしたほうがマシだ

変数はスコープがあってなんぼだと思うが、
まあメソッド自体を数行以内、できれば１行にしてるから。
name spaceの階層を分けるような設計してないんだろうなぁ。
設計レベルの無知がjavaをダメにしてる。
とくにメインフレームだしてるような大手メーカーさんが上にいるとダメな設計しか降りてこない。

タブーである長い関数を書かない限り変数名問題は起きない

>>367
参照変数間違えた
それ直せばいいだけのミス

バグはバグだ

スパゲッティーコードをパクって
さらにスパゲッティーにする
大盛りスパゲッティーコードが出来上がっているのだが
やっぱりスパゲッティーコード量産するやつって
スパゲッティーが大好きなのか

スパゲッティってわりと簡単にほぐれるよな
ビーフンとかそうめんのほうが絡まりはすごそう

スパゲティー脳人間は永遠にスパゲティーコードを書き続ける
なぜなら、それがスパゲティーだと理解できないからだ
最高のシンプルで洗練されたロジックだと思ってるからだ
もっと良い書き方があるはずという向上心は全くない

うんこしたら半分だけ拭いて充分と思う人間は
それ以上ケツを拭くことはしない

難しい数式を読める人が書いたコードは
難しい数式が読めない人からすると
全く読めないコードでありスパゲティ

ツルパゲッティ

Javaでスパゲッティってなるか？
殆どの人が勘違いしてるけどGOTO文で色々飛びまくるのをスパゲッティって言うんやで
GOTO一切使ってないならスパゲッティとはいわない

要素をgetで取得するたびに値が変わるデータクラスに会ったことがないからそんなことが言えるんだ

>>377
一般的にスパゲッティが使われる意味は新旧二つあって
一つはループ制御構文を使わずにgotoなどで流れがぐちゃぐちゃになることで古い言語で起きる
もう一つはデータ制御の観点で可変参照が複数あったりグローバル変数へのアクセスが多数散在していることにより見通せないままデータがいつの間にか書き変わってること

Javaはスパゲティなりガチ

>>377
何重にもネストしたfor文の中で
ログも出さずに突然リターンする

しかもリターンの変数ではなくnullとか0とかベタ書き
それが1カ所じゃなくてレベルが違うところで10カ所以上存在する

さらに条件分岐の先でfor文が存在して
そこからいきなりリターンする箇所もある

このコードをステップ実行なしで全て追うことができるかどうか
わかるよね？

オレ様が読めないコードはスパゲッティ

素直にわかりませんと言えるようになりましょう

MineCraftのJavaコードはスパゲティどころか難読化されていたらしいからな
それでも世間にModがあふれてる
外人あたまおかしい

だめだこりゃ
実行するたびに結果が変わる
並び順が保障されないSet配列を使いまくって
ぐるぐる回して条件に一致したら即座リターンとか
そりゃ毎回変わるわ

こういうバグ脳な奴らが大量に溢れてるな
Javaプログラマーの世界は

まあよくはないが条件に一致してればいいのでは

>>384
一般的に現在はセキュリティのためにHashSetもHashMapも実行のたびに並び順が変わるのが正しい
セキュリティだけでなくバグの早期発見にも繋がる
並び順を固定したいならそのための何らかのコレクションを用いるかソート

HashMapかLinkedHashMapかTreeMapかは悩むね。
いま、趣味でつくっているやつは、どれを使っても美しくない。
LinkedHashMapがベターか。

log(n)オーダーごときでケチケチすんなや

英語の正しい発音はスパゲリ
さあみんなでご一緒に言いましょう
酸っぱ下痢

もうJavaなしじゃ生きていけない

Javaはメモリ管理をガベージコレクションに任せる素人向け言語の割にはそこそこ速いからIT土方向けに需要があったけど
IT土方は真っ先に絶滅することになって終わりね

>>390
そろそろkotlinに移行しないと時代遅れになるぞ

スパゲッティくらいは作れないとプログラマーとは名乗れない

Javaって全て参照渡しだから
voidメソッド10回ぐらい呼んだ深淵の底でオブジェクトを更新する
くそったれなスパゲティコードが出来上がるんだな

他の言語は参照渡しはめんどくさいから
呼べばちゃんと値を返す行儀の良いプログラムが
出来上がりやすいんだよ

>>394
可変参照渡しと不変参照渡しの区別がないの？
不変参照渡しなら渡した先で書き換えできないからスパゲッティにならないよ

Javaに限らずどのプログラミング言語でも
原則「インデントを深くしない」

深くなる原因は色んな階層にある
・設計が悪い
・コーディング方法が悪い
・プログラミング言語の仕様が悪い

一番の要因は
設計者が無能

んんー？ javaでインデントがそんなに深くなるっけ？
どんな書き方しとるんだろう。
1999年に、日本にガード句がもたらされて以降は、フラットな書き方が主流だと思ってた。

レガシー遺産のやつらはVB6の感覚でJavaに移行していったから1メソッドが巨大になるんだよ

Javaの極悪コード
label continueが大量にあって
もうこれはダメだ
実質gotoだしな
なぜこれでok出したんだこのプロジェクトは

>>401
一つ外のループへラベルcontinueってbreakと同じだろ
だからその例は二つ以上外のループへラベルcontinueしている
つまり３重以上のループになっている

スパゲッティーというより
思考がひねくれているやつが仕様を書くと

カレー以外の食べ物を食べない場合に
スプーン以外のものが存在しない、かつ
スプーンに変わるものが存在しない場合
エラーとしない

こんな書き方するやつ何なんだ
お前の人生は否定し続けることで成り立ってきたのか

>>403
それな
わかりやすくロジカルに書く素養がない人わりといるんよな

PMからは進捗率を高めに報告させるためにとりあえずstaticを付けておけと指示されたことある

話題が２０年前に戻ったようでほほえましい
がんばれよおまえら

下男下女がホウキの持ち方で口論しているようなものだ
おれはもうひねくれたおっさんになってしまったので
誰にどうやって仕事を押し付けるか考えてる