プログラミングのデザインパターン勉強するやつってバカじゃね

そんなの勉強する前に
単一責任の原則とか参照透過性理解したほうがいいですよ

アダプターは知ってたら便利かもねって思ったけど

他は別にぃ？って感じ

なんで参照透過性を勉強してないと思ってんの？

お前「参照透過性」って言葉知ったの昨夜じゃん

>>4
いや概念は知ってたし
キーワードをど忘れしただけ

確かに
そんなん勉強するよりアプリ開発勉強した方が良い

>>5
一理ある。
仕事にするならソースコードを改悪しないバカにならないように意識する必要はあると思いますがね

>>9
参照透過性（Referential Transparency）とは、プログラミングにおける概念の一つです。これは、プログラム内の任意の式がその式が評価される環境に依存せず、常に同じ値を返す性質を指します。つまり、同じ入力に対しては常に同じ出力を返すという特性を持っています。

この性質があると、プログラムがより理解しやすく、予測可能になります。また、テストやデバッグが容易になり、関数型プログラミング言語で特に重要視される概念です。

Javaでの参照透過性を守った例と守られていない例を示します。

### 参照透過性を守った例

“`java
public class PureFunctionExample {
public static int add(int a, int b) {
return a + b;
}

public static void main(String[] args) {
int result = add(2, 3);
System.out.println(result); // 5
}
}
“`
この例では、`add`関数は純粋な関数です。同じ入力（この場合は2と3）に対しては、常に同じ出力（5）を返します。関数内部で外部の状態に影響を及ぼす操作は行っていません。

### 参照透過性を守らない例

“`java
public class ImpureFunctionExample {
private static int counter = 0;

public static int addAndCount(int a, int b) {
counter++;
return a + b;
}

public static void main(String[] args) {
System.out.println(addAndCount(2, 3)); // 5
System.out.println(addAndCount(2, 3)); // 5 だが、counterが変更されている
System.out.println(counter); // 2
}
}
“`
この例では、`addAndCount`関数は外部の状態（`counter`変数）に副作用をもたらします。この関数は同じ入力（2と3）に対して、何度呼び出しても結果は同じですが、`counter`の値が変更されるため、関数全体としては参照透過性を持ちません。このような副作用の存在は関数の出力だけでなく、外部状態にも依存していることを意味します。

gpt4に課金してる俺にも感謝しろ😡

>>15
「流星のロックマン」のゲームシステムにおける参照透過性の例を考えてみましょう。あるあるネタとして、このゲームにおけるバトルカードシステムを使うことができます。

### 参照透過性を守った例：
**バトルカードの獲得：** ゲーム内で特定の敵を倒すと、常に同じバトルカードが手に入るシステムを考えてみましょう。たとえば、特定のウイルスを倒すと必ず「キャノン」カードを獲得するとします。これは参照透過性の良い例です。なぜなら、同じ入力（特定のウイルスを倒す）に対して、常に同じ出力（「キャノン」カードを得る）が得られるからです。プレイヤーは常にどの敵を倒せばどのカードが手に入るかを知っており、予測可能です。

### 参照透過性を守らない例：
**ランダムイベントの発生：** ゲームでランダムイベントが発生し、その結果によって異なる報酬が手に入るシステムを考えます。例えば、特定のエリアに入るとランダムに異なる敵と遭遇し、倒した時に得られるバトルカードが毎回異なるとします。この場合、同じアクション（特定のエリアに入る）でも、異なる結果（ランダムな敵、ランダムな報酬）が生じるため、参照透過性は守られていません。プレイヤーは何が起こるかを予測できず、結果は常に変動します。

このように、「流星のロックマン」のバトルカードやランダムイベントのシステムは、参照透過性の有無を例えるのに適したゲームシステムの例と言えます。参照透過性を守るシステムは一貫性と予測可能性を提供し、守らないシステムはサプライズや変動をもたらします。

>>18
スマン3行100文字以内で例えてくれ

あーすまんより理解度高めたいから流星のロックマンで例えて

>>16
だった

こんなんわざわざ勉強しなくても気付く事じゃね
ユーティリティ関数作るなら特に

>>17
センス良いやつは気づきそう
依存度うんぬんなんて基本情報ですらでてくるし

ご指摘の通り、もし関数やシステムの目的が「毎回ランダムなイベントを起こすこと」であるならば、その目的自体が参照透過性の概念には適合しません。参照透過性は、同じ入力に対して常に同じ出力を返す性質を指します。ランダム性を目的とする場合、その性質は参照透過性とは相容れないものです。

例えば、「流星のロックマン」で特定のエリアに入るたびに異なる敵が出現するシステムを考えます。このシステムの目的が「プレイヤーに毎回異なる体験を提供すること」である場合、それは参照透過性を意図的に避ける設計です。ここでは、同じ「入力」（特定のエリアに入る行動）に対して、意図的に「異なる出力」（異なる敵の出現）をもたらすことが目的になっています。

このように、参照透過性の有無はそのシステムや関数の目的や設計に依存します。ランダム性や不確実性を取り入れたゲームプレイ体験を提供することが目的の場合、参照透過性は必ずしも求められる特性ではありません。

副作用しか勝たん

イキり初学者

あ？どこがデタラメじゃ
流星のロックマンは詳しくないのでわかりません

>>29
ΩはΩボスの事な？

ランダムエンカウントの中で低確率で遭遇する最上位ボス

分からない事ぐらい分かるようにしてから取りかかれよプログラマーなんだからさ