< 자동속성(Auto-Implemented Properties) >

클래스 내에 데이터 필드를 선언하고 이를 접근하기 위한 메서드를 작성하는 것은 매우 일반적인 일이다. 이렇게 필드에 대한 접근 제어를 하기 위해 getter와 setter를 사용한다. 이렇게 필드와 이를 제어하는 메서드를 함께 묶어 속성(Property)이라 부른다.

public class Coffee
{
    private string _name;  // 필드

    public string Name    // 속성
    {
        get { return _name; }  // getter
        set { _name = value; } // setter
    }
}

 

그러나 이와 같은 방식은 코드의 중복성을 증가시키고 가독성을 낮추는 문제가 있다. 그래서 이를 해결하기 위해 자동속성(Auto-Implemented Properties)이라는 개념을 도입했다.

public class Coffee
{
    public string Name { get; set; }
}

 

자동속성을 사용하면 필드는 컴파일러에 의해 자동으로 생성되며, getter와 setter 메서드도 자동으로 생성된다. 이는 코드의 중복성을 줄이고 가독성을 높여 준다.

자동속성은 특히 데이터 전송 객체(Data Transfer Object, DTO)나 데이터 모델 클래스 등의 작성에 주로 사용된다. 이들 클래스는 데이터를 저장하고 전달하는 역할을 하는데, 이때 개별 필드에 대해 별도의 로직 없이 단순히 데이터를 저장하거나 반환하는 작업이 주로 이루어지기 때문에 자동속성을 사용하면 매우 효율적이다.

[주의사항]
자동속성은 필드에 대해 별도의 로직이 없을 때 사용하는 것이 좋다. 필드의 값을 가져오거나 설정하는 과정에서 별도의 검증 로직이나 계산이 필요한 경우에는 일반 속성을 사용하는 것이 좋다.
자동속성은 기본적으로 public으로 선언되지만, 필요에 따라 접근 제어자를 변경할 수 있다. 하지만 get과 set에 대해 별도의 접근 제어자를 지정할 수도 있으니 이 점을 주의해야 한다. 예를 들어, 다음과 같이 속성을 선언할 수 있다.

public class Coffee
{
    public string Name { get; private set; }  // 외부에서는 읽기만 가능하고, 클래스 내에서만 값 설정 가능
}

 

< 가상속성(Virtual Properties) >

가상속성은 상속받은 클래스에서 재정의(Override)할 수 있는 속성이다. 이는 다형성(Polymorphism)의 한 형태로, 같은 이름의 속성이지만 각각의 클래스에서 다른 동작을 수행하도록 하는 것이 가능해진다.

public class Vehicle
{
    public virtual string Name { get; set; } = "Vehicle";
}

public class Car : Vehicle
{
    public override string Name { get; set; } = "Car";
}

 

이 경우, Vehicle 객체의 Name 속성은 "Vehicle"을 반환하고, Car 객체의 Name 속성은 "Car"을 반환한다. 가상속성은 이와 같이 상위 클래스에서 정의한 속성을 하위 클래스에서 필요에 따라 다르게 동작하도록 할 때 사용한다.

[주의사항]
하위 클래스에서 속성을 재정의할 때는 반드시 override 키워드를 사용해야 한다.
virtual 키워드를 사용하면 해당 속성이나 메서드는 재정의될 수 있음을 의미한다. 따라서 virtual 키워드를 사용할 때는 하위 클래스에서 이를 재정의할 가능성을 염두에 두고 설계해야 한다.
virtual 키워드를 사용할 경우, 실행 시간에 적절한 메서드나 속성이 호출되기 때문에 약간의 성능 손실이 발생할 수 있다. 따라서 성능이 중요한 상황에서는 이를 고려해야 한다.

차의 운전석에 앉아, 차를 운전할 때, 만약 핸들을 돌린 방향과 차량이 반대 방향으로 움직인다면 어떻게 될까? 위험하고 혼란스러울 것이다. 이처럼, 행동과 그 결과가 일관되게 반응하는 것이 중요한데
이와 비슷하게, 사용자 인터페이스(UI)를 다룰 때 우리는 UI 요소와 데이터 간의 일관성을 유지하려고 노력한다. 여기서 C#의 DataBindings 속성이 활용되는데, 이것은 UI 컴포넌트와 데이터 소스를 "연결"해주는 역할을 한다.

