提供: Minecraft Modding Wiki
移動先: 案内検索
(こーしん。Server側は実際使わないしForgeのJavadocにもないけど解説なので書いとく。)
(微修正)
 
(他の1人の利用者による、間の1版が非表示)
1行目: 1行目:
 
==プロキシシステム==
 
==プロキシシステム==
プロキシシステムはデザインパターンにおけるproxyパターン(または, wrapperパターン)をシステムとして実装したものである。<br>
+
プロキシシステムはデザインパターンにおけるproxyパターン(またはwrapperパターン)をシステムとして実装したものである。<br>
SidedProxyにおいては、サーバー側とクライアント側とで異なる処理を共通のインタフェースで行うといった用途に用いる。<br>
+
SidedProxyは、サーバー側とクライアント側とで異なる処理を共通のインタフェースで行うといった用途に用いる。<br>
この機構によって、クライアント・サーバーに存在しないクラスを読み込んでクラッシュすると言った事態をかんたんに回避できる。
+
この機構によって、クライアント・サーバーに存在しないクラスを読み込んでクラッシュすると言った事態を簡単に回避できる。
  
 
===@SidedProxyアノテーション===
 
===@SidedProxyアノテーション===
37行目: 37行目:
 
保持するフィールドを@Modの付与されたクラスに置かない場合は、modidの記述も必須である。
 
保持するフィールドを@Modの付与されたクラスに置かない場合は、modidの記述も必須である。
  
==プロキシシステムは必ず必要かどうか==
+
== 参考 ==
プロキシシステムは'''必ずしも必要ではない'''。ただし、利用しない場合はSideの判定を挟む箇所が多く出てくるため、よほどの小規模ModかSMP対応を投げ打つのでない限り利用すべきである。
+
[http://mcforge.readthedocs.io/en/latest/concepts/sides/ ForgeDoc]

2018年1月15日 (月) 22:12時点における最新版

プロキシシステム[編集]

プロキシシステムはデザインパターンにおける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の記述も必須である。

参考[編集]

ForgeDoc