Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Symfonyと抽象クラス
Search
matsu_hide
August 07, 2019
Programming
1
300
Symfonyと抽象クラス
matsu_hide
August 07, 2019
Tweet
Share
Other Decks in Programming
See All in Programming
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
110
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
660
datadog dash 2025 LLM observability for reliability and stability
ivry_presentationmaterials
0
190
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
2
290
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
620
NPOでのDevinの活用
codeforeveryone
0
450
Benchmark
sysong
0
270
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
1
710
童醫院敏捷轉型的實踐經驗
cclai999
0
200
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
440
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
330
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
1.1k
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Designing Experiences People Love
moore
142
24k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Producing Creativity
orderedlist
PRO
346
40k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Balancing Empowerment & Direction
lara
1
380
Testing 201, or: Great Expectations
jmmastey
42
7.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Designing for humans not robots
tammielis
253
25k
Transcript
Symfonyと 抽象クラス Symfony Meetup Kansai #2 松藤 秀治 (2019-08-07)
自己紹介 • 松藤 秀治(まつふじ ひではる) • matsu_hide • フリーエンジニア • Symfonyをよく使う
抽象クラスとは?
特定の視点から対象を見たときに 導き出される型と振る舞い (自説)
抽象クラス 実装寄り → インスタンスとかテンプレートメソッドとか 設計寄り → 抽象とか 今日は設計寄りの話です。
抽象クラスは悪者? ・確かに共通処理をくくりだすという理由だけで使うと失敗しや すい。 ・でもうまくいっている例もあるはず。 ・一体何が違うんだろう?
[Symfonyでの使用例1] フォームタイプ
[Symfonyでの使用例2] バリデーター(制約)
[Symfonyでの使用例3] ダンプ
どうしてSymfony(フレームワーク)では 使われているのか?
AbstractType → フォームの要素をどう扱うか? Constraint → Nullや文字数の制約をどう扱うか? AbstractDumper → オブジェクトなどをどう出力するか? 解決したい問題に着目(特定の視点)
そうは言ってもフレームワーク は特別でしょう?
・ソフトウェアで問題を解決するという点でフレームワークも自分 が作るものも同じ。 ・それならフレームワークで使われている技術は自分が作るとき も有用なはず。 ・自分が作るものをフレームワークにするとしたら?という視点。
まとめ • 解決したい問題に焦点をあて、必要であれば抽象クラスを 使う。(再利用される頻度と複雑さのバランスは大事。) • 自分が作るものをフレームワークにするとしたら?という 視点は大事。 • 抽象クラスだけでなくさまざまな技術は問題を解決する(捉 える)ためにある。