< 데이터 바인딩이란 무엇인가? >

"데이터 바인딩(Data Binding)"이란 이름에서 알 수 있듯이, 데이터와 어떤 요소를 '연결'하는 것이다. 사용자 인터페이스 요소 (예: 텍스트 박스)와 데이터 소스(예: 객체의 속성) 간에 '연결고리'를 만들어준다. 이로 인해 데이터가 변경될 때 UI가 자동으로 업데이트되고, 반대로 UI에서 사용자가 변경을 가하면 데이터 소스에도 반영된다.

왜 데이터 바인딩을 사용할까?

[일관성 유지]
데이터 바인딩의 가장 큰 장점 중 하나는 UI와 데이터 사이의 일관성을 유지할 수 있다는 것이다. 예를 들어, 데이터의 값이 변경되면 UI에 해당 변경이 자동으로 반영되어 사용자가 최신 상태를 보게 된다.

[코드 양 감소]
데이터 바인딩을 사용하면 UI 업데이트를 위한 코드를 수동으로 작성할 필요가 없어진다. 데이터의 변경을 감지하고 UI를 적절하게 업데이트하는 것을 프레임워크가 알아서 처리해준다.

[유지보수 용이]
데이터 바인딩은 모델과 뷰 간의 강력한 결합을 준다. 따라서 코드의 유지보수가 더 쉬워지고, 각 부분을 독립적으로 테스트하거나 변경하는 것이 용이해진다.



언제 데이터 바인딩을 사용하는가?


UI에서 표시하는 데이터가 자주 변경되거나, 사용자의 입력을 통해 데이터가 변경되는 경우 데이터 바인딩을 사용하면 매우 효율적이다. 또한, 복잡한 사용자 인터페이스를 가지고 있고 그 인터페이스가 다양한 데이터 소스와 상호작용하는 경우에도 유용하다.

textBoxCity.DataBindings.Add("Text", address, nameof(City));

 

여기서 textBoxCity는 사용자가 도시 이름을 입력할 수 있는 텍스트 박스다. address는 주소 정보를 담고 있는 객체이고, City는 그 중 도시 이름을 나타내는 속성이다.

이 코드를 통해 텍스트 박스의 'Text' 속성과 address 객체의 'City' 속성이 연결된다. 이제 사용자가 텍스트 박스에 도시 이름을 입력하면 address 객체의 'City' 속성이 자동으로 업데이트된다. 반대로, address 객체의 'City' 속성이 프로그램에 의해 변경되면 그 변경 사항이 텍스트 박스에 자동으로 반영된다.

 

 

Address.cs를 아래와 같이 만들고 

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace WindowsFormsApp2
{
    public class Address : INotifyPropertyChanged
    {
        private string city;

        public event PropertyChangedEventHandler PropertyChanged;

        public string City
        {
            get { return city; }
            set
            
            {
                if (city != value)
                {
                    city = value;
                    PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(City)));
                }
            }
        }
    }
}

아래와 같이 Form1 코드를 작성한다 여기서 TextBox는 도구 툴에서 만들어도 된다. 

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsApp2
{
    public partial class Form1 : Form
    {
        private Address address;

        // textBoxCity를 선언
        private TextBox textBoxCity = new TextBox();

        public Form1()
        {
            InitializeComponent();

            // Address 객체를 생성하고 초기 도시를 '서울'로 설정
            address = new Address() { City = "서울" };

            // textBoxCity의 Text 속성을 address 객체의 City 속성에 바인딩
            textBoxCity.DataBindings.Add("Text", address, nameof(Address.City), false, DataSourceUpdateMode.OnPropertyChanged);

            // textBoxCity를 폼에 추가 가능 .
            this.Controls.Add(textBoxCity);
        }
        private void Form1_Load(object sender, EventArgs e)
        {

        }
    }
   
}

초기값 서울
여기선 울산인데 울산1로 변경해보았다.

 

setValue값이 바인딩 된 값이 즉시 반영되는 것을 확인할 수 있다.

20230627(화) 울산 맑은샘 헬스

  • 인클라인 트레드밀 5분 (웜업)
  • 레그 컬 40KG 3SET
  • 레그 프레스 60KG 5SET
  • 레그 익스텐션 80KG 5SET
  • 트레드밀 20분 

'건강운동관리' 카테고리의 다른 글

