Casual Developers Note

エンジニアやデザイナー向けの技術情報・英語学習情報・海外留学情報・海外旅行情報を提供中。世界を旅して人生を楽しもう。

  • ホーム
  • 技術 Tips & Tutorials
  • 技術塾
  • ライフハック
  • 海外留学
  • 英語学習
  • コラム
  • お問い合わせ
現在の場所:ホーム / アーカイブ技術塾

2018年6月15日 By KD コメントを書く

オブジェクト指向の基本原則「SOLID Principles」からプログラミングの基本を学ぶ

オブジェクト指向の基本原則「SOLID Principles」からプログラミングの基本を学ぶ

初心者が何の指針も無しにプログラミングすることは、目隠しをした状態で吊橋を渡るようなものです。今回はそんな事にならないように、プログラミング初心者向けに、オブジェクト指向によるプログラミングの基本原則「SOLID Principles」を紹介します。

はじめに

プログラミングを始めたばかりというのはだいたい目の前しか見えていません。目の前の小さな問題解決で一杯一杯なので、そのソースコードが将来誰に読まれたり、どのように運用されたり、どのように拡張されたりなんてことは全く見えていないでしょう。そのまま進めていくと、後で気づいたら悲惨な技術的負債の山が出来上がっているかもしれません。

では、どうすればよいのでしょうか?簡単です。先人の知恵に従えばよいのです。いわゆるベストプラクティスを学ぶ事です。今回はオブジェクト指向でプログラミングをしたことがある経験者なら誰でも知っている基本原則「SOLID Principles」を噛み砕いて紹介します。

基本原則「SOLID Principles」

Single Responsibility Principle

最も有名な原則で、日本語では「単一責任の原則」や「単一責務の原則」などと表現されます。

これは「モジュールやクラスは単一の機能に対して責任を持たせるべき。」という原則です。別の言い方をすると、一つのクラスに関係の無い機能を沢山持たせずに、そのクラスが果たすべき責務に応じた機能だけを持たせなさい、と言うことになります。

メリットは、関係の無い機能間で影響が少なくなるので(いわゆる疎結合)、ロバスト性(他の機能を変更した時に関係の無い機能まで意図せずに変更しなければならない状況を避けること)を高めることができることです。さらに、この原則で書かれたソースコードはシンプルなクラスになるので読みやすいというメリットもあります。

Open / Closed Principle

これは「ソフトウェアのエンティティは拡張のためにオープンされ、変更のためにクローズドされるべき。」という原則です。別の言い方とすると、仕様変更が起きても修正する必要のないソースコードを書き(クローズド)、機能追加のために拡張できるソースコードを書くべき(オープン)と言うことになります。

それをどうやって実現するのかと言うと、オブジェクト指向では当たり前の「クラス継承」や「インターフェース実装」を利用したポリモルフィズムを実現することです。

このメリットは、やはりロバスト性が高まることと、既存機能への仕様変更の影響を少なくすることです。つまり、仕様変更や機能追加が簡単になるということです。

例えば、ある銀行の残高照会のAPIを使って会計簿を作るアプリを作るとします。その時、銀行を表すインターフェースを作った上でそれを実装した特定の銀行を表すクラスを作ったとします。すると、その銀行がAPIの仕様を変更したとしても、インターフェース経由でその機能を利用している他のクラスは変更する必要がありません(クローズド)。さらに、対応する銀行を増やす機能追加をする場合も、同じインターフェースを実装して作れば良いので拡張は容易です(オープン)。

Liskov Substitution Principle

これは「もしT型クラスのサブクラスとしてS型を定義した時、T型のオブジェクトはS型のオブジェクトと交換可能にすべき。」という原則です。別の言い方をすると、この原則を維持するには、親クラスを継承した子クラスがあり、子クラスが親クラスのメソッドをオーバーライドしている場合、オーバーライドしたメソッドに関して、引数となる型にはより抽象度の高い型を使うことができ、戻り値となる型には継承された型を使うことができます。

