추상화가 얼마나 많은가?

추상화가 얼마나 많은가?

---

객체 지향 프로그램에서 : 추상화가 얼마나 많은가? 얼마가 맞습니까?

나는 항상 멍청한 사람이었습니다. 나는 높은 수준의 캡슐화와 추상화의 개념을 이해했지만, 너무 많이 추가하면 프로그램을 혼란스럽게 할 뿐이라고 본능적으로 느꼈습니다.

저는 항상 빈 클래스 나 레이어를 남기지 않는 추상화를 위해 노력했습니다. 그리고 확실하지 않은 경우 계층에 새 레이어를 추가하는 대신 기존 레이어에 무언가를 추가하려고합니다.

그러나 최근에는 좀 더 고도로 추상화 된 시스템을 접하고 있습니다. 나중에 계층 구조에서 표현이 필요할 수있는 모든 것이 하나의 시스템 앞에 표시되는 시스템입니다. 이것은 처음에는 나쁜 디자인처럼 보이는 많은 빈 레이어로 이어집니다. 그러나 두 번째 생각으로 빈 레이어를 남겨두면 많은 리팩토링없이 미래에 더 많은 위치를 찾을 수 있다는 것을 깨달았습니다. 이전 버전을 조정하기 위해 많은 작업을 수행하지 않고도 이전 버전 위에 새로운 기능을 추가 할 수있는 더 큰 기능을 제공합니다.

이것의 두 가지 위험은 필요한 레이어를 잘못 얻을 수 있다는 것입니다. 이 경우 코드를 확장하기 위해 상당한 리팩토링을 수행해야하며 아직 사용하지 않은 수많은 레이어가 있어야합니다. 그러나 초기 추상화를 만드는 데 얼마나 많은 시간을 소비하는지, 그것을 망칠 가능성, 그리고 당신이 올바르게 할 경우 나중에 절약 할 수있는 시간에 따라-여전히 시도해 볼 가치가있을 수 있습니다.

제가 생각할 수있는 또 다른 위험은 과도하게 수행하고 모든 추가 레이어가 필요하지 않을 위험입니다. 하지만 정말 그렇게 나쁜가요? 추가 클래스 레이어가 정말 너무 비싸서 사용하지 않으면 손실이 큽니까? 여기에서 가장 큰 비용과 손실은 레이어로 인해 발생하는 시간 손실입니다. 하지만 나중에 더 낮은 수준의 코드가 아닌 추상화 된 코드로 작업 할 수있을 때 그 시간의 대부분을 절약 할 수 있습니다.

그래서 언제 너무 많습니까? 빈 레이어와 추가 "필요할 수있는"추상화가 과도하게되는 시점은 언제입니까? 너무 적은 것이 얼마나 되는가? 스위트 스팟은 어디입니까?

경력 과정에서 필요한 추상화의 양을 판단하는 데 도움이되는 신뢰할 수있는 경험 규칙이 있습니까?

---

그래서 언제 너무 많습니까? 빈 레이어와 추가 "필요할 수있는"추상화가 과도하게되는 시점은 언제입니까? 너무 적은 것이 얼마나 되는가? 스위트 스팟은 어디입니까?

이 질문에 대한 확실한 답은 없다고 생각합니다. "너무 많음"과 "너무 적음"에 대한 느낌을 개발하려면 경험이 필요합니다. 일부 메트릭 또는 품질 관리 도구를 사용하면 도움이 될 수 있지만 일반화하기는 어렵습니다. 대부분 각 경우에 따라 다릅니다.

다음은 답변을 찾는 데 영감을 줄 수있는 몇 가지 링크입니다.

• 당신은 그것을 필요로하지 않을 것입니다
• 사용 / 재사용 역설
• 프로젝트 삼각형 : 좋고, 빠르고, 저렴
• 컴퓨터 과학의 모든 문제는 다른 수준의 간접적 인 방법으로 해결할 수 있습니다 (David Wheeler).

개발은 소프트웨어 엔지니어링 노력에 존재하는 다양한 긴장 사이에서 올바른 균형을 찾는 것입니다.

---

추상화의 요점은하는 것입니다 밖으로 요인 수학적 연산처럼, 특정 것들에서 공통 속성 :

ab + ac => a(b + c)

이제 세 번이 아닌 두 번의 작업으로 동일한 작업을 수행합니다. 이 인수 분해로 표현이 더 간단 해졌습니다.

추상화의 전형적인 예는 파일 시스템입니다. 예를 들어, 프로그램이 펜 드라이브, SD 카드, 하드 드라이브 등 여러 종류의 저장 장치에 쓸 수 있기를 원합니다.

