Kotlin [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/02/27(土) 01:46:01.68

JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

**デフォルトの名無しさん** · 2017/09/14(木) 17:43:11.05

安価間違えた、スマン

**デフォルトの名無しさん** · 2017/09/14(木) 17:48:14.60

動的言語のメリットってないだろ
型推論あるし

**デフォルトの名無しさん** · 2017/09/15(金) 10:44:48.01

>>604
javaの知識が前提

**デフォルトの名無しさん** · 2017/09/15(金) 11:20:35.63

>>604
言語自体のデメリットではないかもしれないが、
IDEの選択肢がない・開発補助ツールなどが未発達。

**デフォルトの名無しさん** · 2017/09/15(金) 18:58:50.23

>>610
コレはでかい。正直この知識を簡単に獲得する方法あるの？
kotlinからjavaの世界に入る方法を知りたい。

**デフォルトの名無しさん** · 2017/09/15(金) 21:05:06.50

そういやJavaの知識なしの人向けの入門書はまだないのかな？
なくても流行ればその内出そうだが。

**デフォルトの名無しさん** · 2017/09/15(金) 21:11:43.49

groovyよりは期待できるの？

**デフォルトの名無しさん** · 2017/09/16(土) 07:58:31.08

Javaって一番メジャー言語だから
情報が溢れてると思うんだが……
マイナー言語の苦しさに比べたらはるかに楽

**デフォルトの名無しさん** · 2017/09/16(土) 08:06:32.31

Javaを既に知っている者ならそうだろうな
Javaを知らずにKotlinやると、KotlinとJavaを並行して学習することになるから面倒だって話だ

**デフォルトの名無しさん** · 2017/09/16(土) 09:13:19.33

kotlinはJavaのスクリプト言語みたいな立ち位置だからな（コンパイル要るけど）
Java入門が巷に溢れているがゆえにKotlin+Javaの書籍は出しにくいかもしれん
それにしたとしても時間が解決していくではあろう

**デフォルトの名無しさん** · 2017/09/16(土) 09:53:29.49

Kotlinで開発してたとして、具体的にどういうときにJavaの知識が必要になるんだろう？
JVMに関してなら「言語+実行環境」だから他の言語と変わりないし
Javadocのシグネチャくらいで困ることは無さそうだし

多分、解説書く側も「何が分からないのか分からない」状態になってるんじゃないかな

**デフォルトの名無しさん** · 2017/09/16(土) 10:25:55.20

>>607
JSもJVMもランタイムがいると思うけど、このランタイムってApache2.0ライセンスなのかな?
だとしたら、同梱した場合、表示が必要になるんだっけ?

**デフォルトの名無しさん** · 2017/09/16(土) 10:55:31.44

>>618
こういうことをJVM上でやりたいなぁって思った時に、Javaでの実装手法を調べてKotlinで読み換えるわけだろ？
その時にまずJavaの全般的な知識(文法, ライブラリ)を浅く広く手に入れる所から始まる
次に、JavaからKotlinに読み換えるために文法/ライブラリの在り様を深く理解してから適切なKotlinコードに書き下す
JavaとKotlinの生半可な知識だけでJavaコードを参考にKotlinコード書くと、汚いKotlinコードになるよね

なので、絶賛Javaを再勉強中・・・Java1.5の頃の知識で止まってるからイマドキのJavaが分からない
java.langとかNIO2とかを使ったコードをKotlinでいきなり書こうとしたら何か違う感が酷くてやめちまったよ

**デフォルトの名無しさん** · 2017/09/16(土) 11:21:42.95

他の言語を知ってれば要はリファレンスとjava特有の注意事項があればいいと思うの。
文字列組み立てにはStringBuilder使えみたいなの。

そういうの無い？

**デフォルトの名無しさん** · 2017/09/16(土) 11:42:24.85

android studioってkotlinのプロジェクトにjavaのコードを貼り付けたらkotlinに変換してくれる神機能があるから
泥開発する時にネットで拾ったjavaのコードをペタペタコピペプログラミングするだけでも勉強になる

javaもkotlinも知識皆無の状態でkotlinで泥アプリ開発に取り組んだら見様見真似で簡単なアプリ作れた
ある程度コピペしてたらjavaのこの書き方はkotlinではこう書きそうっていうのがなんとなく察せてくるからandroid studioの補完を頼りに写経したりする

javaも知らないけど新しく言語の知識学ぶなんて面倒くさいからヤダ！知識皆無だけどすぐ何か作りたい！hello wordとか練習問題みたいなの書いても面白くないからモチベーションわかない！すぐ作りたい物作りたい！って場合は
ネットのサンプルと強力なIDEの支援を頼りにコピペ写経するのが効率よさそう
(外国語ができなくても海外でしばらく生活したら知識的に習わなくてもだんだん喋れるようになる理論)

**デフォルトの名無しさん** · 2017/09/16(土) 12:49:19.86

>>620
Kotlinで書かれたサンプルコードが少ないってこと？
それについては自動変換で対応するか、Kotlinが広まってサンプルが増えるのを待つしか無いか

**デフォルトの名無しさん** · 2017/09/16(土) 12:50:15.30

それと思ったのはKotlin・・というよりプログラム初学者は
言語仕様、ライブラリ、プラットフォームの知識がごちゃ混ぜになってるのかも

「Java言語仕様の知識前提」の場合はデメリットだけど、後者２つはそうではないんだよね
ちゃんと切り分けて教える必要があるのかもしれない

**デフォルトの名無しさん** · 2017/09/16(土) 15:17:58.69

>>620
一々Javaで考えてからKotlinに読み替えるのではなく最初からKotlinで考えればいいのでは？それは出来ないの？

**デフォルトの名無しさん** · 2017/09/16(土) 15:51:26.67

前途洋々たる人にJavaを教えたいかというとそうでもない、しかし現状kotlinにはjavaの知識がいくらか必要というジレンマ

**デフォルトの名無しさん** · 2017/09/16(土) 17:15:31.02

自動変換はマジで神機能だな

**デフォルトの名無しさん** · 2017/09/17(日) 09:11:08.18

kotlin変換はスニペット単位で変換挿入できれば初学者サポートとして文句ないんだけど
まあ高望みしても仕方ないなｗ

**デフォルトの名無しさん** · 2017/09/17(日) 09:16:06.15

Kotlinを使い始めるのにJavaから始めないといけないのも高望みだから仕方ない
JVMとJava LibraryありきなんだからJavaを知らないで何が始まろうかと理解している

**デフォルトの名無しさん** · 2017/09/17(日) 10:57:51.48

>>628
騙されたと思ってandroid studioでkotlinを開いてそこにjavaのスニペットをそのまま普通に貼り付けてみ

**デフォルトの名無しさん** · 2017/09/17(日) 12:20:57.80

>>628
できるぞ

**デフォルトの名無しさん** · 2017/09/17(日) 20:10:21.20

kotlinというかIntelliJはなにかにつけてUnresolved Referenceで発狂して真っ赤になるのを潰していかんといかん
全部自前のkotlinファイルとパッケージだけで構成すれば絶対に起こらん事象だが、そんなのは稀だ

**デフォルトの名無しさん** · 2017/09/17(日) 20:33:40.63

>>632
あれはライブラリ作者とプラグイン作者が7割くらい悪い
提供されるテンプレートでjavaパッケージのimportの不足（しかもbuild.gradleに依存関係未記述）とか勘弁して欲しい
ていうかこれ作者のとこではどうやって動いてたんだ…

**デフォルトの名無しさん** · 2017/09/17(日) 22:18:35.53

>>633
TornadoFXでえらい苦労した記憶がある
無論使うのやめた
Androidのほうがまだきちんと動くｗ

**デフォルトの名無しさん** · 2017/09/18(月) 21:46:47.81

昔のEclipse環境下開発みたいなトラブル起こしてんなw
libs/*.jar と .classpath をコミットしてなくて、ライブラリ実装者とライブラリ利用者で環境が合致しないとかよくあった

build.gradleで依存管理してないなら、libs/*.jar と .idea/ で管理してるんじゃないのかね
ビルドできねーよってIssue発行して、build.gradleで依存管理するように直してもらおうぜ(Kotlinと全く関係ない話題

**デフォルトの名無しさん** · 2017/09/19(火) 01:56:04.30

TornadoFXは面白そうだなと思って手を付けた瞬間
・TornadoFXのDSL記法では思った通りに動作しないがJavaFXでは動く
・JavaFXではうまく動かないがswt直呼びでは動く
・JavaのGUIアプリケーションではあまり得意ではない
の3者が混然一体となってGUI初心者に襲いかかってきた荒野の印象しかない
GUIやるのさぼってきたツケもあるしkotlin関係ないけどな

**デフォルトの名無しさん** · 2017/09/19(火) 02:57:40.00

FXには手を出すなって死んだばっちゃが言ってた

**デフォルトの名無しさん** · 2017/09/19(火) 03:13:01.72

HTTPプロトコル受けるようにして、GUIはHTMLとjavascriptでブラウザ任せでやる方がいいんでね？

**デフォルトの名無しさん** · 2017/09/19(火) 11:33:34.11

とるねーどFXのDSL記法は初心者の「こうかな？これなら動くかな？」という学習の試行錯誤を念入りに潰してバグに変えるプロ
設定記述手法以外のDSLなんてまあたいていそんなもんだが
どうしてもPCでGUI欲しくてなにもわからない最初ならJavaFXにするのがよいよ

**デフォルトの名無しさん** · 2017/09/19(火) 23:03:32.67

>>630
IntelliJではできんことのほうが多いね
完動するJavaのクラスのファイルとかそういうでっかいのか意味のあるわかりやすい小さいやつとかじゃないとまず無理
それでも便利だろうという指摘はもっともだが

**デフォルトの名無しさん** · 2017/09/20(水) 00:55:44.49

tornadoFXで丸1日悩んでいたことがJavaFXでは1時間でできたなんていう笑い話が…
別にこれに限った話じゃないけど、今から何か始めたいって人は「kotlin対応新鋭フレームワーク！」みたいな宣伝には騙されずにJava製のでいいからメジャーなやつを選ぼうね
たいていkotlinでの書き方みたいなのが公開されてるからそれで充分さ

**デフォルトの名無しさん** · 2017/09/20(水) 12:49:45.18

画面はWebView(JavaScript連携)でいいよ

**デフォルトの名無しさん** · 2017/09/21(木) 00:08:50.00

そこそこの長さの文字列をわかりよく文字列のリストにする方法ってないですか
"ABCDE".toList()だとCharのリストになってmapとか繋げて変換がいります
"ABCDE".split("")だとなんか7つのリストになります
文字境界の正規表現を指定すればいいような気もしますが探せませんでした

**デフォルトの名無しさん** · 2017/09/21(木) 03:27:44.93

>>643
"ABCDE".split("(?=.)") ではどうか?

**デフォルトの名無しさん** · 2017/09/21(木) 11:28:55.55

>>> "ABCDE".split("")
[, A, B, C, D, E, ]
>>> "ABCDE".split("").size
7
>>> "ABCDE".split(Regex("(?=.)"))
[A, B, C, D, E]
おお、ありがとうです
しかしありそうでないのねStringで分けるやつ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2017/09/21(木) 13:35:52.21

>>645
"ABCDE".map { it.toString() }
これおすすめ

**デフォルトの名無しさん** · 2017/09/21(木) 21:11:04.25

だからそれだとStringをCharにしてからStringにするという手間がかかっ

for(int var6 = 0; var6 < var5.length(); ++var6) {
char item$iv$iv = var5.charAt(var6);
String var13 = String.valueOf(item$iv$iv);
destination$iv$iv.add(var13);
}

…ってなかった。最近の言語のコレクションのmapとかあのへんのメソッドは空気を読んでて困る（えらい）。じゃあこれにします

**デフォルトの名無しさん** · 2017/09/23(土) 03:05:43.18

Kotlinは配列というかリストになんか入れるとエラーで二度と引き出せなくなるのが嫌
何か不都合があって引き出せないのなら最初から弾いてくれ

**デフォルトの名無しさん** · 2017/09/23(土) 06:21:39.07

意味がわからん

**デフォルトの名無しさん** · 2017/09/23(土) 09:46:44.92

つmutableListOf

**デフォルトの名無しさん** · 2017/09/23(土) 09:47:52.09

いや意味がわからんな

**デフォルトの名無しさん** · 2017/09/23(土) 10:14:30.20

あのへんは型とか継承とかの理解きちんとしてないとちょっと複雑なの入れたときものっそいエラーになるよ
適当に書いて適当に使ってると動くと見せかけていざというとき詰まる箇所ベスト3に入ると思う

**デフォルトの名無しさん** · 2017/09/23(土) 10:59:53.99

具体例があると話も広がりそうだけどイメージがわかない

**デフォルトの名無しさん** · 2017/09/23(土) 13:45:04.86

コレクションって色々種類があって、
問題によって適切なクラスを選ぶべきとか言っていたくせに
mutableListはmutableListしか種類ないし、それで別に問題がないってどういうことだよ
フィールドもprivateにしてsetter, getterからアクセスしろとか言っていたくせに
プロパティアクセスは実質フィールドをpublicにしているのと変わりないじゃねえか
その他、継承は良いことだからたくさん使って活用していこうとか言っていたくせに
openをつけないと継承できなくして、実質継承は推奨しないみたいになってるのなんなん
嘘ばっかり言いやがって

**デフォルトの名無しさん** · 2017/09/23(土) 14:17:09.35

>>652
「のっそい」って何処の方言？沢山って意味？

**デフォルトの名無しさん** · 2017/09/23(土) 14:32:54.88

>>654
いろいろ勘違いしててどこから突っ込めばいいのやら

**デフォルトの名無しさん** · 2017/09/23(土) 15:29:22.72

プロパティアクセスは、publicなフィールドへのアクセスと違って、
setを制限してgetだけにできるし、
setするときの値チェックなんかもできるし、
privateフィールドをsetter/getterでアクセスする利点はそのままに、
使うときの表記をシンプルにしてくれる

**デフォルトの名無しさん** · 2017/09/23(土) 15:29:38.76

継承するよりコンポジションしてアクセスを転送する方がいいっていうのは
もうオブジェクト指向では定説

**デフォルトの名無しさん** · 2017/09/23(土) 15:37:14.57

ミュータブルなコレクションに厳密な静的型チェックを適用としようとするのはいろいろ限界がある
Javaでは厳密な静的型チェックを放棄して使いやすさを優先してる

**デフォルトの名無しさん** · 2017/09/23(土) 15:40:52.48

今更だけど、StringをStringリスト(配列)にするってクッソ馬鹿っぽいな
Stringをnewするのも重いし、確保したメモリをGCで回収するのも重くなる

「StringをCharにしてからStringにするという手間」とか言うならChar配列で扱えというね
String配列扱うくらいに性能を考えないなら、当初の通りに#toList #map使っててもおkだろ

**デフォルトの名無しさん** · 2017/09/23(土) 16:00:34.34

>>654
>mutableListはmutableListしか種類ない
意味がわからない
大枠でList, Set, MapなどがあってLinkedHashMapとSortedMapは順序制御が違うし
ArrayListとLinkedListは追加削除のパターンによって計算量オーダーが異なる

>setter, getterからアクセスしろとか言っていたくせに
構文が理由ではない
>フィールドをpublicにしているのと変わりない
構文が変わりないだけ

**デフォルトの名無しさん** · 2017/09/23(土) 16:22:03.12

>>660
Stringがイミュータブルなら、
Stringの一部分を取り出して新しいStringを作るのはとても軽い処理でできる
その新しStringを作る仕組みで配列を作れば、それも軽い

**デフォルトの名無しさん** · 2017/09/23(土) 16:43:59.09

COW信者乙

さておき、入れ物のStringインスタンスをnewするのはやめたいよな
中身をコピーするかどうか以前にJVM上のインスタンスの確保が重たいんだよ
そして、GCで回収して回る対象個数が増えて重たくなるのは中身のコピー有無は関係ないんだよ

**デフォルトの名無しさん** · 2017/09/23(土) 17:42:00.77

かといって日頃パフォーマンスに影響するような膨大な処理をさせてないので気にならない

**デフォルトの名無しさん** · 2017/09/23(土) 20:38:20.82

Kotlinの気に入らないところ
http://anopara.net/2017/09/16/kotlin%E3%81%AE%E6%B0%97%E3%81%AB%E5%85%A5%E3%82%89%E3%81%AA%E3%81%84%E3%81%A8%E3%81%93%E3%82%8D/

**デフォルトの名無しさん** · 2017/09/23(土) 21:43:26.21

気に入らないところが、JavaやScalaを使い込んだ人視点で、このスレレベルからみるとむしろズレてるね

**デフォルトの名無しさん** · 2017/09/23(土) 22:33:09.90

>>662
そういったイミュータブルな文字列を表現するデータ構造として Rope がある
・Rope (data structure) - Wikipedia
　https://en.wikipedia.org/wiki/Rope_(data_structure)
・ロープ: 理論と実践 - IBM developerWorks / Java technology
　https://www.ibm.com/developerworks/jp/java/library/j-ropes/
・最終報告 - Ropeを用いたRuby処理系の高速化に関する報告
　http://www.spinute.org/ruby/gsoc2016/japanese.html

特に「Stringの一部分を取り出して新しいStringを作る」という
substring 操作に関しては、上記の Wikipedia のページからリンクされている
原論文(英語)の中で疑似コードを使って丁寧に解説されている

で、肝心の Kotlin 実装は知らない（汗

**デフォルトの名無しさん** · 2017/09/23(土) 22:39:08.56

>>641
tornadoFXのマニュアル今読んでいるところだけど、tornadoFXだめなのか...
>>642
前やってみたけど、Javascriptとつなぎ合わせるところが、ちょっと面倒だった。
型安全でもないし...

**デフォルトの名無しさん** · 2017/09/24(日) 02:01:15.02

>>666
文法が気に入らないって言ってるだけでJavaやScalaを使い込んでるようにも見えんがな
JVMの仕様上、JavaやScalaの方が最適化されてるからKotlinが気に入らないって話かと思って読んだらもっと浅い話だった

Kotlinの文法が良いってこのスレは賞賛してるから論点はこのスレと合致してる
ただ、Kotlinの文法がダメって記事と、Kotlinの文法がイイってスレとで感想が真逆なだけだ

**デフォルトの名無しさん** · 2017/09/24(日) 02:17:41.07

>>655
ものすごい→ものっそい

**デフォルトの名無しさん** · 2017/09/24(日) 09:32:49.28

tornadoFXはDSLのダメなとこ出てるねえってだけだから、それ気にならないならいいんじゃないかな
足りない情報は君が発信するんだ

**デフォルトの名無しさん** · 2017/09/24(日) 10:29:34.48

Kotlin は、Groovy, Scala, Ruby の影響を受けている

Ruby を関数型にした、Elixir を意識している。
関数型では、デフォルトが、immutable

**デフォルトの名無しさん** · 2017/09/24(日) 14:15:58.51

ねえねえおにいちゃん
ミュータブルリストの先頭から要素を削除して詰める（戻り値不問）って行為をいちばんうまくできる書き方ってなあに

**デフォルトの名無しさん** · 2017/09/24(日) 14:31:53.81

>>673
removeAt() じゃないの?

**デフォルトの名無しさん** · 2017/09/24(日) 14:32:52.09

コマンドラインでこんな風にできたが

>>> val a = mutableListOf(1, 2, 3)
>>> a
[1, 2, 3]
>>> a.removeAt(0)
1
>>> a
[2, 3]

**デフォルトの名無しさん** · 2017/09/25(月) 02:59:33.77

kotolinってc#で言うpartial classみたいなことできないのかな？
実装を分けたい

**デフォルトの名無しさん** · 2017/09/26(火) 20:47:43.28

fun main(args : Array<String>){
test(){
println("test!")
}
}

fun <T> test(body: () -> T ) : T {
println("START")
try{
return body
}
finally{
println("END")
}
}
これで
(returnの行): error: type mismatch: inferred type is () -> T but T was expected
ってエラー出るのなんでですか
まだどっかに<T>って書かないとダメですか
STARTって表示してtest!って表示してENDって表示するようにしたいんですが

**デフォルトの名無しさん** · 2017/09/26(火) 20:59:27.36

bodyは () -> T じゃん？つまり body() がTじゃん？
返り値いらないならUnit型でも

**デフォルトの名無しさん** · 2017/09/26(火) 21:19:23.18

println()って何か返すんだっけ？

**デフォルトの名無しさん** · 2017/09/26(火) 21:25:08.76

コピペ参考でジェネリクス書いちゃう気持ちはわかる
ネットとかにある高階関数なんかのサンプルはたいていなんか小難しいパターンやってるからな
ちょこちょこ検索してみたけどシンプルなのはなかなかないようだ
というわけで顧客が必要だったもの：

fun main(args : Array<String>){
test(){
println("test!")
}
}

fun test(body: () -> Unit){
println("START")
try{
return body()
}
finally{
println("END")
}
}

超わかりやすい

**デフォルトの名無しさん** · 2017/09/26(火) 22:18:45.79

>>680
それ return 書かなくても同じだよね？

**デフォルトの名無しさん** · 2017/09/27(水) 00:00:41.38

簡素化のためにUnitを返す型をクロージャーにしてるけど任意の型を戻せるようにしたいんじゃないの
>>680は顧客が本当に必要だったものとは別のものが出来上がってる事例な気がする

**デフォルトの名無しさん** · 2017/09/27(水) 02:23:01.67

>>677
return body ではなく return body() では?

**デフォルトの名無しさん** · 2017/09/28(木) 00:26:24.46

前から思ってたんだけど、Kotlinって
val hogeIsEmpty = hogeが空かどうかのわりと長い1行
if (hogeIsEmpty) {
// then
}
みたいな読み下す優先の変数の名前とか分離定義って推奨されてる？
Javaでやらないようなことはやらんほうがいい？条件カッコに改行ありで詰め込むべき？

**デフォルトの名無しさん** · 2017/09/28(木) 00:37:08.13

そういうのはRubyでやれや！って煽られて終わりな気も致しますよ

**デフォルトの名無しさん** · 2017/09/28(木) 00:42:19.80

くっ…

**デフォルトの名無しさん** · 2017/09/28(木) 01:13:09.11

えーそれ言語関係なくない？
hogeIsEmptyな関数に抽出するのは
リファクタリングの基本だしJavaでもやるだろ

**デフォルトの名無しさん** · 2017/09/28(木) 18:33:31.64

むしろJavaだとboolean isHogeEmpty()ってメソッドを作るケースだから
Javaの文法が古臭いと仕切り直したKotlinではメソッドを作らないのが正当なんじゃないの

**デフォルトの名無しさん** · 2017/09/28(木) 20:41:39.85

そうなのか？

うーん。なんだったらgetだけのプロパティ作ってその中でやるという手もあるが。

**デフォルトの名無しさん** · 2017/09/28(木) 21:04:34.88

>>684
変数での分離で良い

一見で意味付けが分かり辛いものは変数名で説明していい
局所的なものであれば無意味にメソッド化する必要も無い
その条件式が2度出てきたときに再考する

**デフォルトの名無しさん** · 2017/09/29(金) 08:30:52.93

あー、rubyは変数いきなり定義だし命名規則もsnake_caseで緩いし変数もメソッドも呼び出し方同じにできるし
真偽には?つけてよいという風潮があるからこういうの得意だね
Java/Kotlinは読み下しさせようとするとわりとデコボコするけどそのかわり静的コンパイルだから実行パフォーマンスへの影響が少ない
（だから「ちょっと動かして見やすく名前つけただけで動作的中身的には一緒だから安心して」という説得に向いてるのはKotlinのほうではある）
Kotlinにはスコープ関数とかletとかitとか（あとはbeがあれば完璧だ）あるのでそのへん駆使してもらうしか

**デフォルトの名無しさん** · 2017/09/29(金) 09:00:05.56

一般的には説明変数を追加するのに比べると
メソッド抽出のほうが可読性も保守性も高い
デメリットもあるから状況次第で選択すればいい
いずれにしても言語に依存した話ではないよ

**デフォルトの名無しさん** · 2017/10/01(日) 12:07:39.75

言語に関係ない話だと思うんだけどごめん
初心者がゲーム作ってて、たとえばRPGのアイテムみたいなのをクラスで実装したいって考えたとき、
たとえば食べ物アイテムを100個くらい作ろうと思ったら、名前とか重さとか売価とかレシピとかを持ってるクラスが（下手するとktファイルも）それだけで100個あることになるよね
何かアイテムのデータを確かめたいとか書き換えたいとか思ったら100個の中から探さないといけなくなる気がして、とてもしんどいんだけど、なにか便利な管理方法ってあるものなのかしら

**デフォルトの名無しさん** · 2017/10/01(日) 12:35:40.87

データベース…

**デフォルトの名無しさん** · 2017/10/01(日) 13:26:09.11

でもデータベースはメソッド生えないにゃん…
現状の超でっかいMapオブジェクト
{"yakusou" -> {"name":"薬草", "price":10, "weight":2, "action":["EAT","DROP","HEAL","GRIND"]...}}
の該当アイテム読んでactionで分岐するメソッド構成とあんまし変わらない気がするにゃん…

ビルド時にCSVファイルとかからクラスファイルを生成してもらえばいいのではと思ったけど
書いてるときにアイテムのクラスやメソッドが参照できないとIDEが補完警告出すことに気づいてぐにょーんってなってる
たぶんゲーム特有のなんとかかんとかなんだろうと思うのでなんとかする

**デフォルトの名無しさん** · 2017/10/01(日) 13:29:23.37

つまり、どういうこと？

**デフォルトの名無しさん** · 2017/10/01(日) 13:45:30.71

>>695
アイテムごとに個別のメソッドが必要だと考えるのは抽象化が不足してるから
食べ物アイテム100個作っても食べ物クラス1個で済む場合もあるでしょ

**デフォルトの名無しさん** · 2017/10/01(日) 15:01:31.15

むしろそれぞれクラス化するのはアクションの方で
アイテムなんて1クラスで十分じゃね

**デフォルトの名無しさん** · 2017/10/01(日) 15:03:06.78

ゲ制でやれ

**デフォルトの名無しさん** · 2017/10/01(日) 15:06:13.80

>>695
> {"yakusou" -> {"name":"薬草", "price":10, "weight":2, "action":["EAT","DROP","HEAL","GRIND"]...}}
> の該当アイテム読んでactionで分岐するメソッド構成とあんまし変わらない気がするにゃん…

それの何がいけないの？

**デフォルトの名無しさん** · 2017/10/01(日) 15:11:03.14

色々用途や効果がある個々のアイテムインスタンスが対応するメソッドを持ってて自分に関することは全て知っていて
たとえば砕いたら何になるのかとか、字面に置いたらどのテクスチャになるのかとか、を問い合わせる構造にしたいのはわかる気がする
でもそれ理想っぽいけどお察しの通りデータ増えると破綻するんすよ…

**デフォルトの名無しさん** · 2017/10/01(日) 15:24:19.98

よくわかんないけどデータベース(SQL)から(id,)name,price,weight,actionの(データ)クラスに入れてMapに突っ込むのは普通じゃね
アクションは共通の動作だけハンドラーに直接書いて、固有の動作は個々のアイテムごとにスクリプトファイル作ってそんなかにアクションごとのメソッド書いて、それをハンドラーから実行させる

**デフォルトの名無しさん** · 2017/10/01(日) 15:27:41.13

あ
完全にサーバー<=>クライアント型のゲームを想定してました忘れてください

**デフォルトの名無しさん** · 2017/10/01(日) 15:35:03.09

よっぽどドラクエ2みたいなツクールサンプル的な単一用途アイテムでもない限り
「薬草という多用途アイテムを表現するのに薬草クラスのインスタンスを作って保持する」というのは悪手
このへんは個別に考えてもらわなければならないのでまあ結論としては>>699
個々人が下手に作って再発明して失敗して適応適用していかなきゃならんなんてなんて非効率なんだとは思うのだが今のところ光明はない
ぶっちゃけ初心者にゲーム作らせるのこのへんの問題もあってあんま好きではないのだ。ユーティリティアプリが無難

**デフォルトの名無しさん** · 2017/10/01(日) 16:36:39.58

薬草を使った時の処理
薬草を燃やした時の処理
薬草を売った時の処理
…

薬草クラスにまとめようがまとめまいが
いずれはどこかに書かなければならない
だったら最初から薬草クラスに入れとけって話

**デフォルトの名無しさん** · 2017/10/01(日) 17:36:02.79

じゃあ毒消し草にも同じ処理コピペすんの？

**デフォルトの名無しさん** · 2017/10/01(日) 23:16:31.50

アルゴリズムと計算量を知らないのか

千個の中から、1つを見つける際、全(線形)探索なら千回、
2分探索なら、2^10 = 1,024 だから、10回で見つけられる

2分探索なら、データ数が千個でも、探索回数は、1/100 になる

2千個になっても、全(線形)探索なら2千回、
2分探索なら、11回で見つけられる。
探索回数は、1/200 になる

データ数が倍になっても、探索回数は1回しか増えないが、
データを2分木で持っていないと、2分探索はできない