プロとしての行為 Act as Proffesional
オブジェクト指向エクササイズ下記のルールで、1000行程度のソフトウェアを書いてください。 1. 1つのメソッドにつきインデントは1段階までにすること 2. else句を使用しないこと 3. すべてのプリミティブ型と文字列型をラップすること 4. 1行につきドットは1つまでにすること 5. 名前を省略しないこと 6. すべてのエンティティを小さくすること 7. 1つのクラスにつきインスタンス変数は2つまでにすること 8. ファーストクラスコレクションを使用すること 9. Getter、Setter、プロパティを使用しないこと というルールが適応できない場合は優先すべきルールを選択し、どのルールを適応するのか判断して欲しいとの旨が記載されています。 9つのうち 7つがデータのカプセル化 1つポリモフィズの適切な利用（else句をつかわない） 1つが明確でわかりやすい命名標準 オブジェクト指向
デザインパターンの話 - Qiita
irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基本的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前の本でこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる
その７ 参照オブジェクトの正体は気にしない原則 ： LSP
ホーム < ゲームつくろー！ < オブジェクト指向設計編 < 親の決まりを子が破っちゃいけない原則 ： LSP その７ 親の決まりを子が破っちゃいけない原則 ： LSP オブジェクト指向には、守るべき原則がいくつかあります。その３ではOCP(Open-Closed Principle：開放閉鎖原則)という大原則を紹介しました。この章で紹介するLSP(Liskov Substitution Principle：リスコフの置換原則)もまた大切な原則です。どういうものであるか、さっそく見ていくことにしましょう。 ① LSPって何だ？ LSP(Liskov Substitution Principle：リスコフの置換原則)というのは、Barbara Liskovさんが1988年に唱えたオブジェクト指向の継承に関わる原則です（コードコンプリート第2版上巻p175）。これは、基本型で決められた約束を派
その３ 拡張できて修正不要の原則 ： OCP
ホーム < ゲームつくろー！ < オブジェクト指向設計編 < 拡張できて修正不要の原則 ： OCP その３ 拡張できて修正不要の原則 ： OCP オブジェクト指向には幾つか「原則」と呼ばれるものが存在しています。原則（Principle）というのは約束(Promise)や指針（Guideline）よりもはるかに強い戒めです。オブジェクト指向における原則は、よっぽどの理由が無い限り破る事は許されないものばかりです。沢山ある原則の中で、ここではオブジェクト指向の基本原則である「Open-Closed Principle : OCP」について見ていくことにします。尚、今回の話は「まさーるのページ」（石井様作成）にあるオブジェクト指向に関する素晴らしいお話の影響を多大に受けております。このページをご覧になりますと、オブジェクト指向の本が読みたいと熱望してしまうこと間違いなしです。私も思わず関連本を
アジャイル設計と5つの原則 - かまずにまるのみ。
アジャイルソフトウェア開発の奥義 第2部「アジャイル設計」の自分用まとめ。 アジャイル設計 アジャイルな設計 「原則」「パターン」「プラクティス」を継続的に適用することで、読みやすく変更に強い状態を保つことができる設計。 悪い設計 第2部の中で「貧弱な設計の兆候」「腐敗するソフトウェアの兆候」として、以下の7つが挙げられている。 硬さ （設計変更が難しい） 脆さ （設計が壊れやすい） 移植性のなさ （再利用が難しい） 扱いにくさ（正しい設計をするのが困難なソフトウェア、面倒な開発環境） 不必要な複雑さ（"後で必要になるかもしれない"と考えて先行実装したコード） 不必要な繰り返し （コピペ） 不透明さ （目的や意図がわかりにくい） 原則 システムに悪い設計の兆候が見られるとき、その原因がオブジェクト指向設計の原則に反していることだったりする。 ただし無条件で原則に従うと「不必要な複雑さ」を招
オブジェクト指向とは何なのか考えてみた - Flat Leon Works
オブジェクト指向の概要 オブジェクト指向の位置づけ 命令型から手続き型へ、そしてオブジェクト指向へ オブジェクト指向+αでメリットが出てくる (おまけ)良質なプログラミングとは何か まとめ オブジェクト指向とは何なのか考え抜いてみました。 オブジェクト指向の概要 用語の位置づけプログラミング(プログラム設計)の手法 用語の意味オブジェクトへのメッセージ送信でプログラミング(プログラム設計)を行うこと なぜ使われるのか1.手続き型プログラミングより自然な考え方になるから 2.プログラミング言語の機能によるサポート次第でより便利になるから 3.設計の工夫で良質なプログラミングが可能になるから オブジェクト指向の解説がわかりにくくなっているのは、「オブジェクト指向自体の解説」と「オブジェクト指向をより便利にする言語機能の解説」と「オブジェクト指向でよりよいプログラミングを行うための手法の解説」が
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
オブジェクト指向と10年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向は難しい！わかった気になって実践すると詰みます... ｳｷﾞｬｰ この記事は10年以上オブジェクト指向と戦った筆者が、通常とは異なるアプローチでオブジェクト指向を解説したものです。 筆者はJavaを使って本格的なシステム開発をしたことがありませんが、オブジェクト指向言語として最もポピュラーなJavaをベースにオブジェクト指向について解説させていただきました。 また、この記事の続編にあたります「なぜオブジェクト指向は難しいのか」を更に2年の時を経て執筆させて頂きました！是非こちらも一読していただけると嬉しいです。 オブジェクト指向三大要素の謎 オブジェクト指向三大要素ってありますよね。オブジェクト指向は「カプセル化」「継承」「ポリモーフィズム」の3つの要素で成り立つと言われています。最近では、この三大要素が語られる傾向は薄いようですが、一度は耳にしたことがある
Java 的オブジェクト指向を 90 分で理解する - 偏見プログラマの語り！
1. 分からない。いくら説明を読んでも分からない。 ● 1.1. 未だに分からない Java 的オブジェクト指向 今日び Java 的オブジェクト指向の説明なんて星の数ほどあるような気がしますが、それでもなお「これで分かった！」という説明に辿りつけない不運な人がいるようですね。まぁこんだけ色々な説明が溢れていたら逆にどれを読めば良いのかワケ分からなくなってしまうのかもしれません。じっくり読んでも理解できなかったのであれば、きっとその説明と読者の相性が悪かったんでしょう。… というわけで、僕も Java 的オブジェクト指向が全っっっっ然これっぽっちも分からないという人に向けて説明する記事を書こうと思います。そうでない人には無価値な記事ですのでブラウザの「戻る」をクリックしましょう。 ● 1.2. 「オブジェクト指向」という名の南の島がある オブジェクト指向にはいくつもの専門用語があって、学習
先輩「if文使うなんてダセープログラム書くんじゃねーよ！」 - ヨーホー
さて、４年前ぐらいにタイトルで書いたようなことを先輩に言われた訳ですが、その時はそのまま流してしまいました。 俺はSEって言ってもインフラ系でプログラムをあんまり書きません。 そんな訳で当時は何となくだけど、if文はコストがかかる（実行速度が遅くなる？）から出来るだけ使うなよ、って意味で解釈しました。 でも内心、if文使わなかったらどうやって条件分岐するんだよ！って思っていました。 最近、折角この業界にいるんだから、プログラムぐらいサラッと書ける方が カッコイイなと思ってプログラムを書いて遊んでいた所、if文を使わない条件分岐の方法を知りました。目からウロコです。 どうやるかって言うと、「多重配列を使えばいいんです！」 はい。リピートアフタミー。 「多重配列を使えばいいんです！」 具体的にどうするかは、下に書きます。例としてジャンケンをするプログラムをPHPで書きました。 まずは、if文を
オ・ト・ナのカプセル化再入門 - Qiita
よく、初心者向けの教科書に「とりあえずprivateを指定し、必要な物はpublicにしましょう。」と書いてありますが、これは大きな間違いです。 最初にアクセス修飾子を熟知しておかなければ、Java という言語を扱う上で最良の設計を行なうことは難しいでしょう。 そんな教科書は今すぐ窓から投げ捨てるか、ちり紙代わりに使いましょう。 Package パッケージは Java のクラス郡をまとめるための仕組みです。主に利用する目的として、以下の 2 点ががあります。 名前の衝突を避ける事が出来る。 パッケージによるアクセス制御を行なえる。 これらを利用する事で Facade デザインパターンを忠実に実現することができます。 Java のカプセル化においてこの仕組みは必要不可欠でしょう。 Design patterns 次に、ソフトウェア設計において基本的な 2 パターンを紹介します。 Facade
Getter/Setterは悪だ。以上。 | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、Getters/Setters. Evil. Period.を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 2003年にAllen Holubが書いたWhy getter and setter methods are evilという有名な記事に端を発する古い議論がある。それは、getter/setterはアンチパターンで避けるべきものなのか、 もしくはオブジェクト指向プログラミングに必須なものなのかというもの。 この議論に少しだけ私の意見を加えたいと思う。 上記記事の要旨はこうだ。 getterやsetterはひどい慣習で、これらを使うやつらはゆるせん。誤解の無いようもう一度言うが、 私はget
BEMという命名規則とSass 3.3の新しい記法 - アインシュタインの電話番号
BEMを使った命名がとても明快で、このところHTMLやCSSを書くのによく使っている。CSSのクラス名として書く場合は、BEMをCSS用に使いやすくしたMindBEMdingという書き方を採用している。最初にこれを知ったときは「こんな汚い記述の仕方は使いたくない」と思ってたんだけど、すっかり慣れて、今ではその明快さにちょっと心酔しかけているほど。 BEMの方法論とMindBEMdingのルールについてはそれぞれの文書を読んでもらうとして、それらをひっくるめて大雑把に説明すると、BEMとはBlock、Element、Modifierの頭文字を取ったもので、構成する要素をそのどれかに当てはめて命名していく方法。どの場合でも必ずBlockもしくはそのModifierがルートにあり、その中に、所属するElementもしくはそのModifierが含まれる構成になる。 Block - 構成のルートとな
車買取一括査定を依頼してこんな交渉には注意？
少しでも高く車を売りたい。そして申込みをスムーズに行うためにも 車買取の一括査定サービスはとても便利です。 複数の業者へ一斉に中古車査定を依頼するのですが、交渉には少し注意が必要です。 一括査定からの申込みなので、業者も始めから競争相手がいることは知っています。 業者としては少しでも低い査定額で早く決めてしまいたいもの。 他の業者が来る前に、決断させるような交渉を進めます。 「今決めるなら、プラス１０万円上げます」というような上乗せした査定額を 提示することもあります。思わず決めたくなりますが、冷静に考えてみると 最初からプラス１０万円の提示ができたはずです。このやり方に誠意を感じますか？ それでも決めてしまうか、他の業者を待つかはご自身次第になりますが、 このような交渉術はよくあることです。頭に入れておくと良いですね。 高額な査定額を探すためには、査定を依頼した車買取業者の金額がすべて
オペランドの原則 - Strategic Choice
メソッドの引数にはオペランドのみを入れるべきである。どういうこと？クラスへのアクセスはメソッドを通じて行われます。メソッドが単純で使いやすいことが、クラスの使いやすさを決定します。特にメソッドの引数リストが短いことは、メソッドをシンプルにするので、クラスの品質に大きく貢献します。メソッドの引数は、2種類に大別できます。オペランド引数 操作対象であるオブジェクトを表す。オプション引数 操作のモードを表す。このうち、メソッドの引数には「オペランド」のみを入れるようにします。「オプション」は、メソッド呼び出しの中で設定するのではなく、クラスにデフォルト値を持った上で、setter用意して別途指定できるようにします。たとえば？印刷機能を考えます。典型的な印刷メソッドは以下のようなものです。 class Printer def print(printer_name, paper_size, colo
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向エクササイズのススメ
とある掲示板で「条件分岐は悪」という発言を見かけたのですが実際どうなんでしょうか？
Amazon.co.jp: ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション: ThoughtWorks Inc. (著), 株式会社オージス総研オブジェクトの広場編集部 (翻訳): 本
おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ
