Shion のもくログ(旧: Shion の技術メモ)

使った技術のメモや、うまくいかなかった事とかを綴ります

PR

2022/05/28 ~ 2022/06/03 のもくもく日記

もくもく 前回までは

2022/05/21 ~ 2022/05/27 のもくもく日記 をご覧ください。

今回の目標

  • レシピの整備

途中経過

その1

ありがたいことに各社いろいろ整備してくれているので、まずはモバイルに絞ってみることに

その2

書籍 ソフトウェアアーキテクチャの基礎 を読み進め中。

意訳になってしまうけど、アーキテクトに必要なスキルの一つが“交渉術“ なの、ヘドバンのように激しく頷いてしまうくらい、わかりみが深い……

この一文、とても共感できる 😌

Ruby on Rails に専門家になったとしても、1、2年Ruby on Rails から離れていたら、その専門知識は失われてしまう。

……自分の都合で引用しているかもだけど、継続性を大事にして、少しずつ発展させたいなと思っているのです(願望)

この一文カッコいい 😆

アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ。

その3

そういえばKotlin で定義したinternal data class がJava から呼べてしまうの、それを防ごうとするとめっちゃややこいw

  1. data class をabstract class に変更(constructor 隠蔽不可のため)
  2. インスタンス生成メソッドをJvmName に無効文字列を混ぜて隠蔽
  3. 型は参照できるけど実質使えない
abstract class SomeData {
    internal abstract val prop1: String

    companion object {
        @JvmName("-newInstance")
        internal fun newInstance(): SomeData {
            return object : SomeData() {
                override val prop1 = "prop1 from SomeData"
            }
        }
    }
}
public class CallSample {

    public void call1() {
        // Abstract Class だからインスタンス化できない
        SomeData someData1 = new SomeData();

        // JvmName に無効化文字列があるから参照できない
        SomeData someData2 = SomeData.Companion.newInstance();
    }

    public void receive(SomeData data) {
        // この場合は……どう防ごうかね……
        // プロパティにしなければ良いと言えば良いのだけど……
        String prop1 = data.getProp1$android_app_data_main();
    }
}

その4

書籍 良いコード/悪いコードで学ぶ設計入門 を読み進め中。

この一文良い 👍

同じようなロジック、似ているロジックであっても、概念が違えばDRY にすべきではないのです。

今回の進捗

※関連SNS
PR