提供: Minecraft Modding Wiki
移動先: 案内検索
(こーしん。Server側は実際使わないしForgeのJavadocにもないけど解説なので書いとく。)
1行目: 1行目:
{{前提MOD|reqmod="Minecraft Forge4.3x"}}
 
 
 
==プロキシシステム==
 
==プロキシシステム==
プロキシシステムはデザインパターンにおけるproxyパターン(または, wrapperパターン)をシステムとして実装したものである. 具体的には, 以下の一文で示される
+
プロキシシステムはデザインパターンにおけるproxyパターン(または, wrapperパターン)をシステムとして実装したものである。<br>
*サーバー側, クライアント側で異なる処理を, 共通のインタフェースで行う
+
SidedProxyにおいては、サーバー側とクライアント側とで異なる処理を共通のインタフェースで行うといった用途に用いる。<br>
 
+
この機構によって、クライアント・サーバーに存在しないクラスを読み込んでクラッシュすると言った事態をかんたんに回避できる。
基本的には'''クライアント側でのみ必要な処理'''を共通のインタフェースで行うが, サーバー側とクライアント側で異なる処理を共通のインタフェースで行いたい場合も利用する.
 
  
 
===@SidedProxyアノテーション===
 
===@SidedProxyアノテーション===
 +
この例ではClientProxyをclientパッケージ下、ServerProxyをserverパッケージ下においている。
 
<source lang = "java">
 
<source lang = "java">
@SidedProxy(clientSide = "パッケージ名.client.ClientProxy", serverSide = "パッケージ名.CommonProxy")
+
@SidedProxy(clientSide = "パッケージ名.client.ClientProxy", serverSide = "パッケージ名.server.ServerProxy")
 
public static CommonProxy proxy;
 
public static CommonProxy proxy;
 
</source>
 
</source>
28行目: 26行目:
 
</source>
 
</source>
  
@SidedProxyアノテーションは実行される側によって生成するインスタンスを変えるアノテーションである. clientSideがクライアント側, serverSideがサーバー側である. 余談だが, bukkitSideが存在し, 将来的にbukkitにまでコードの統一化が行われることが示唆されている.
+
*ServerProxy
 +
<source lang = "java">
 +
@SideOnly(Side.SERVER)
 +
public class ServerProxy extends CommonProxy
 +
{
 +
}
 +
</source>
 +
 
 +
@SidedProxyを付与したフィールドは起動時(具体的には各ModのFMLConstructionEvent前)に、対応したプロキシで初期化される。<br>
 +
保持するフィールドを@Modの付与されたクラスに置かない場合は、modidの記述も必須である。
  
 
==プロキシシステムは必ず必要かどうか==
 
==プロキシシステムは必ず必要かどうか==
プロキシシステムは'''必ずしも必要とは限らない'''. 例えば単なるブロックの追加でも, 既存のテクスチャの色違いであったり, 同じテクスチャで明るさを持っているだけ, などの場合はプロキシシステムをわざわざ利用する必要はない. 必要とされるのはあくまで'''サーバーとクライアントで異なる処理を行う'''場合である.
+
プロキシシステムは'''必ずしも必要ではない'''。ただし、利用しない場合はSideの判定を挟む箇所が多く出てくるため、よほどの小規模ModかSMP対応を投げ打つのでない限り利用すべきである。
 
 
==諸注意==
 
上記の例はクライアント側のみ, パッケージに階層clientを追加している. これはあくまで'''明示的に'''クライアントのみの処理はパッケージの階層を追加しているだけで, 実際はclientパッケージを作る必要性はない. ただし, チュートリアルで作成するModは'''明示的に階層を分けている'''ので注意すること.
 

2017年2月19日 (日) 18:27時点における版

プロキシシステム

プロキシシステムはデザインパターンにおけるproxyパターン(または, wrapperパターン)をシステムとして実装したものである。
SidedProxyにおいては、サーバー側とクライアント側とで異なる処理を共通のインタフェースで行うといった用途に用いる。
この機構によって、クライアント・サーバーに存在しないクラスを読み込んでクラッシュすると言った事態をかんたんに回避できる。

@SidedProxyアノテーション

この例ではClientProxyをclientパッケージ下、ServerProxyをserverパッケージ下においている。

@SidedProxy(clientSide = "パッケージ名.client.ClientProxy", serverSide = "パッケージ名.server.ServerProxy")
public static CommonProxy proxy;
  • CommonProxy
public class CommonProxy
{
}
  • ClientProxy
@SideOnly(Side.CLIENT)
public class ClientProxy extends CommonProxy
{
}
  • ServerProxy
@SideOnly(Side.SERVER)
public class ServerProxy extends CommonProxy
{
}

@SidedProxyを付与したフィールドは起動時(具体的には各ModのFMLConstructionEvent前)に、対応したプロキシで初期化される。
保持するフィールドを@Modの付与されたクラスに置かない場合は、modidの記述も必須である。

プロキシシステムは必ず必要かどうか

プロキシシステムは必ずしも必要ではない。ただし、利用しない場合はSideの判定を挟む箇所が多く出てくるため、よほどの小規模ModかSMP対応を投げ打つのでない限り利用すべきである。