メリットは、ソースコード間の疎結合を促し、再利用性やメンテナス性を高めることです。

言葉で考えるとややこしいのですが、実はこれはJavaやC#などの主要なオブジェクト指向言語では自動的に満たされるため、クラス継承やインターフェース実装を行っていれば、意識せずに実現できます。C++などのかなり昔にできた言語はこの原則を満たすように意識してプログラミングする必要がありました。こういった原則の元となる文献はC++をベースに考えられていることが多く、その当時の状況を反映している原則だと言えます。

Interface Segregation Principle

これは「使用しないメソッド郡に依存するようなクライアントがあってはならない。インターフェースが多すぎるメソッド郡を持っている場合、そのメソッド郡を小さく具体的に分割することで、クライアントが関心のあるメソッドのみを持つようにすべき。」という原則です。別の言い方をすると、親クラスに沢山のメソッドを持たせると、それを継承した子クラスが不要なメソッドを持つ事になってしまうので、親クラスは共通的なメソッドのみを持つようにし、子クラスが必要なメソッドだけを持つようにすべきと言うことです。

メリットは、疎結合を促し、変更を容易にし、メンテナンス性を高めることができます。

デメリットとしては、複雑なアプリケーションの場合に、小さいメソッドが多すぎると、管理が難しくなるという問題があります。適切なさじ加減が腕の見せどころです。

Dependency Inversion Principle

これは「高レベルのモジュールは低レベルのモジュールに依存すべきでなく、間に抽象を挟むべき。抽象は詳細に依存すべきではなく、詳細が抽象に依存すべき。」という原則です。別の言い方をすると、ある具体的な処理をするクラス(低レベルのモジュール)があり、それを利用するクラス(高レベルのモジュール)がある場合、低レベルのクラスを抽象化したクラスもしくはインターフェースを用意し、高レベルのクラスはその抽象化したクラスもしくはインターフェースを経由して、低レベルのクラスを利用するように実装すべきと言うことです。

メリットは、高レベルのモジュールと低レベルのモジュールの間に抽象化するインターフェースを挟んでいるので、それらのモジュールは疎結合になり、メンテナンス性は向上します。

デメリットして、不必要に抽象化を行うと、無駄なインターフェースを量産することにつながり、ソースコードを複雑化してメンテナンス性を落とす結果になります。この抽象化が必要かどうかを見極めて適切に適用することが腕の見せどころです。

最後に

いかがでしたか?基本原則と言うのは意識せずに実行できるレベルになっている事が望ましいです。私の場合はこれらの基本原則はある程度プログラミングができるようになってから知ったのですが、全て当たり前だなと思ったのを覚えています。オブジェクト指向プログラミングをマスターしている人は何も考えずに行っていることだからです。これからオブジェクト指向プログラミングを身につけたいと思っている人は、この基本原則を意識して体に染み込ませましょう。では。

カテゴリ : 技術塾 タグ : oop, principles, programming

2018年4月13日 By KD コメントを書く

NodeJSの基本の3つのデバッグ方法

NodeJSの基本の3つのデバッグ方法

今回から「技術塾」と題して主に初心者向けに基本的な技術情報を提供するカテゴリを作りました。最初の内容は、NodeJSアプリケーション開発において必須のスキルであるデバッグです。デバッグのできないプログラマなんて、寿司の握れない板前、英会話のできない英語教師、ホームランの打てない4番バッター、はたまた、メダルを逃したオリンピック選手(これはちょっと違うか)、例えたら切りが無いですね。今回はそんな残念なNodeJSプログラマにならないために、基本となる3つのデバッグ方法を紹介します。

はじめに

NodeJSに限らずデバッグはプログラマ、エンジニア、デベロッパーにとって必ずマスターしなければいけないスキルの一つです。そのスキルが無いと、バグが発生した時に原因を突き止めて改修することが事実上不可能だからです。

今回はNodeJSの初心者を対象として、基本となる3つのデバッグ方法を紹介しますので、必ずマスターしましょう。

