バルト海からインド洋へ

ストーリーは、コトリン島からジャワ島への私の旅の始まりについてです。



それはすべて、私が働く名誉のある組織のソフトウェアの監査が、あらゆるニーズに対応するさまざまなソフトウェアの可用性を示したという事実から始まりました。便利でした。 はい、誰も交換可能性をキャンセルしませんでした。



私の共有は、メ​​インソフトウェアをテストするためのデスクトップアプリケーションでした。 有望なKotlin言語で書かれています(当時はバージョン1.1が利用可能でした)が、統一は統一です。 この点で、仕事中に出会ったいくつかの瞬間と、Kotlinが初めて彼と仕事をしてからの印象を共有したいと思います。 この言語には多くの情報があり、Javaとのさまざまな比較があることは注目に値します。私の印象を共有したいだけです。



KotlinはJavaと仲が良いという事実から始める価値があります。この言語の作成者が何を志向していたかを見ることができ、JVMバイトコードへのコンパイルの存在も喜ばれます。 これにより、さまざまなJavaフレームワークとライブラリを使用できます。また、必要に応じて、1つのプロジェクトでこれら2つの言語をほぼシームレスにクロスできます。Kotlinクラスのコンパイルから開始するだけです。 プロジェクトではTornadoFXとExposedを使用しました。最初のプロジェクトはJavaFXの類似物であり、2番目はデータベースフレームワークです。



最初のセンセーションは、はい、プロファイルでのみ同じJavaでしたが、多くの構文糖を使用して、コードをより速く、よりコンパクトに記述できるようにしましたが、場所によってはより複雑になりました。



コードを初めて見たとき、「?」の豊富さに驚かされます。ゲッターとセッター、定数および可変変数valとvarの不在、自動型推論またはそれらの存在、もちろん、初期化が後まで延期される場合。 したがって、コードを分析すると、同僚がどのようなオブジェクトを念頭に置いていたのか疑問に思うことがよくあります。 int、booleanなどのプリミティブデータ型は、幼年期の「;」および「new」と同様に、言語では観察されません。



そもそも、この言語はnullセーフと見なされ、その結果、次のような構造になります。



Stand?.channell?.stream?.act()
      
      





「質問の神にもっと質問を!」と叫びたい。

「?」は最初はわずかに当惑します。オブジェクトのすべてのプロパティをnullでチェックする必要があるため、nullセキュリティが最前線にあることは明らかです。しかし、チェックせずにメソッドを呼び出す機能をnullのままにして、 ?「To」!!」。

例として、前の式は次のようになります



  Stand!!.channell!!.stream!!.act()
      
      





コンパイラはこの式をチェックしません。 共同プロジェクトがJavaでコンパイルされているかどうかはチェックしません。 問題は、それでは何が利点なのでしょうか?!



言語にはチェック済みの例外はなく、ファイルの読み取り時にIOExceptionは表示されません。 あなたを判断するのは悪いことですか、それとも良いことですか。



次に、Kotlinコードの例とJavaの同様の例を共有して、すべてがコンパクトに進む方法を示します。

コトリン Java
 private fun checkConnections(silently: Boolean = false): Boolean { var isNotFailed = true mqToClearTable.items.filter { isMqValid(it) }.forEach { mq -> if (mq.queue.isNotEmpty()) { isNotFailed = isNotFailed && checkMqConnection(MQContainer(mq.host, mq.port.toInt(), mq.channel, mq.queue, mq.manager), silently) } } return isNotFailed }
      
      



 private Boolean checkConnections(Boolean tempSilently) { boolean silently = ObjectUtils.defaultIfNull(tempSilently, false); boolean isNotFailed = true; List<QueueToClearObservable> filteredQueue = mqToClearTable.getItems().stream().filter(this::isMqValid).collect(toList()); for (QueueToClearObservable mq : filteredQueue) { if (StringUtils.isNotEmpty(mq.getQueue())) { isNotFailed = isNotFailed && checkMqConnection(new MQContainer(mq.getHost(), mq.getPort(), mq.getChannel(), mq.getQueue(), mq.getManager()), silently); } } return isNotFailed; }
      
      



 private fun armsTable() = armsTable.apply { columnResizePolicy = TableView.CONSTRAINED_RESIZE_POLICY items = currentStand?.arms?.observable() column("", ARM::hostProperty).useTextField(DefaultStringConverter())}
      
      



 private void armsTable() { armsTable.setColumnResizePolicy(TableView.CONSTRAINED_RESIZE_POLICY); if (currentStand != null) { if (CollectionUtils.isNotEmpty(currentStand.getArms())) { List<ARM> items = FXCollections.observableList(currentStand.getArms()); armsTable.getItems().addAll(arms); } } TableColumn<ARM, String> hostPropertyColumn = new TableColumn<>(""); hostPropertyColumn.setCellValueFactory(cell -> cell.getValue().hostPropertyProperty()); hostPropertyColumn.setCellFactory(TextFieldTableCell.forTableColumn());
      
      





Kotlinのコールシグネチャにデフォルト値が存在することは喜ばしいことです。Javaでは、そのようなことをOptionalクラスまたはメソッドのリロードによって解決する必要があります。

はい、Kotlinの機能スタイルは現時点でより適切に開発されているため、クラスオブジェクトの初期化時に必要なプロパティを追加できます。 例えば



  factory = new MQQueueConnectionFactory().applay { channel = mq.channel targetClientMatching = true hostname = mq.host.activ(); }
      
      





ただし、Javaでは、これらのプロパティの追加を転送したり、初期化後に追加のメソッドを使用したりできるいくつかのデザイナーを編成する必要があります。



しかし、私の意見では、物議を醸すものがあります:





Kotlinの機能部分についてもう少し。 同様の関数の存在は、アプリケーションの異なるニュアンスでも実行、実行、適用されます。たとえば、itキーワード(単一のパラメーターの暗黙的な名前)を使用して、同じ構造内で複数のそのような関数を使用すると不協和音が発生します:



 testInfo.also { it.endDateProperty.onChange { it?.let { update(Tests.endDate, it) } } }
      
      





特にコードが大きく、関数がネストされている場合、コードの正確な参照を把握するために、コードの解析に必要以上の時間を費やす必要があります。



Kotlinのデザイナーについてのコメント。 それだけでなく、メソッドの場合と同様に、コンストラクターでフィールドのデフォルト値を設定でき、Lonerパターンは、他のものと同様に言語レベルで実装され、Javaとは異なり、データクラスはペンで何度も何度も書き込みますそして数回。 しかし、私の意見では、後者のほうが継承の実装がより適切に構成されています。Kotlinとは異なり、すべてのクラスは最初は開いており、継承する場合は簡単に再定義できます。 Kotlinでは、クラスまたはメソッドをさらに再定義するには、オープンマークが必要です。 また、閉じたクラスはプロキシできません。 言語での静的プロパティとメソッドの実装も存在せず、代わりに、コンパニオンオブジェクトを介した実装が提案されています。



  class ExceptionHandler : Thread.UncaughtExceptionHandler { companion object { fun foo{ ….} val interval = 100 } }
      
      





結論として、Kotlinは一般に良い印象を与えたことに注目したい。 これにより、よりシンプルでコンパクトなコードを記述できます。これは、GUIで作業する場合に特に当てはまりますが、産業開発ではまだわかりません。



All Articles