헬스  (0) 2023.06.28
헬스  (0) 2023.06.22
헬스  (0) 2023.06.21
헬스  (0) 2023.06.20
헬스  (0) 2023.06.19

< 작게 만들자 > 

함수를 만들 때 가장 중요한 규칙은 크기다. “작게 만들어야 한다”는 것이다. 더 작다면 더 좋다. 요리 초보자가, 특별한 재료를 사용하는 50단계 요리보다, 간단한 재료로 만드는 5단계 요리를 만들어 보고 싶을 것이다. 마찬가지로, 함수도 단계가 적을수록 이해하기 쉽다.

public static String prepareDeliciousDish(Ingredients ingredients, boolean isVegan) {
    if (isGoodCombination(ingredients)) {
        mixIngredients(ingredients, isVegan);
    }
    return serveDish(ingredients);
}

< 간격을 일정하게 유지하자 >

요리할 때도 조리도구와 재료를 가까운 곳에 두는 것이 편리하듯이 코드도 마찬가지다. 만약 함수 안에 if, else 또는 while 같은 구문이 있다면, 그 안에 넣을 내용은 간단하게 한 줄 정도로 만들어보자. 그 한 줄에는 다른 함수를 호출하는 내용이 들어갈 수 있다. 이렇게 하면 더 읽기 쉬운 코드가 되고, 동시에 더 가까운 간격으로 구성된다.

< 함수 당 추상화 수준은 하나로 >

함수를 만들 때, 내부의 내용은 동일한 수준의 ‘추상화’를 가져야 한다. 한 그림에는 한 스타일로 그리는 것과 같다. 높은 수준의 개념과 세부적인 요소를 함께 섞으면, 누군가 그 그림을 볼 때 혼란스러울 것이다. 함수도 마찬가지로, 동일한 수준의 추상화를 유지하면 더 이해하기 쉽다.

< 위에서 아래로 읽혀야 한다 >

코드를 읽는 것은 마치 이야기를 읽는 것과 같아야 한다. 이야기를 읽을 때는 위에서 아래로 읽으며, 내용이 점점 풀어진다. 마찬가지로 코드도 그렇게 작성되면 좋다. 함수의 추상화 수준이 한 단계씩 점점 낮아지는 방향으로 코드를 작성하면 더 이해하기 쉽다.

쉽게 말해서, 먼저 개요를 읽고, 그다음에 세부사항을 읽는 방식이다. 이를 '내려가기 규칙'이라고 부른다.

< 스위치문 > 

스위치문은 여러 가지 경우의 수를 한 번에 처리할 수 있어 매우 유용하나, 잘못 사용하면 너무 복잡해질 수 있다. 예를 들어, 회사에서 직원들의 급여를 계산하는데 스위치문을 사용한다고 생각해 보자.

public Money calculatePay(Employee e)
throws InvalidEmployeeType {
    switch (e.type) {
    case COMMISSIONED:
        return calculateCommissionedPay(e);
    case HOURLY:
        return calculateHourlyPay(e);
    case SALARIED:
        return calculateSalariedPay(e);
    default:
        throw new InvalidEmployeeType(e.type);
    }
}


이 코드는 직원의 유형에 따라 다른 급여 계산 방식을 적용하는데, 새로운 직원 유형이 추가될 때마다 이 스위치문도 업데이트해야 하는 단점이 있다.  이 Switch문을 사용하면 복잡도가 급격히 늘어나는 문제가 있다.

[다형성]

이 문제를 해결할 수 있는 해결책이 있다. 그것은 바로 '다형성'을 이용하는 것이다. 다형성을 사용하면 하나의 코드로 다양한 경우를 처리할 수 있다.

"다형성"을 이용하면, 각 직원 유형마다 다른 계산 방식을 적용하는 클래스를 만들 수 있다. 그리고 이 클래스들을 'Employee'라는 공통 인터페이스를 통해 관리할 수 있다.

public abstract class Employee {
    public abstract boolean isPayday();
    public abstract Money calculatePay();
    public abstract void deliverPay(Money Pay);
}
public interface EmployeeFactory {
    public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}


이렇게 하면, 새로운 직원 유형이 추가되어도 스위치문을 업데이트할 필요가 없게 된다. 단지 새로운 클래스를 추가하기만 하면 된다. 

 

여기서 다형성이란? ↘

더보기