なお、デバッグの0番目の方法としてconsole.logがありますが、当たり前なので書きません。

基本の3つのデバッグ方法

デバッグ用のソースコードの準備

それではデバッグを試すためだけの簡単な環境を準備しましょう。

$ mkdir nodejs-debugging
$ cd nodejs-debugging/
$ yarn init -y
$ yarn add node-emoji
$ touch debugging.js

「debugging.js」は以下にします。

const emoji = require('node-emoji');

const puppy = {
  name: 'Pochi',
  age: 1,
  feeling: emoji.get('heart'),
  owner: 'Tom Cruise'
};

console.log(puppy);

単にオブジェクトをコンソールに出力するだけのコードです。

標準のデバッガーでのデバッグ

1つ目は「debugger」と「inspect」コマンドを使うコンソールでのデバッグ方法を紹介します。これはnode-inspectという機能で、NodeJSには最初から搭載されています。

やり方はアナログですが、ブレークポイントを設定したい場所に「debugger」を書きます。

スクリーンショット 2018 02 22 5 05 38

続いて、「node inspect」コマンドにより、デバッグを開始します。

スクリーンショット 2018 02 22 5 06 41

「c」コマンドにより、ブレークポイントまで進みます。

スクリーンショット 2018 02 22 5 11 34

ブレークポイントで停止した状態で、「repl」コマンドを実行することで、値を確認したり、値を変更したりできます。今回はpuppyのfeelingをheartからrelaxedに変更しました。確認や変更が終わったらControl+Cでこのモードから抜けます。

スクリーンショット 2018 02 22 5 11 57

そして、「c」コマンドを実行すると他にブレークポイントが無いので終了します。値を変更した箇所は変更されたままで出力されていることが確認できます。「.exit」でデバッグを終了します。

スクリーンショット 2018 02 22 5 14 26

デバッグ時のコマンドは以下です。

  • cont, c … ブレークポイントまで進む
  • next, n … 次のステップへ進む
  • step, s … ステップイン
  • out, o … ステップアウト
  • pause … ポーズ

今回使ったのは「c」コマンドだけですが、詳しくは公式ドキュメントを参照して下さい。

Chromeでのデバッグ

2つ目はCromeのDevToolを使ってデバッグ方法を紹介します。まさにNodeJSがJavascriptであることを活かしたデバッグ方法です。

まず、Chromeを開き、「chrome://inspect/」を表示します。

スクリーンショット 2018 02 22 5 42 12

次にコマンドラインで「node –inspect-brk」を実行しましょう。

$ node --inspect-brk debugging.js
Debugger listening on ws://127.0.0.1:9229/b50c177f-31d8-4db5-aac8-2411cdce33d9
For help see https://nodejs.org/en/docs/inspector

先程のChromeの画面にRemote Targetが表示されます。そうしたら「Open dedicated DevTools for Node」のリンクをクリックします。

スクリーンショット 2018 02 22 5 45 30

するとChromeのデバッグ画面が表示されます。

スクリーンショット 2018 02 22 5 47 07

試しに、コンソールのデバッグでやったのと同じことをしてみましょう。デバッグ画面からブレークポイントを設定します。ソースコードの横をクリックするだけです。

スクリーンショット 2018 02 22 6 02 47

右上の三角のボタンをクリックするとデバッグが開始されます。以下のようにブレークポイントで止まり、値を確認できます。

スクリーンショット 2018 02 22 6 05 08

Chromeのコンソールから値を確認することもできます。今回はfeelingの値をcycloneに変更しました。

スクリーンショット 2018 02 22 6 07 29

もう一度右上の三角ボタンをクリックすると、他のブレークポイントが無いので、デバッグが終了します。コンソールに結果が出力されています。

スクリーンショット 2018 02 22 6 09 27
この方法はかなり便利で、特にnodemonでアプリケーションを起動している場合は、ソースコードを変更してすぐに、デバッグの画面が更新されてます。node-inspectよりはるかにデバッグが簡単です。

Visual Studio Codeでのデバッグ