파일 시스템이 없다면 직접 디스크 쓰기 로직, 펜 드라이브 쓰기 로직 및 SD 카드 쓰기 로직을 ​​구현해야합니다. 그러나 이러한 모든 로직에는 공통점이 있습니다. 파일과 디렉토리를 생성하므로 추상화 계층을 생성하고 하드웨어 공급 업체에 특정 작업을 수행 할 수있는 인터페이스를 제공하여 이러한 공통적 인 사항을 추상화 할 수 있습니다.

사물이 공유하는 속성이 많을수록 추상화는 다음과 같은 이점이 있습니다.

ab + ac + ad + ae + af

에:

a(b + c + d + e + f)

그러면 9 개의 작업이 5 개로 줄어 듭니다.

기본적으로 각각의 좋은 추상화는 시스템의 복잡성을 대략 절반으로 줄입니다.

추상화를 유용하게 만들려면 항상 공통 속성을 공유하는 최소한 두 가지가 필요합니다. 물론 당신은 추상화처럼 보이도록 하나의 것을 떼어 내지 만 그것이 유용하다는 것을 의미하지는 않습니다.

10 => 5 * 2

엔티티가 하나만있는 경우 "공통"이라는 단어를 정의 할 수 없습니다.

그래서 당신의 질문에 대답하십시오. 시스템을 가능한 한 간단하게 만드는 경우 충분한 추상화가 있습니다.

(제 예에서 덧셈은 시스템의 일부를 연결하는 반면 곱셈은 추상-구체적 관계를 정의합니다.)

---

너무 적은 것이 얼마나 되는가?

일상적으로 "낮은 수준"요소로 작업을 계속하고 계속해서 그렇게하고 싶지 않다고 느낄 때. 그들을 추상화하십시오.

그래서 언제 너무 많습니까?

When you can't make bits and pieces of some code parts on a regular basis and have to debug them down to the previous layer. You feel this particular layer does not contribute anything, just an obstacle. Drop it.

Where's the sweet spot?

I like to apply the pragmatic approach. If you see a need for an abstraction and understand how it will improve your life, go for it. If you've heard there should be "officially" an extra layer of abstraction but you're not clear why, don't do it but research first. If somebody insists on abstracting something but cannot clearly explain what if will bring, tell them to go away.

---

In theory, it should be a matter of simple math using only three (fairly simple) variables:

• S = savings from use
• C = cost of the extra abstractions
• P = probability of use

If S * P > C , then the code is good. If S * P < C, then it's bad.

The reason that's purely theoretical, however, is that you generally can't guess at the probability of use or the savings you'll get from using it. Worse, you can't guess or or usually even measure the cost of its presence.

At least some people have drawn a conclusion from this. In TDD, the standard mantra is "you ain't gonna need it" (YAGNI). Simply put, anything that doesn't directly contribute toward the code meeting its current requirements is considered a bad thing. In essence, they've concluded that the probability of use is so low, that including such extra code is never justified.

Some of this comes back to "bottom up" versus "top down" development. I tend to think of bottom up development as "library development" -- I.e. instead of developing a specific application, you're really developing libraries for the kinds of things you'll need in the application. The thinking is that with a good enough library, you can develop almost any application of that general type relatively easily.

Quite a bit also depends on the size of the project. Huge projects that stay in use for decades justify a lot more long-term investment than smaller projects that are discarded and replaced much more quickly. This has obvious analogs in real life as well. You don't worry nearly as much about the fit, finish, or workmanship in a disposable razor you'll throw away in less than a week as you do in something like a new car that you'll be using for the next few years.

---

Simply put, there is too much abstraction if the code is difficult to understand.

Now this isn't to say that you should hard code everything, because that's the easiest code to write and read.

The easiest test is to either put it down for a few days, pick it back up and ask yourself, does this make any sense. A better approach is to give it to someone else, and see if they can make heads or tails of it.

---

The reality is that it depends on how well you can look into the future. You want to plan for changes you can foresee without creating too many extra layers. If you have a design that transfers data between systems, go ahead and create an interface and use the planned implementation as the default. For example, you use FTP to move files around but know the standard will be message-based (or whatever) next year.

As for layers within the design, sometimes the added layers make it easier to write smaller classes. It's ok to add conceptual layers if it means the concrete classes become straight forward.

---

Every abstraction that is not actually used is too much. The simpler a system, the easier it is to change. Abstraction layers nearly always make systems more complicated.

OTOH, it's certainly possible to program a complex, unmaintainable mess without any kind of abstraction, and sometimes, "standardized" abstraction layers can help structure a system better than most people would be able to do on their own.

---

See item (6a) of RFC 1925 and know that it is indeed true. The only problems you can't fix by adding abstraction layers are those caused by having too many abstraction layers. (In particular, every piece of abstraction makes the whole thing harder to understand.)

참고URL : https://stackoverflow.com/questions/2668355/how-much-abstraction-is-too-much