다형성(polymorphism)은 그리스어에서 유래한 말로, '많은(many)'와 '형태(shape)'의 합성어로서 '많은 형태를 가짐'을 의미한다. 컴퓨터 과학에서의 다형성은 한 가지의 인터페이스를 가지고 다양한 동작을 수행할 수 있는 능력을 뜻한다. 다시 말해, 한 가지 이름 아래에서 여러 가지 동작을 하는 것이다.

예를 들어, 동물원에 간다고 상상해 보자. 거기에는 사자, 원숭이, 펭귄 등 다양한 동물들이 있다. 이 동물들 모두 '동물'이라는 공통의 이름 아래에서 그들 각각의 동작(울음소리, 움직임 등)을 한다. 다형성이라는 마법은 바로 이것과 같다. 

[다형성을 이용한 코드]
앞에서 살펴본 직원 급여 계산 문제로 보자면. 여기서 각 직원 유형(COMMISSIONED, HOURLY, SALARIED)마다 다른 계산 방식을 적용해야 했다.

public abstract class Employee {
    public abstract boolean isPayday();
    public abstract Money calculatePay();
    public abstract void deliverPay(Money Pay);
}


먼저 'Employee'라는 공통 인터페이스를 만들고, 이 인터페이스에는 모든 직원이 가질 수 있는 메서드들을 정의한다. 이렇게 되면 각 직원 유형의 클래스는 이 'Employee' 인터페이스를 통해 서로 다른 급여 계산 방식을 구현할 수 있게 된다.

따라서 새로운 직원 유형이 추가되더라도 기존의 스위치문을 수정할 필요가 없게 된다. 단지 새로운 직원 유형 클래스를 만들어 'Employee' 인터페이스를 구현하기만 하면 되는 것이다.

이렇게 '다형성'이라는 것을 이용하면, 각 직원 유형마다 다른 계산 방식을 적용하는 동시에 코드의 복잡성을 크게 줄일 수 있다. 

< 숨겨야 가장 효과적 >

효과적으로 사용하려면, 스위치문을 숨겨야 한다. 이를 '추상 팩토리'라는 기법을 사용해서 가능하게 할 수 있다.

public class EmployeeFactoryImpl implements EmployeeFactory {
    public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
        switch (r.type) {
        case COMMISSIONED:
            return new CommissionedEmployee(r);
        case HOURLY:
            return new HourlyEmployee(r);
        case SALARIED:
            return new SalariedEmployee(r);
        default:
            throw new InvalidEmployeeType(r.type);
        }
    }
}


이렇게 스위치문을 팩토리 클래스 안에 숨겨두면, 다른 부분의 코드에서는 이 스위치문을 신경 쓸 필요가 없어진다. 

 

출처 : 출판사 인사이트북 / 클린 코드 / https://product.kyobobook.co.kr/detail/S000001032980

※저의 블로그에 있는 모든 참고 서적, 강의 내용은 출판사, 저자(혹은 편집자)에게 허락을 직접 맡고, 게시하는 글입니다.

 

Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고

Clean Code(클린 코드) | 프로그래머, 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가에게 추천하는더 나은 코드를 만드는 책『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의 동

product.kyobobook.co.kr

 

프로그래밍에서 가장 중요하면서도 자주 무시되는 요소 중 하나는 코드 내의 변수, 함수, 클래스의 이름이다. 적절한 이름은 코드의 가독성을 높이고 이해를 돕는다.

< 검색 가능한 이름 사용하기 >

코드에서 이름을 검색하는 것은 개발자의 일상 중 하나다. 그러나 너무 일반적인 이름이나, 너무 짧은 이름은 검색이 어렵게 만든다.

예를 들어, 7이라는 숫자를 상수로 사용했다고 가정해보자. 이 숫자를 찾으려면 수많은 파일과 수식에서 7이 사용된 모든 곳을 검색해야 한다. 동일한 이유로 'e'와 같은 일반적인 문자도 변수 이름으로 적합하지 않다.

그렇다면 어떤 이름이 검색하기 쉬울까? 바로 "길고 구체적인 이름"이다. 이런 이름을 사용하면 코드의 의미가 더욱 명확해지며, 해당 이름을 찾기도 훨씬 쉬워진다.

int realDaysPerIdealDay = 4;
const int WORK_DAYS_PER_WEEK = 5;
int sum = 0;

