buto > /dev/null

だいたい急に挑戦してゴールにたどり着かずに飽きる日々です

AWS PostgreSQLに接続できない

公式チュートリアルPostgreSQLの作成・起動をした

PostgreSQL データベースを作成、接続する 説明に従ってポチポチ、作成と起動はできたがクライアントツールからDBに接続できない。。。

原因は以下 - DBを作成していなかった(DBインスタンスだけ作成していた) - 5432ポートの通信を許可するセキュリティグループを作成していなかった

セキュリティグループ

AWSドキュメントによると

セキュリティグループは、インスタンスの仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドトラフィックをコントロールします。

インスタンスごとに設定するファイアウォールのことか 最初、VPCのセキュリティグループをPostgreSQLインスタンスにも適用するように設定していて、 このセキュリティグループが「TCP通信 ポート:5432」を許可する設定がなかったのが原因

PostgreSQLインスタンスを作成する時に、セキュリティグループは「新規作成」にしてあげると このインスタンスでのTCP通信を許可する設定がされたファイアウォールが作成された! (VPCのセキュリティグループにも送信元IP、ポートを設定すればいけそうだ)

PostgreSQLインスタンス用のセキュリティグループが作成されたら無事、接続成功しました!

デザインパターン入門 Adapter

Adapter

メソッドが違うなどして継承できない2つのクラスの仲介をする 既存のクラスは修正せず、仲介するAdapterを作ることで修正範囲を最小限にできる

デザインパターン ~Adapter~ 内部処理用のBeanクラスと画面から値が入ってくるBeanクラス同士が 直接、継承などで結び付けられない時に使うのか!

新規の画面と入力値がやりとりできないから、とかで新しくBeanを作ったことがあるような…

デザインパターン入門 Singleton

Singleton

クラスのコンストラクタをprivateにして他クラスからインスタンスを生成できないようにする (シングルなインスタンスインスタンス同士が作用して不具合が発生する可能性があるので、Singletonパターンで防ぐ

インスタンスの相互作用から発生しうる不具合

思いついたのはこんな不具合 - static変数(グローバル変数)が書き換えられてしまう - static変数にはfinalキーワードをつけましょうって習ったな - 排他制御で処理が実行できない - DB更新をするインスタンスが複数あると、一方のインスタンス排他制御をしていてもう一方ではDB更新が行えない

デザインパターン入門 Prototype

Prototype

インスタンスの生成をnew Class()でなく、インスタンスから別のインスタンスを生成する 雛形を作っておき、それをコピーして使う 例が思い浮かばなかったのでTECHSCOREの記事を使います

図形描画で「直線を描画するクラス」と直線を組み合わせて「図形を描画するクラス」がある 図形描画クラスで定義した三角、星などの図形を描画する処理を 雛形管理クラスでmap.put("star",星型の描画処理)のようにインスタンスを保存する → 星型をたくさん描画したい時はmap("star")だけでOK

f:id:butorisa:20201020170930j:plain

図形ごとにクラスを作成するとクラス数が多すぎて保守性が下がるのでPrototypeパターンを使う

業務で「クラス名が違うだけでプロパティは同じ」複数のクラスを作ってしまったことがある… 次からはPrototypeパターンが使えないか検討しよう

デザインパターン入門 Factory Method

Factory Method

スーパークラスを定義して、処理はサブクラスが行う スーパークラスがサブクラスに依存しないから改修はサブクラスだけで済む

スーパークラスは「登録する」ことだけ定義されているので、サブクラスに依存しない

f:id:butorisa:20201020170814j:plain

Builderパターンとの違い

  • Builder
    • クラスのアウトラインは抽象クラス
    • 処理を持ったサブクラスと組み合わせて複雑な処理を実現
  • Factory Method
    • 抽象クラスには概念くらいアバウトな定義だけ(登録するなど)
    • サブクラスは登録する処理だったら何でもOK
    • 抽象クラスがサブクラスに依存しないので修正範囲を切り分けられる

Abstract Factoryパターンとの違い

  • Abstract Factory
    • クラスごと(クラスに定義されている一連の処理をまとめて)サブクラスが実装
  • Factory Method
    • メソッド単位でサブクラスが実装

デザインパターン入門 Builder

Builder

抽象クラスを定義して処理は継承したクラスが行う 具象クラスのインスタンスによって処理の切り替えが簡単にできる

商品登録は「フォーム画面から登録」と「バーコードから登録」できる ピンクの商品登録クラスに具象クラスのインスタンスを渡せば登録方法が切り替えられる

f:id:butorisa:20201020170651j:plain

フォームから登録だと、「フォーム登録インスタンス」をピンクの商品登録に渡せばOK

デザインパターン入門 Abstract Factory

デザインパターンとは

今さら聞けない!デザインパターンとは【初心者向け】

デザインパターンとは、JavaRubyなどのオブジェクト指向の言語で使われる設計パターンのことです。過去のエンジニアが解決してきた方法(設計)が、デザインパターンとしてまとめられているのです。

読みやすく、ムダのないコード書いてみたい… 行き当たりばったりのコーディングとはお別れだ!!

Gang of FourGoF

GoFのデザインパターンまとめ あらゆるコードのパターンは23種類に落ち着く、らしい! 早速、1つ目のパターンを見てみる

Abstract Factory

抽象クラスを作成し、実装は抽象クラスを継承したクラスで行う クラスの追加・変更があった時の修正が最小限にできる

例えば、ECサイトで 「商品にはid、商品名、価格は絶対必要」だけど、今後セールも開催したいなって時は 商品を抽象クラスにして、セール対応をする時に商品クラスを継承すればOK

f:id:butorisa:20201020170359p:plain

セール商品もid、商品名、価格(定価)は必要だから商品クラスから引き継げると楽

絶対置き換わる、削除されないプロパティは抽象化しておくと継承で再利用できるから便利 1クラスになんでもかんでも詰め込まないから変更に強い