함께 자라기 with 그랩 - 2주차

---

📌 강의를 듣고 배운 내용 정리

절차지향 프로그래밍

장단점

• 장점

  절차지향 프로그래밍으로 작성된 코드는 일반적으로 이해하기 쉽습니다. TOP -> DOWN 식이고, 함수라는 작은 단위로 나눠져 있기 때문이죠. 로직이 복잡한 것이나 계속해서 기능을 확장해나가야 하는 것이 아니라면, 유지보수도 용이합니다. 우리가 프로그래밍을 처음 배우면 보통 절차지향으로 배우는 이유이기도 합니다.

• 단점

  그러나 절차지향은 전체 로직이 매우 복잡하거나 동적으로 로직을 바꿔야 하는 등의 기능 확장이 필요할 때 유지 보수하기가 어려워집니다. 또한 데이터와 함수가 분리되어 있기에 함수가 많아질수록 데이터의 변경 사항을 추적하기도 어려워집니다.

따라서 절차지향은 프로그램이 수행하는 알고리즘이 명확하고, 기능 확장 등이 자주 일어나지 않는 상황에서 사용하기에 좋습니다.

객체 지향 프로그래밍

장단점

• 장점

  객체 지향은 여러 명의 개발자들이 협력을 해야 하거나, 확장 가능하도록 코드를 설계해야 하는 경우에 적합합니다.

• 단점

  하지만 확장이 가능하고 유연한 만큼, 처음 코드를 보는 사람들은 어렵고 헷갈릴 수 있습니다. 또한 실행 환경에서 입력에 따라 다양한 작업 흐름이 만들어지기 때문에 디버깅하기가 상대적으로 어렵습니다.

---

📌 내 프로젝트에 피드백 해보기

파이널 프로젝트에서 작성했던 코드를 살펴보면 절차지향 프로그래밍으로 진행했었다.많은 기능이 모인 컴포넌트를 객체지향 프로그래밍으로 리팩토링해보면괜찮겠다고 생각했다.

그 이유는 이전에는 전혀 이렇게 생각을 못했지만 다시 살펴보니 많은 데이터들이 공유되어 있는 상태이기 때문에 가독성이 좋지 않다고 생각이 들었기 때문이다.

하지만, 아직 어떻게 뜯어고쳐야 할 지 엄두가 안나기 때문에 가장 볼륨이 적은 컴포넌트를 선정해서 추후 리팩토링 기간에 적용해보면서 연습해보려고 한다!

Login 컴포넌트

function Login() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [errorMessage, setErrorMessage] = useState('');
  const [open, isOpen] = useState(true);
  const navigate = useNavigate();
  const dispatch = useDispatch<AppDispatch>();

  const handleOnSubmit = useCallback(
    async (e: React.FormEvent<HTMLFormElement>) => {
      e.preventDefault();
      try {
        if (email && password) {
          const data = await axios.post(
            `${process.env.REACT_APP_SERVER}/users/login`,
            { email, password },
            {
              headers: {
                'Content-Type': 'application/json',
              },
              withCredentials: true,
            },
          );
          dispatch(UserLogin(data.data.data));
          setEmail('');
          setPassword('');
          navigate('/');
        }
      } catch (err) {
        setErrorMessage('이메일과 비밀번호를 다시 확인해주세요.');
      }
    },
    [email, password, setEmail, setPassword, navigate, setErrorMessage],
  );

  const emailOnChange = useCallback(
    (e: React.FormEvent<HTMLInputElement>) => {
      setEmail(e.currentTarget.value);
    },
    [setEmail],
  );

  const passwordOnChange = useCallback(
    (e: React.FormEvent<HTMLInputElement>) => {
      setPassword(e.currentTarget.value);
    },
    [setPassword],
  );

  const exitOnClick = useCallback(() => {
    isOpen(false);
    navigate('/');
  }, [open, isOpen, navigate]);

  const signUpOnClick = useCallback(() => {
    navigate('/signup');
  }, [navigate]);

  const state = window.localStorage.getItem('com.naver.nid.oauth.state_token');
  const naverUrl = `https://nid.naver.com/oauth2.0/authorize?response_type=code&client_id=${process.env.REACT_APP_NAVER_CLIENT_ID}&state=${state}&redirect_uri=${process.env.REACT_APP_NAVER_CALLBACK_URL}`;
  const kakaoUrl = process.env.REACT_APP_KAKAO_AUTH_URL;
  const googleUrl = process.env.REACT_APP_GOOGLE_AUTH_URL;

---

📌 이번 주 공유된 아티클을 읽고 핵심 내용 정리

데이터를 가지고 조건문, 반복문 등을 통해 일정한 절차를 수행하는 부분을 '프로시져' 라고 부릅니다.

문제 의식

코드를 행동을 기준으로 묶었을 때 규모가 적을 때는 코드의 흐름을 따라가기 쉽다. 하지만 변경 가능한 공유 데이터를 사용할 수 있기 때문에 규모가 커질 수록 코드의 가독성이 매우 나빠지고 코드를 바꾸기도 어렵고, 버그도 많이 생긴다.

개선 방향

이러한 문제를 해결하기 위해서 흩어져 있는 데이터와 로직을 하나의 그릇에 담아주면 된다. 서로 관련 있는 데이터와 프로시져를 독립된 하나의 개체로 묶어주는 것이다. 한 개체는 다른 개체가 관리하는 데이터를 건드릴 수 없게 된다. 오직 자기가 갖고 있는 데이터와 관련있는 작업만 직접 수행하게 한다.

연관성이 없는 다른 작업은 그 작업을 맡고 있는 다른 객체에게 ‘메시지'를 보내서 담당하게 한다. 이렇게 하면 변경 가능한 데이터를 공유하는 일이 없어지고, 독립된 개체가 서로 메시지를 주고 받는 관계만 남게 된다.

이것이 앨런 케이가 생각했던 객체 지향의 본질인 1) 메시징 2) 캡슐화 3) 동적 바인딩이다.

메시징, 캡슐화, 동적 바인딩이 합쳐질 때 기대되는 효과는 다음과 같다.

1. 변경가능한 공유 데이터가 최소로 줄어든다.
   관련있는 프로시져와 데이터를 묶은 다음, 다른 객체는 접근할 수 없게 하기 때문이다. 다른 객체의 상태를 알아내거나 바꾸려면, 해당 객체가 정해놓은 형식으로 메시지를 보내는 방식밖에 없다. 이걸 '캡슐화'라고 한다.

2. How(구현) 부분을 쉽게 바꿀 수 있다.
   '메시지'를 받는 부분만 일관되게 유지한다면, 실제로 그걸 처리하는 코드는 바뀌어도 실행에 문제가 없다.'메시지를 보내는 것'은 메서드(함수)를 호출하는 것과 다르다.다른 객체가 돈을 달라는 메시지를 보내면, 지갑에서 돈을 꺼내주든, 옆에 있는 친구한테 돈을 빌리든, 스마트폰으로 이체를 해주든 받는 객체가 알아서 결정한다.

3. 메시지를 실제로 처리하는 객체를 쉽게 바꿀 수 있다.
   기능의 변경이 쉬워진다.

---

출처
https://velog.io/@eddy_song/alan-kay-OOP,
그랩님이 공유해주신 자료!

---