ふつうのプログラマのふつうの設計普通のプログラマの普通の設計 2022-01-26 本編（雑談）の前振りスライドです。 https://modeling-how-to-learn.connpass.com/event/231669/
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
ソフトウェア開発における 「設計」と「パフォーマンス」の相互作用 / Interaction Between Design and Performance on
Software Development - Speaker Deck
設計Night2018の資料です https://connpass.com/event/104821/
DynamoDBデータモデリング虎の巻：第弐巻 〜考え方編〜 - misc.tech.notes
前巻のおさらい 前巻はDynamoDBのデータモデリングをする前に知っておいた方が良いDynamoDB自体の仕組みやデータ構造のお話でした。 marcy.hatenablog.com 今回は 今回はデータモデリングを行う際に必要なマインドセット、つまり「考え方」について書き記したいと思います。非常によく聞かれる「RDBとの考え方の違い」といった切り口で進めていきたいと思います。 RDBとはアプローチが真逆 RDBのデータモデリングをする場合、まず正規化されたデータのスキーマを決めることから始めると思います。慣れてくると律儀に第一正規化から始めずにいきなり第三正規形あたりから設計しだすことも多いと思います（私もそうです） そして、データのスキーマが決まってからそれに対してどのようにアクセスするか（＝SQL）をアプリケーションを設計する際に考えていくというのがRDBでの一般的なアプローチではな
DynamoDBデータモデリング虎の巻：第壱巻 〜前提知識編〜 - misc.tech.notes
動機など 最近、Serverlessの文脈からDynamoDBのテーブル設計の相談を受けることが多くなってきていて、Podcastでも話したけどけっこう図とかが無いと説明しづらい領域なので、まとまった資料がほしいなということでまとめてみる。 cloudinfra.audio どう考えても長編大作エントリ不可避なので気力が続けば第二巻以降に続きます…！（フィードバックが多いと頑張れるかも…！） 本巻の対象と前提知識 本巻はDynamoDBのデータモデリングにスコープを絞っています。DynamoDBおよびデータベースの一般用語などについての説明は省きます。 前提知識としては以下のようなものになるかと思います。 DynamoDBのサービスとしての概要や用語( WCU , RCU , GSI , LSI など)を知っている Hash TableやB-Tree(B+Tree)といったデータ構造がどん
Javaのgetter,setterメソッドは（特に）GUI部品のための規格だった話
こんな記事があった。 「 getter/setterとはなんだったのか」- プログラマーの脳みそ JavaBeansはGUIなどで再利用可能なコンポーネントを提供する際の規格のようなもので(僕もあまり詳しくない)2000年ぐらいにGUIのコンポーネントを作るときに意識したような、どうでもよかったような、イマイチ恩恵が実感できなかった代物だった JBuilder2とか3の頃のJava開発といえば、AWTやSwingといったGUIアプリケーションを作ることがまだ当たり前だった時代。「部品」といえば、GUI部品のことを指していました。GUI部品といえば、ペタペタツールの存在を忘れてはなりません。当時のJava IDEは、こぞってVisual Basicの開発環境に追いつけ追い越せという状況だったんです。 それらのIDEが目指したもの、それは「コーディングなしでGUI画面を作れるようにすること」で
結局のところgetter／setterは要るのか？要らないのか？ - Qiita
Javaを勉強するに当たって表題通りの疑問が湧いたので、色々と調べました。 getter／setterが必要とされる理由に関しては各所で散々解説されているので、"不要派"の意見を重点的にまとめています。 まずオブジェクト指向プログラミングの定石 フィールド＝private、メソッド＝public フィールドを操作するためにgetterメソッドとsetterメソッドを用意する ＝ カプセル化である。 カプセル化が好まれる理由 メンバ変数のアクセス制御ができるようになる クラス内部のデータ表現を変えた場合でも呼び出し側のコードを変更する必要がない メンバ変数の参照や変更を追跡することができる 値の正当性チェックを入れることができる オブジェクト指向とはそういうものである。 オブジェクト指向プログラムでgetter/setterメソッドを使わなければならない10の理由 プロパティについて C#や
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
Where is the mate to the Sock? — Where is the mate to the Sock? ドキュメント
Where is the mate to the Sock?¶ March 20, 2023 Setting Up Haskell (日本語)¶ Haskell is a powerful programming language that has undergone many changes over the year. If you are looking to set up Haskell for the first time or revisit it after a long break, there are two popular ways to do so: stack and GHCup. I will explore both options and recommend a suitable approach. Before stack¶ ghc is the popul
クラスの「継承」より「合成」がよい理由とは？ゲーム開発におけるコードのフレキシビリティと可読性の向上 | POSTD
コード構造における重要な問題として、複数のクラスを共有する場合に合成と継承のどちらを用いるかという点があります。“has a”の関係と、“is a”の関係と言われる2つの対比です。例えば、“ソファには綿が入っている”と、“ソファは家具である”という違いのようなものです。この例では2つの違いは非常に明白ですが、実際には、“has a”の関係でも“is a”の関係でも意味を成すケースがたくさんあります。ゲームのキャラクターについて、これはコリジョンボックスを持っているかと聞くのと、これは衝突可能なオブジェクトかと聞くような場合です。この2つは全く同じことではありませんが、それぞれが（または両方一緒に）衝突を処理する主構造として用いられ、どちらの方がよいかは必ずしも明白ではありません。私の経験では、直感的には継承の方がよいと思うことも多いのですが、それだと問題がたくさんあって結局は合成の方がよか
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
オブジェクト指向設計の原則 - それはBooks
「アジャイルソフトウェア開発の奥義」を読んで第二弾。オブジェクト指向設計の原則に関するメモです。自分で読んで思い出せるくらいの内容しかメモってないと思われるので、もっと詳しい解説が欲しければ本書を買ってください。 本書には、クラス設計の原則として5つの原則が載っています。 単一責任の原則 (The Single Responsibility Principle: SRP) オープン・クローズドの原則 (The Open-ClosedPrinciple: OCP) Liskovの置換原則 (The Liskov Substitution Principle: LSP) 依存関係逆転の原則 (The Dependency Inversion Principle: DIP) インターフェース分離の原則 (The Interface Segregation Principle: ISP) パッケー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The mind of Serverless as a Software - Serverlessの世界に特別なことなんて何もなかった - slideship.com
DynamoDB を使用した設計とアーキテクチャの設計に関するベストプラクティス - Amazon DynamoDB
https://ubiteku.oinker.me/2016/03/22/tdd%E5%86%8D%E8%80%83-8-%E5%87%9D%E9%9B%86%E6%80%A7%EF%BC%88cohesion%EF%BC%89%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%AA%E3%81%AE%E3%81%8B%EF%BC%9F/
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
オブジェクト指向とは何だったのか？ – ゆびてく
