간단해진 깨끗한 코드 - 2부
#6 데이터 숨기기
아래 코드 스니펫 중 어느 것이 더 잘 설계되었다고 생각하십니까?
1)
interface Vehicle {
public function getFuelTankCapacityInGallons();
public function getGallonsOfGasoline();
}
2)
interface Vehicle {
public function getPercentFuelRemaining();
}
위의 두 경우 모두 두 번째 옵션이 바람직합니다. 우리는 가능한 한 데이터의 세부 사항을 노출하고 싶지 않습니다. 오히려 우리는 데이터를 추상적인 용어로 표현하기를 원합니다. 개체에 포함된 데이터를 가장 잘 나타내는 방법에 대해 진지하게 생각해야 합니다. 최악의 옵션은 게터와 세터를 부주의하게 추가하는 것입니다.
따라서 개체의 데이터를 숨기기에 적합한 모든 상황에서 수행할 수 있습니다.
#7 단순한 디자인 규칙
Kent Beck은 프로그램을 더 잘 설계하기 위한 기본 기준으로 다음 4가지 규칙을 도입했습니다.
클래스와 메서드를 작게 만들려는 노력의 일환으로 작은 클래스와 메서드를 너무 많이 만들 수 있습니다. 또한 함수와 클래스 수를 낮게 유지해야 합니다. 이것은 다른 것보다 더 중요한 켄트의 단순한 디자인 규칙의 네 번째 규칙입니다.
#8 의도를 드러내는 기능
이 코드 스니펫이 어떻게 개선될 수 있다고 생각하십니까?
public function getFlaggedCells() {
$flaggedCells = new List();
foreach ($cells as $cell) {
if ($cell[STATUS_VALUE] == 1) {
$flaggedCells->add($cell);
}
}
return $flaggedCells;
}
의도를 드러내는 함수(isFlagged라고 함)를 작성하여 매직 넘버를 숨길 수 있습니다. 함수의 새 버전이 생성됩니다.
public function getFlaggedCells() {
$flaggedCells = new List();
foreach ($cells as $cell) {
if ($cell->isFlagged())
$flaggedCells->add($cell);
return $flaggedCells;
}
#9 테스트 작성은 더 나은 설계로 이어집니다.
Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed. Fortunately, making our systems testable pushes us toward a design where our classes are small and single purpose. Writing tests leads to better designs.
#10 관심사 분리
건설과 사용을 분리하기 위해 화살표의 방향은 무엇이어야 합니까?
Main Application
Builder
방향은 다음과 같아야 합니다.
run
Main ---------> Application
|
| build and construct
\|/
Builder
이는 단순히 응용 프로그램의 구성과 사용이 분리되어야 함을 의미합니다. 이 두 단계는 근본적으로 분리되어 있으며 이를 분리하면 더 나은 디자인과 구조를 얻을 수 있습니다.
괜찮아. 이 부분에 대한 내용입니다. 내Telegram 채널에 가입하면 최신 게시물에 대한 알림을 받을 수 있습니다. 또한 및 에서 나를 팔로우할 수 있습니다.
Reference
이 문제에 관하여(간단해진 깨끗한 코드 - 2부), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/mehradsadeghi/clean-code-made-simple-part-2-l53텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)