for (int j=0; j < NUMBER_OF_TASKS; j++) {
    int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
    int realTaskWeeks = (realTaskDays / WORK_DAYS_PER_WEEK);
    sum += realTaskWeeks;
}

 

위 코드에서는 sum이 유용하진 않지만 최소한 검색이 가능하다. 이름을 의미있게 지으면 함수가 길어지지만, realDaysPerIdealDay, WORK_DAYS_PER_WEEK와 같이 상세한 이름을 사용함으로 검색하기 쉽고, 코드가 무엇을 하는지 이해하기도 쉽다.

< 불필요한 인코딩 피하기 >

다음으로, 이름에 불필요한 인코딩을 포함시키지 않는 것이 중요하다. 이름에 인코딩을 넣으면 그만큼 이름을 이해하기 어려워지며, 이름을 바꾸는 것도 복잡해진다.

예를 들어, 'm_' 접두사를 붙이는 관습은 이제는 필요 없어졌다. 변수명 앞에 이런 접두사를 붙이면 코드를 읽는 사람이 불필요한 정보에 신경 쓰게 되고, 결국 코드의 가독성을 저해하게 된다.

public class Part {
    String description;

    void setDescription(String description) {
        this.description = description;
    }
}

 

여기에서는 description이라는 명확한 이름만을 사용하여 Part의 설명을 표현하였다.

또한, 클래스가 인터페이스인지 아닌지를 나타내는 'I'와 같은 접두사도 피하는 것이 좋다. 이는 클래스를 사용하는 사람에게 불필요한 정보를 제공하며, 가독성을 해칠 수 있다. 만약 인터페이스와 구현 클래스를 명확히 구분해야 한다면, 인터페이스는 단순한 이름을 사용하고, 구현 클래스 이름에 인코딩을 하는 것이 더 좋다.

public interface ShapeFactory { ... }

public class ShapeFactoryImp implements ShapeFactory { ... }


이렇게 하면 사용자는 단순히 ShapeFactory라는 이름으로 클래스를 사용하며, 인터페이스와 구현 클래스를 쉽게 구분할 수 있다.

< 단일 문자 변수명: 좋은 선택일까? >

한 번씩 우리는 코드에서 단일 문자로 이루어진 변수명을 발견하곤 한다. 예를 들어, 루프에서 반복 횟수를 세는 변수로 'i', 'j', 'k'를 사용하는 것이 대표적인 경우다. 하지만 이런 단일 문자 변수명은 국한된 상황에서만 적절하다고 할 수 있다. 즉, 루프 범위가 작고, 다른 이름과의 충돌이 없을 때에 적용할 수 있다.

그럼에도 불구하고, 단일 문자 변수명의 남발은 피해야 한다. 이유는 단순하다. 코드를 읽는 사람이 'c'라는 변수가 무엇을 의미하는지 기억하고 있어야 한다면, 이는 그 사람에게 부담을 주는 것이기 때문이다.

['똑똑함'의 함정에서 벗어나기]
프로그래머들은 대체로 똑똑하다. 하지만 이 똑똑함이 가끔 함정이 될 수 있다.  'r'이라는 변수가 호스트와 프로토콜을 제외한 소문자 URL을 나타내는 것을 항상 기억할 수 있다고 자신할지라도, 이는 명확하지 않은 코드를 만들어낼 수 있다.

전문적인 프로그래머는 자신의 능력을 잘 활용하여 다른 사람들이 쉽게 이해할 수 있는 코드를 작성한다. 이들은 '명료함'이 가장 중요하다는 사실을 잘 이해하고 있다.

[클래스 이름과 메서드 이름 잘 짓기]
클래스 이름은 명사나 명사구를 사용한다. 이는 클래스가 어떤 '것(thing)'을 나타내기 때문이다. 예를 들면, 'Customer', 'WikiPage', 'Account', 'AddressParser' 등이 있다. 'Manager', 'Processor', 'Data', 'Info' 같은 모호한 단어는 피하도록 하자.

반면에 메서드 이름은 동사나 동사구를 사용한다. 메서드는 어떤 행동을 나타내므로, 이름도 그러한 행동을 잘 설명해야 한다. 'postPayment', 'deletePage', 'save' 등이 좋은 예이다.