3つ目はVS Codeを使ったデバッグ方法を紹介します。

ソースコードをVS Codeで開き、左側の虫のようなアイコンをクリックします。

スクリーンショット 2018 02 22 6 37 41

するとデバッグ画面が表示されるので、上の「構成がありません」をクリックします。

スクリーンショット 2018 02 22 6 19 02

そして、「構成の追加」を選びます。

スクリーンショット 2018 02 22 6 19 18

「環境の選択」には「Node.js」を選びます。

スクリーンショット 2018 02 22 6 42 35

すると「launch.json」というデバッグ設定ファイルが自動生成されます。

スクリーンショット 2018 02 22 6 20 21

今回は単にデバッグモードで実行できれば良いので、デバッグ設定ファイル(launch.json)は以下のように設定します。

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Run",
      "program": "${workspaceFolder}/debugging.js"
    }
  ]
}

後は、Chromeの時と同じようにデバッグできます。

ソースコードの右側をクリックして、ブレークポイントを設定します。

スクリーンショット 2018 02 22 6 45 43

デバッグボタンをクリックするとデバッグが開始されます。

スクリーンショット 2018 02 22 6 48 25

ブレークポイントで止まっている状態では以下のようになっています。

スクリーンショット 2018 02 22 6 50 41

それでは、先ほどと同じように値を変更してみます。デバッグコンソールからChromeの時と全く同じように値を扱えます。

スクリーンショット 2018 02 22 6 53 10

値の確認と変更が終わったら、上にある三角のボタンをクリックすれば、実行が再開されます。

スクリーンショット 2018 02 22 6 54 51

デバッグコンソールに結果が出力されて、デバッグが終了しました。

スクリーンショット 2018 02 22 6 56 43

この方法であれば、VS Codeのエディタ上でコーディングからデバッグまで完結させることができ、大変便利です。なので、当然これが一番オススメの方法です。

デバッグ設定ファイルの詳細はVS Codeの公式サイトを参照して下さい。

最後に

いかがでしたか?これでNodeJSのデバッグ方法の基本はマスターできたと思います。自分の関わったアプリケーションで障害が出た時に、華麗にデバッグして原因を究明し、ささっと改修してプロの仕事を見せつけましょう。それでは。

環境

  • NodeJS : v9.5.0
  • node-emoji : 1.8.1

カテゴリ : 技術塾 タグ : debug, nodejs

2017年8月12日 By KD コメントを書く

初心者エンジニア必見!Windows VS Mac 推奨基本ツール

初心者エンジニア必見!Windows VS Mac 推奨基本ツール

そろそろ夏休みですねー。俺は今海外です(笑)数年は日本には戻らない予定ですが、人生は気分とタイミングで決まるのでどうなるかは未来の自分しか知りません。手に職があるので何とでもなると思っているこの頃です。

対象

今回の記事は初心者のアプリケーションエンジニア向けです。 特にWindowsを主に使っている人向けに、自分のお薦め(推奨)の基本ツールセットを紹介します。ついでに、Macに乗り換えたばかりの人は助かることがあるかもしれません。

基本ツールとは?

今回はターミナル、シェル、ランチャー、パッケージマネージャーのことだと定義します。(良い言い方が思いつかなかったので。)また、テキストエディタに関しては対象外としました。完全に好みの問題ですし、WindowsとMacで差異はほぼ無いためです。(とは言っても安定のSublime Text3かVisual Studio Codeがお薦めです。サクラエディタやTextMateを使ってる人はもういないでしょう。)

推奨基本ツールの一覧

  Windows Mac
ターミナル Cmder iTerm
シェル GitBash Bash
ランチャー Launchy Alfred
パッケージマネージャー Chocolatey Homebrew

ターミナル

Windowsはコマンドプロンプト(用の端末)が標準で搭載されていますが、かなりショボいです。Macで標準で搭載されているターミナルと比較しても、枠を簡単に調節できないし、コピペがめんどくさい上に、デザインもダサいです。 Windowsの標準は良いとこなし。そこでCmderの登場です。上記のコマンドプロンプトの弱点をすべてカバーしてくれます。

