SLAP原則
Single Level of Abstraction Principle
直訳して単一レベルの抽象化原則
DRYを突き詰めるあまりに、処理の抽象度が揃っていないのは避ける @sonatard: コードとしての複雑さがあるときにトップダウンで分割すると、本質的な難しさは解決せず隠蔽されているだけのことが多いように思う ボトムアップでシンプルにする方法を模索したい
@sonatard: そうするとボトムにシンプルなパーツが揃うので、それを利用している限り最上位からみてもシンプルな状態にできる トップダウンの分割は、ユースケースごとに常にトップダウンの分割を考えなければいけない状態が継続する
@shibu_jp: あと、C++でもJavaScriptでも関数10行、クラス100行で済んでた、と書いてあるけど、動きとかUI定義とかすると一瞬で100行の関数とか1000行のクラスになったりするし、かといって分けるとどこに何があるのかわからなくなったりするよね。まあそういうのは無理に分けなくてもいいよね、とは思う。 見えるべきものが下に隠蔽されて、コードの詳細を追わないと全体像がわからないコードになる
責務や状態の関心が同じであれば多少大きくても良い
処理の抽象度や水準の意識がとても大事
プログラムを高水準、中水準、低水準に分けて考える
水準が同じ処理を１まとめにして関数化し、その関数をより上の水準の関数から呼び出すような階層構造にすることで、全体の動きが俯瞰しやすくなる
高水準なコードとは
オブジェクト指向言語であれば、Publicで外部公開されたメソッド
例えば、ボタンをクリックした時にコールされる関数やメソッド等
ユーザー側、外部向けのコードというイメージ
中水準
ミドルウェア的な、共通処理
低水準
オブジェクト指向言語であれば、Privateで非公開のメソッド
実際の処理(ロジック)、計算式、APIの利用やファイルの読み書き、インターフェース等
より内部的なコードというイメージ
@little_hand_s: 個人的にはリスコフなんかよりも「SLA原則(Single Level of Abstraction Principle、SLAPとも呼ぶ)」の方が大事だと思っている。 あるオブジェクトの記述は同じレベルの抽象度のコードだけ書くようにすると、圧倒的に理解容易性が高くなる。