マンガではわからない ソフトウェア開発の真理 | ドクセル目指せ脱UE4初心者！？知ってると開発が楽になる便利機能を紹介 - DataAsset, Subsystem, GameplayAbility編 -
SIerで仕事やっていてよく見るコードと直し方 - デメテルの法則違反 - Qiita
仕事やっていてよく見るアンチパターンをまとめていこうと思ってます。今回はデメテルの法則違反です。 コードはScalaですが、RubyやPythonやJavaでも基本同じです。 トピックは以下。 違反したコード とりあえず直す とりあえず直したあとのテスト デメテルの法則に違反したコード デメテルの法則とは、「直接インスタンス化したもの」か「引数として渡されたもの」以外のものを使ってはいけないという法則です。 class Profile(name: String, age: Int) { def showProfile(): Unit = println(s"my name is $name (age: $age)") } class Applicant(id: String, val profile: Profile) object Order { // デメテルの法則に違反している de
デメテルの法則 - Wikipedia
デメテルの法則 (Law of Demeter, LoD) または最小知識の原則 (Principle of Least Knowledge) とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 このガイドラインは1987年の末にかけてノースイースタン大学で作成された。簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 「デメテルの法則」という名前は、この法則がアダプティブプログラミングとアスペクト指向プログラミングに関する研究であるデメテルプロジェクトの成果であることに由来する。プロジェクト名は農業の女神であるデーメーテールにあやかっている。 オブジェクト指向における適用[編集] オブジェクト指向
依存性逆転の原則 - Wikipedia
依存性逆転の原則または依存関係逆転の原則（dependency inversion principle）とは[1]、オブジェクト指向設計の用語であり、ソフトウェアモジュールの疎結合を確立する特別な形態を表現したコンセプトである。SOLIDの五原則の一つとして知られる。 オブジェクト指向における従来の依存関係とは、上位モジュールから下位モジュールへの方向性であり、仕様定義を担う上位モジュールを、詳細実装を担う下位モジュールから独立させて、各下位モジュールを別個保存するというものだったが、それに対して依存性逆転原則は以下二点を提唱している[2]。 上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも抽象（例としてインターフェース）に依存するべきである。 "High-level modules should not import anything from low-le
SOLID - Wikipedia
SOLID（ソリッド）は、ソフトウェア工学の用語であり、特にオブジェクト指向で用いられる五つの原則の頭字語である。ソフトウェア設計をより平易かつ柔軟にして保守しやすくすることを目的にしている。その特徴はインターフェースを仲介にしての機能の使用と、インターフェースによる機能の注入である。 この五つの原則は、アメリカのソフトウェア技術者ロバート・C・マーティン（英語版）が提唱していた数々の設計原則の中からチョイスされたものである。マーティンが提唱していた原則は、例えば2000年に発表されたレポート『Design Principles and Design Patterns』[1]の中で紹介されている[2][3][4]。そのうち五原則をSOLIDという語呂合わせの頭字語にして普及させたのは、ソフトウェア技術者マイケル・フェザーズであり、2004年以降に広く知られるようになった[5]。SOLIDは
インピーダンスミスマッチ - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "インピーダンスミスマッチ" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2020年8月） インピーダンスミスマッチとは、インピーダンスの整合ができていない状態のことである。電気電子の分野においては、エネルギーの伝送という観点からは反射や損失を発生させ、非効率の原因となるため問題にされる。理論的には、電気的なものに限らず、音波などといった媒質中を伝搬する波について全く同様の現象がある。 電気電子[編集] 電気的総合的な説明はインピーダンス整合（この記事名である「インピーダンスミスマッチ」の対義的な語である「インピーダンスマッチ」のことであ
アスペクト指向プログラミング - Wikipedia
アスペクト指向プログラミング（Aspect Oriented Programming、AOP）は、横断的関心（英語版）を実装する手法によって、プログラムのモジュール性を高めることを目的にしたプログラミングパラダイムである。横断的関心とは、関心の分離によるモジュールの複数以上にまたがっている共通機能を意味している。AOPはこの横断的関心を、既存コードに設けた間接点（joint point）を通しての振る舞い助言（advice）の追加によって、コード変更を伴なわずに実装できるようにしている。任意の間接点および振る舞い助言の定義をまとめたモジュールがアスペクト（英語版）と呼ばれ、これが横断的関心の表現体になる。例としては、全ての関数呼出しにログ出力を伴わせたい時に、全関数冒頭にjoint pointを設けてログ出力コードをadviceにしたアスペクトをプログラム内に定義することで、自動的に各関数
9. Classes
9. Classes¶ Classes provide a means of bundling data and functionality together. Creating a new class creates a new type of object, allowing new instances of that type to be made. Each class instance can have attributes attached to it for maintaining its state. Class instances can also have methods (defined by its class) for modifying its state. Compared with other programming languages, Python’s
Tell, Don't Ask [ 求めるな、命じよ ] - はむはむエンジニアぶろぐ
Tell, Don't Ask は、オブジェクト指向プログラミングのよいとされる考え方の一つです。 Tell, Don't Ask は、日本訳で 求めるな、命じよ と訳されているのが、多いみたいですね。 オブジェクト指向というのは、役割を思ったオブジェクト同士が協力(コラボレーション)しながら機能(価値)を提供する。 オブジェクトが持つ役割が、あいまいだと良い設計と言われている 凝集度が高く結合度の低い ものは出来ません。 その為に、必要な考え方の一つなのが Tell, Don't Ask [求めるな、命じよ] である。 求めるな、命じよって言われてもピンきにくいですよね(´・ω・｀)w シーケンス図とか書いてみて、解説します。 Tell, Don't Ask Tell, Don't Ask とは、 Ask ではなく Tell しなさいというものです。 オブジェクトAが、オブジェクトBを呼
![Tell, Don't Ask [ 求めるな、命じよ ] - はむはむエンジニアぶろぐ](https://cdn-ak-scissors.b.st-hatena.com/image/square/ac7e2df06bedb9512e0b7b1b3caa43724e98d3a7/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fs%2Fsecret_hamuhamu%2F20150816%2F20150816222337.jpg)
Object Oriented Programming in Bash
Bash is a very common *nix shell, and it's programming language is purely procedural and focused on command execution. Object Oriented Programming (OOP) is a programming paradigm that represents the elements of a problem as entities with a set of properties and actions that it can execute. If you use Bash to write very simple and short scripts, procedural programming is just fine, you don't need m
unityでオブジェクト指向な作り方ってなんなの＼(^o^)／ その２ （SpaceShipクラスの作成と拡張） - Qiita
概要 前回、unity公式チュートリアルの2Dシューティングゲームの第二回、第三回でプレイヤークラスと弾クラス用に親クラスのゲームキャラクラスを作りました。 unityでオブジェクト指向な作り方ってなんなの＼(^o^)／ その１ 今回は第四回で敵クラスを作成しますが、そこで新たに作成するSpaceshipクラス。unityではこれを作ってプレイヤーや敵のオブジェクトにアタッチすることで戦闘機系クラス？として使って下さいということなんだろうか… シューティングチュートリアルサイト 第04回 敵を作成しよう こちらも自分のできる範囲でオブジェクト指向を意識して変更をしていこうと思います。 Spaceshipクラスを作成（GameCharaクラスを継承する） 継承前のチュートリアルに書かれていたSpaceshipクラス using UnityEngine; [RequireComponent(t
オブジェクト指向設計（2016年度）
コンテンツ 第1章 基本的な用語 第2章 オブジェクト指向開発 第3章 設計の問題 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第1章 基本的な用語 クラスとオブジェクトの違い 第2章 オブジェクト指向開発 オブジェクト指向開発 オブジェクト指向分析 機能外要求 User インタフェース Student クラスとTeacher クラス Student クラスのソースコード Teacher クラスのソースコード 演習2-1 UserLocator クラスのソースコード 演習2-2 演習2-2 の解答 Teacher.java UserLocator.class 第3章 設計の問題 演習3-1 演習3-1 の解答1（返却値を利用した方法） 演習3-1 の解答2（条件分岐
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: アナリシスパターン 新装版: 再利用可能なオブジェクトモデル (ObjectTechnologySeries 2): マーチンファウラー (著), Fowler,Martin (原名), 一,堀内 (翻訳), 晶夫,友野 (翻訳), 公信,児玉 (翻訳), 文雄,大脇 (翻訳): 本
Go vs. Java: 15 main differences
What's the difference between a method and a function?
オブジェクト指向とは何ですか？
オブジェクト指向とは何だったのか？ – ゆびてく
Flame
Ralph Johnson, Joe Armstrong on the State of OOP
99 Practical Bottles of OOP with Sandi Metz (Changelog Interviews #225)