一方、Macは標準のターミナルでもWindowsより優れていますが、iTermに乗り換えればタブで開けたりなどさらに便利になります。

シェル

Windowsには専用のコマンド群が用意されていますが、Linuxコマンドとは異なるため、tail -fやsshなどのコマンドが使えません。そこでGit for Windowsをインストールすることで付いてくるGitBush(msysgit)が便利です。これを入れれば、Linuxの基本コマンド郡がexeとして手に入ります。自分はCmderからGitBushとPowerShellを切り替えながら使っていました。(もうCygwinを使う人もいないでしょう。)

ちなみに、Windows標準でtail -fをするには、PowerShellから「Get-Content ファイル -Wait -Tail 末尾からの行数」と入力すれば良いです。Windowsユーザでも意外と知らない人がいますよね。

なお、Bash on Linux on Windowsはまだ様子見の段階だと思います。MacやLinuxのようになることはOSを一から作り直さない限り無いと思いますが、Windowsにしては前向きな取り組みですね。

MacはLinuxと同じシェル環境が手に入るので、好きなシェルが選び放題です。特にこだわりが無い人は標準のBashが一番でしょう。機能性重視の人はやはりZshになるかと思います。

ランチャー

Windowsには標準でランチャーがありません。なので、もうめんどくさいです。そこで、昔からあるLaunchyがまあまあ良いです。他にも、WowやHainあたりを試してみるのも良いでしょう。Windowsユーザはランチャーがあるだけで捗りますよ。

Macは安定のAlfredでしょう。標準のSpotlightで満足できるならそれで良いですけどね。

パッケージマネージャー

Windowsに何かソフトを入れる場合はサイトからインストーラをダウンロードしてきてインストールするのが一般的ですが、PCをセットアップするたびにうんざりします。LinuxやMacみたいにコマンドだけでインストールできないものでしょうか?そこで、Chocolateyの出番です。パッケージが豊富というわけではありませんが、そこそこ必要なものは手に入ります。

他にも、マイナーなところでScoopもありますし、.Net用にはNuGetが提供されていますので、試してみるのも面白いです。

Macはもはや一強となったHomebrewです。一世代前のMacPortsはいつの間にか誰も使っていません。Homebrew-Caskも素晴らしいです。(一時期Chef/Puppet/AnsibleでMacの環境を構築するヲタクがいましたが、過去の話です。)

最後に

自分はWindowsからMacに乗り換えた派なので、両方の良さとWindowsの苦しみを知っています。と言うか、普通の人ならWindowsが最初のPCになると思いますが、MacにするともうWindowsに戻れそうにありません。Windowsユーザがせめて少しでも良い環境を手に入れられることを願ってこの記事を書きました。Windowsもっと頑張れ!

カテゴリ : 技術塾 タグ : launcher, mac, packagemanager, shell, terminal, tumblr-imported, windows

  • « 前のページ
  • 1
  • 2

ブログ更新情報や海外の関連情報などを配信する無料メルマガ

Sponsored Links

About Author

KD

世界を旅し日本を愛するエンジニア。大学でコンピュータサイエンスの楽しさを学び、日本の大手IT企業で働く中で、新しい技術やスケールするビジネスが北米にある事に気づく。世界に挑戦するための最大の壁が英語であったため、フィリピン留学およびカナダ留学を経て英語を上達させた。現在は日本在住でエンジニアとして働きつつ、次の挑戦に備えて世界の動向を注視している。挑戦に終わりはない。このブログでは、エンジニアやデザイナー向けの技術情報から、海外に留学したい人向けの留学情報、海外に興味がある人向けの海外旅行情報など、有益な情報を提供しています。

https://casualdevelopers.com/

