SwiftとKotlinの構文比較 (2) 〜クラス、列挙体、構造体、プロトコル、拡張 - Qiita
class NamedShape { var numberOfSides: Int = 0 var name: String init(name: String) { self.name = name } func simpleDescription() -> String { return "A shape with \(numberOfSides) sides." } } class NamedShape(name: String) { var numberOfSides: Int = 0 var name: String = "" init { this.name = name } fun simpleDescription() : String { return "A shape with ${numberOfSides} sides." } } class Square: Nam
オブジェクト指向設計原則とは - Qiita
はじめに オブジェクト指向の設計原則を説明します 勉強内容のアウトプットです 単一責任の原則 単一責任の原則は非常にシンプルな内容で、「1つのクラスに1つの役割(機能)」と言うものです。 これはカプセル化で強く言われる「小さなカプセル」ということに通じます。 ただ、この「1つのクラスに1つの役割」という考え方は正しいのですが、コレを正確に運用するのは非常に難しいです。運用が難しいというのは「1つのクラスに1つの役割」という言葉を指針としてしまうと思わぬ間違いを生むということです（言葉自体は正しいが、人間はアホなので間違っちゃうのです） そこで、クラスの妥当性をチェックするために別の角度から眺める必要が出てきます。この時の言葉が 「クラスを変更する理由が2つ以上存在してはならない」 という言葉です。この言葉は単一責任の原則の話で重要となる言葉ですので、覚えておいてください。 さて、あなたはあ
オブジェクト指向設計 getter, setterを使うなとはどういうことか - Qiita
趣旨 今回は、とかく誤解されたままになりがちなこのテーマについて自分の中での整理も兼ねて書いていきます 内容は特定の言語に限定されるものではありませんが、コード例はJavaで書いています。他の言語をお使いの方は適宜読み替えながら読んでいただければ幸いです 入門書は間違ったことを教えている？ 皆さんはどのような本でオブジェクト指向プログラミング言語を勉強しましたか？多くの方は例えば「やさしい～」や「たのしい～」のような入門書から入ったのではないでしょうか（中にはいきなり分厚い言語仕様から入る剛の者も居るようですが） その中で必ずと言っていいほど書かれているワードがあります フィールドはprivateにし、その値の書き換えや読み取りにはgetterやsetterを用意しましょう。これによってカプセル化が維持されます さて一方でコミュニティなどでは次のように言われることがあります getterや
オブジェクト指向歴25年のオブジェクト指向おじさんが語るオブジェクト指向設計の処方箋 - Qiita
この記事のターゲット この記事は以下の人々を対象としています。 オブジェクト指向を一通りわかっている人。 オブジェクト指向の設計力を高めたい人。 オブジェクト指向を使っているのに、設計が綺麗にならず悩んでいる人。 プログラムが大きくなるとオブジェクト指向設計が破綻する人。 オブジェクト指向に限界を感じている人。 共同開発メンバーの設計力に差があって困っている人。 以下の人は対象外です。 オブジェクト指向が何なのかわからない人。 オブジェクト指向を極めている人。 関数型など別のパラダイムに活路を既に見いだしている人。 オブジェクトは責任ベースで考える オブジェクト指向といえば、やれインターフェイスだメッセージだ隠蔽だカプセル化だ、みたいな用語がたくさん出て来て、どれも関連があるようでないようで意味が分からないですよね。気取ったこと言ってんじゃねぇよと。 日本で社会人経験があれば、こんなものは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