생성자의 이름을 지을 때는 조금 다른 접근 방식이 필요하다. 여러 생성자를 만들 때는, 각각의 차이점을 설명하는 이름을 가진 정적 팩토리 메서드를 사용하는 것이 좋다. 예를 들어, 'Complex.FromRealNumber(23.0)'처럼 사용하면, 생성자가 하는 일이 명확히 보인다.

 

 

 

 

 

 

출처 : 출판사 인사이트북 / 클린 코드 / https://product.kyobobook.co.kr/detail/S000001032980

※저의 블로그에 있는 모든 참고 서적,강의 내용은 출판사,저자(혹은 편집자)에게 허락을 직접 맡고, 게시하는 글 입니다.

 

Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고

Clean Code(클린 코드) | 프로그래머, 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가에게 추천하는더 나은 코드를 만드는 책『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의 동

product.kyobobook.co.kr

 

< 그릇된 정보를 피하자 >

코드에서 잘못된 정보를 제공하는 이름을 사용하면, 코드를 읽는 사람을 혼란스럽게 만들 수 있다. 예를 들어, 리스트가 아닌 것을 'accountList'라고 부르면, 이것은 프로그래머에게 잘못된 정보를 제공하는 것이다. 왜냐하면 프로그래머에게 'List'는 특별한 의미를 갖기 때문이다. 그래서 'accountGroup' 또는 'accounts'와 같이 명명하는 것이 더 좋다.

또한, 아주 비슷한 이름을 사용하면 혼란을 초래할 수 있다. 예를 들어, 'XYZControllerForEfficientHandlingOfStrings'와 'XYZControllerForEfficientStorageOfStrings'는 아주 비슷한 이름이다. 둘 사이의 차이를 구별하기 어렵다. 비슷한 이름을 사용하는 것보다는, 서로 다른 개념은 서로 다른 이름을 사용하는 것이 좋다.

< 의미있게 구분하자 >

코드 내에서 두 개념을 구분하기 위해 이름을 지을 때, 의미있게 구분하는 것이 중요하다. 연속된 숫자를 이름에 추가하거나 (예: a1, a2, ...), 불용어를 추가하는 것은 좋지 않다. 이름이 다르다면, 대표하는 의미도 달라져야 하기 때문이다.

이름에 'variable', 'table' 등의 단어를 추가하는 것 역시 피해야 한다. 이러한 단어는 불필요한 중복을 초래하고, 추가적인 정보를 제공하지 못한다. 예를 들어, 'NameString'이 'Name'보다 무엇이 더 나은가?  아무런 차이가 없다.

< 발음하기 쉬운 이름을 사용하자 >

마지막으로, 이름을 지을 때 발음하기 쉬운 이름을 선택하는 것이 좋다. 우리의 뇌는 단어를 처리하는 데 많은 부분을 사용하며, 그 단어들은 발음이 가능한 것이다. 그래서 발음하기 쉬운 이름을 사용하면, 우리는 코드에 대해 토론하기도 쉽고, 이해하기도 쉽다.

예를 들어, 다음의 두 코드 중 어느 쪽이 더 이해하기 쉬울까?

class DtaRcrd102 {
    private Date genydhms;
    private Date modymdhms;
    private final String pszqint = "102";
};


vs

class Customer {
    private Date generationTimestamp;
    private Date modificationTimestamp;
    private final String recordId = "102";
};



두 번째 코드가 더 이해하기 쉽고, 의미가 명확하다. 그리고 이야기하거나 토론하기에도 훨씬 쉽다.

결국, 이름을 지을 때는 잘못된 정보를 제공하지 않도록 주의하고, 서로 다른 개념에는 서로 다른 이름을 지어야 한다. 또한, 이름은 가능하면 발음하기 쉬워야 한다. 이렇게 하면, 우리의 코드는 읽기 쉽고 이해하기 쉬워질 것이다.

 

 

 

출처 : 출판사 인사이트북 / 클린 코드 / https://product.kyobobook.co.kr/detail/S000001032980

※저의 블로그에 있는 모든 참고 서적,강의 내용은 출판사,저자(혹은 편집자)에게 허락을 직접 맡고, 게시하는 글 입니다.

 

Clean Code(클린 코드) | 로버트 C. 마틴 - 교보문고

Clean Code(클린 코드) | 프로그래머, 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가에게 추천하는더 나은 코드를 만드는 책『Clean Code(클린 코드)』은 오브젝트 멘토(Object Mentor)의 동

product.kyobobook.co.kr

 

+ Recent posts