最近の投稿

  • 2020年JS周辺のバックエンド寄りの注目技術!ネクストNodeJSの「Deno」と分散型パッケージレジストリの「Entropic」の紹介

    2020年JS周辺のバックエンド寄りの注目技術!ネクストNodeJSの「Deno」と分散型パッケージレジストリの「Entropic」の紹介

    2020年1月13日
  • 今さら聞けないJavaによる関数型プログラミング入門 ~ラムダ式、ストリーム、関数型インターフェース~

    今さら聞けないJavaによる関数型プログラミング入門 ~ラムダ式、ストリーム、関数型インターフェース~

    2019年11月4日
  • ReactのためのEslintおよびPrettierの設定方法 ~Airbnb JavaScript Style Guideの適用~

    ReactのためのEslintおよびPrettierの設定方法 ~Airbnb JavaScript Style Guideの適用~

    2019年10月30日
  • BashからZshに移行する方法(Mac編)

    BashからZshに移行する方法(Mac編)

    2019年10月21日
  • Create React Appを使わないでゼロからReactの開発環境を構築する方法(Webpack/Docker編)

    Create React Appを使わないでゼロからReactの開発環境を構築する方法(Webpack/Docker編)

    2019年9月30日

カテゴリ

  • 技術 Tips & Tutorials (100)
  • 技術塾 (6)
  • ライフハック (26)
  • 海外留学 (12)
  • 英語学習 (3)
  • コラム (6)

アーカイブ

最高の学習のために

人気記事ランキング

  • MySQLで「ERROR 2003 (HY000): Can't connect to MySQL server」と怒られた時の対処法
    MySQLで「ERROR 2003 (HY000): Can't connect to MySQL server」と怒られた時の対処法
  • Jupyter Notebookで「The kernel appears to have died. It will restart automatically.」というエラーが出た場合の原因と対処法
    Jupyter Notebookで「The kernel appears to have died. It will restart automatically.」というエラーが出た場合の原因と対処法
  • SAKURAのメールボックスで独自ドメインのメールを設定し、Gmail経由で送受信する方法
    SAKURAのメールボックスで独自ドメインのメールを設定し、Gmail経由で送受信する方法
  • バンクーバー留学豆知識:バンクーバーのATMで日本の銀行のキャッシュカードを使ってお得にお金を引き出す方法
    バンクーバー留学豆知識:バンクーバーのATMで日本の銀行のキャッシュカードを使ってお得にお金を引き出す方法
  • Amazon EC2インスタンスにSSHできなくなった時の対処法
    Amazon EC2インスタンスにSSHできなくなった時の対処法
  • Expressで「Cannot set headers after they are sent to the client」と怒られた時の対処法
    Expressで「Cannot set headers after they are sent to the client」と怒られた時の対処法
  • TumblrからWordPressにブログ移転する最適な方法
    TumblrからWordPressにブログ移転する最適な方法
  • SpringBootのProfile毎にプロパティを使い分ける3つの方法
    SpringBootのProfile毎にプロパティを使い分ける3つの方法
  • 今さら聞けないJavaによる関数型プログラミング入門 ~ラムダ式、ストリーム、関数型インターフェース~
    今さら聞けないJavaによる関数型プログラミング入門 ~ラムダ式、ストリーム、関数型インターフェース~
  • バンクーバー留学豆知識: バンクーバーのカジノを攻略せよ!必勝法を公開します!
    バンクーバー留学豆知識: バンクーバーのカジノを攻略せよ!必勝法を公開します!

Bitcoin寄付 / BTC Donation

Bitcoinを寄付しよう

BTC
Select Payment Method
Personal Info

Donation Total: BTC 0.0010

このブログの運営のためにBitcoinでの寄付を募集しています。お気持ち程度の寄付を頂けると管理者の励みになります。

Bitcoin寄付について知りたい方はこちらの記事へ

ビットコイン取引ならここ

  • ホーム
  • 技術 Tips & Tutorials
  • 技術塾
  • ライフハック
  • 海外留学
  • 英語学習
  • コラム
  • サイトマップ
  • タグ一覧
  • プライバシーポリシー
  • お問い合わせ

Copyright © 2023 KD - Casual Developers Notes