[CS study] 2022.04.20

Software Engineering

이해는 하고 있지만 설명은 못하겠는 용어들의 정의

 

클린 코드와 리펙터링 의미만 보면 비슷하다고 느껴진다. 어떤 차이점이 있을까?

 

클린 코드

• 가독성이 높은 코드를 의미
• 얼마나 코드가 잘 읽히는지, 코드가 지저분하지 않고 정리된 코드인지를 나타내는 것
• 가독성을 높이는 법
  • 네이밍이 잘 되어야 함
  • 오류가 없어야 함
  • 중복이 없어야 함
  • 의존성을 최대한 줄여야 함
  • 클래스 혹은 메서드가 한 가지 일만 처리해야 함

 

리팩터링

• 프로그램의 외부 동작은 그대로 둔 채, 내부의 코드를 정리하면서 개선하는 것
• 프로젝트가 끝나면, 지저분한 코드를 볼 때 가독성이 떨어지는 부분이 존재 이 부분을 개선시키기 위한 것이 리팩터링
• 코드의 가독성을 높이고, 유지보수에 큰 도움이 된다.
• 목적은 소프트웨어를 더 이해하기 쉽고 수정하기 쉽게 만드는 것 (성능을 최적화시키는 것이 아님)
• 이해하기 쉽고, 수정하기 쉽다? -> 개발 속도가 증가!
• 명심해야 할 것, 우선 코드가 제대로  돌아가야 한다. 리팩터링은 우선적으로 해야 할 일이 아님을 명심
• 리팩터링이 필요한 코드?
  • 중복 코드
  • 긴 메서드
  • 거대한 클래스
  • switch문 (객체지향의 특징을 살리려면 적게 사용해야 함)
  • 절차 지향으로 구현한 코드

 

결론

• 리팩터링이 클린 코드보다 더 큰 의미 클린 코드는 단순히 가독성을 높임 리팩터링은 클린 코드를 포함한 유지보수를 위한 코드 개선
• 클린 코드는 설계부터 잘 이루어져 있는 것이 중요!
• 리팩터링은 결과물이 나온 이후 수정이나 추가 작업이 진행될 때 개선해나가는 것이 올바른 방향

 

객체지향 프로그래밍 (OOP)

너무나 방대한 내용이다. 천천히 개념을 잡아보자!

 

객체지향 패러다임이 나오기 이전의 패러다임부터 살펴보자.

 

순차적, 비구조적 프로그래밍

• 말 그대로 순차적으로 코딩해나가는 것
• 필요한 게 있으면 순서대로 추가해가며 구현해가는 방식. 직관적일 것처럼 생각되지만, 점점 규모가 커진다면?
• 비구조적 프로그래밍에서는 goto문을 활용한다. 만약 이전에 작성했던 코드가 필요하면 다시 그곳으로 이동하기 위함
• 규모가 커지면 goto문이 무분별하게 사용되고, 실뜨기를 하는 것처럼 꼬이게 된다.
• 나중에 코드가 어떻게 연결되어 있는지 확인조차 못하게 될 문제점 존재

 

그래서 탄생한 것이 절차적, 구조적 프로그래밍

 

절차적, 구조적 프로그래밍

• 반복될 가능성이 있는 것들을 재사용이 가능한 함수(프로시저)로 만들어 사용하는 방식
• 보통 절차라는 의미는 함수(프로시저)를 뜻하고, 구조는 모듈을 뜻함, 모듈이 함수보다 작은 의미이긴 하지만 요즘은 큰 틀로 같은 의미로 쓰이고 있다.
  • 프로시저(procedure): 반환 값(return)이 따로 존재하지 않는 함수를 뜻함 (요즘 언어에서는 function과 procedure를 구분해 사용하지 않는다. 예전에는 문법적으로 구분하는 언어도 있었다 정도로 이해하자)
• 너무 추상적으로 표현된다는 문제점 존재
• 함수는 논리적 단위로 표현되지만, 실제 데이터에 해당하는 변수나 상수값들은 물리적 요소
• 도서 관리 프로그램이 있다고 가정
  • 책에 해당하는 자료형(필드)를 구현해야 한다.
  • 책과 관련된 함수를 구현해야 한다.
  • 이들을 따로 만들어야 한다 결국 많은 데이터를 만들어야 할 때 구분하기 힘들고 비효율적으로 코딩할 가능성 증가

 

이를 한 번에 묶기 위한 패러다임 객체지향 프로그래밍 탄생

 

객체지향 프로그래밍

• 클래스마다 필요한 필드를 선언
• 특정한 개념의 함수와 자료형을 함께 묶어서 관리하기 위해 탄생한 것
• 객체 내부에 자료형(필드)와 함수(메서드)가 같이 존재하는 것이 중요한 점
• 도서 관리 프로그램이 있다고 가정할 때 책이라는 객체에 제목, 저자, 페이지와 같은 자료형과 읽기, 예약하기 등 메서드를 한 번에 묶어 저장하는 것이 가능해졌다.
• 이처럼 가능한 모든 물리적, 논리적 요소를 객체로 만들려는 것
• 객체 간의 독립성이 생기고 중복 코드의 양이 줄어듬, 독립성이 확립되면 유지보수에도 용이

 

결과적으로 나아가는 방향은 점점 개발자들이 편하게 개발할 수 있도록 개선되는 방식이다.

 

객체지향 패러다임이 생기며 크게 4가지 특징을 갖추게 되었다.

이 4가지 특성을 잘 이해하고 구현해야 객체를 통한 효율적인 구현이 가능하다.

 

특징

• 추상화(Abstraction): 필요로 하는 속성이나 행동을 추출하는 작업
  • 추상적인 개념에 의존하여 설계해야 유연함을 갖출 수 있다.
  • 세부적인 사물들의 공통적인 특징을 파악한 후 하나의 집합으로 만들어 대는 것 ( 최양임, 배성현, 노광민, 갓승대는 모두 사람이라는 공통점이 있다 사람이라는 추상화 집합을 만들고 사람이 가진 공통적인 특징들을 만들어 활용한다)
  • 왜 필요한가? 새로운 사람이 추가될 수도 있다. 이때 추상화로 구현해두면 다른 곳의 코드는 수정할 필요 없이 추가로 만들 부분만 새로 생성해주면 됨
• 캡슐화(Encapsulation): 낮은 결합도를 유지할 수 있도록 설계하는 것
  • 한 곳에서 변화가 일어나도 다른 곳에 미치는 영향을 최소화하는 것
  • 객체가 내부적으로 기능을 어떻게 구현하는지 감추는 것
  • 결합도가 낮아야 하는 이유?
    • 결합도: 어떤 기능을 실행할 때 다른 클래스나 모듈에 얼마나 의존적인가를 나타내는 말
    • 즉 독립적으로 만들어진 객체들 간의 의존도가 최대한 낮게 만드는 것이 중요
  • 객체 안의 모듈 간의 요소가 밀접한 관련이 있는 것으로 구성하여 응집도를 높이고 결합도를 줄여야 요구사항 변경에 대처하는 좋은 설계 방법
  • 캡슐화는 어떻게 높은 응집도와 낮은 결합도를 갖게 할까?
    • 정보 은닉을 활용함
    • 외부에서 접근할 필요가 없는 것들은 private로 접근하지 못하도록 제한을 두는 것
• 상속: 일반화 관계(Generalization)라고도 함 여러 개체들이 지닌 공통된 특성을 부각해 하나의 개념이나 법칙으로 성립하는 과정
  • 상속(일반화)은 또 다른 캡슐화다 자식 클래스를 외부로부터 은닉하는 캡슐화의 일종이라고 말할 수 있다
  • 자동차 클래스가 있다고 생각해보자 내부에는 볼보, 벤츠, 아우디 등이 캡슐화를 통해 은닉되어있다.
    • 여기에 추가로 대리 운전을 하는 사람 클래스가 있다고 가정
    • 사람 클래스의 관점으로는 자동차의 종류가 숨겨져 있는 상태
    • 대리 운전자의 입장에서는 자동차의 종류는 운전하는데 크게 중요하지 않다.
    • 새로운 자동차들이 추가되어도 사람 클래스는 영향을 받지 않는 것이 중요하다.
    • 그러므로 캡슐화를 통해 사람 클래스 입장에서 확인할 수 없도록 구현하는 것
  • 이처럼 상속 관계에서는 단순히 하나의 클래스 안에서 속성 및 연산들의 캡슐화가 한정되지 않음
  • 즉 자식 클래스 자체를 캡슐화하여 사람 클래스와 같은 외부에 은닉하는 것으로 확장되는 것
  • 자식 클래스를 캡슐화하면 외부에선 이러한 클래스들의 영향을 받지 않고 개발을 이어갈 수 있는 장점
  • 상속 재사용의 단점
    • 부모 클래스의 변경이 어려워짐 (자식 클래스들이 영향을 받음)
    • 불필요한 클래스가 증가할 수 있음 (유사기능 확장 시 필요 이상의 불필요한 클래스를 만들어야 할 수 있음)
    • 상속이 잘못 사용될 수 있음 (같은 종류가 아닌 클래스의 구현을 재사용하기 위해 상속을 받게 되면 문제가 발생할 수 있음 상속받는 클래스가 부모 클래스와 IS-A 관계가 아닐 때 문제 발생)
      • IS-A관계: 'A는 B이다'일 때 '~이다'와 같다. A클래스가 다른 클래스 B의 서브클래스(파생 클래스) 임을 의미 (동물이라는 부모 클래스에 개, 사람이라는 자식 클래스가 있는 것 '사람은 동물이다', '개는 동물이다')
      • HAS-A관계: 'A는 B를 가지고 있다'와 같다. 다른 객체를 받아들여 그 객체의 기능을 사용하는 것 (연필 클래스와 지우개 클래스가 있을 때 연필 클래스에 지우개 클래스를 객체화하여 지우개 클래스의 자원 및 기능을 사용할 수 있게 하는 것 지우개가 달린 연필이 탄생)
    • 해결책
      • 객체 조립 (Composition) 컴포지션이라고 부르기도 함 필드에서 다른 객체를 참조하는 방식으로 구현됨
      • 상속에 비해 런타임 구조가 복잡해지고 구현이 어려운 단점
      • 변경 시 유연함을 확보하는데 장점
      • 같은 종류가 아닌 클래스를 상속하고 싶을 때는 객체 조립을 우선적으로 적용하는 것이 좋음
  • 상속을 사용할 때
  • IS-A관계가 성립할 때
  • 재사용의 관점이 아니라 기능의 확장 관점일 때
• 다형성(Polymorphism): 서로 다른 클래스의 객체가 같은 메시지를 받았을 때 각자의 방식으로 동작하는 능력
  • 객체 지향의 핵심
  • 상속과 함께 활용할 때 큰 힘을 발휘 코드를 간결히 해주고 유연함을 갖추게 해 줌
  • 부모 클래스의 메서드를 자식 클래스가 오버 라이딩해서 자신의 역할에 맞게 활용하는 것
    • 오버 라이딩: 무시하다, 우선하다 기반 클래스의 메서드를 무시하고 새로운 메서드를 만듦 (사람 클래스를 상속받는 학생 클래스가 있다 둘 다 인사라는 메서드를 가지고 있을 때 학생. 인사()를 했을 때 사람의 인사 메서드를 무시하고 학생의 인사 메서드 재정의하여 사용)
  • 다형성을 사용하면 구체적으로 어떤 클래스 객체가 참조되는지는 무관하게 프로그래밍하는 것이 가능해짐

객체 지향 설계 원칙

SOLID라고 부르는 5가지 설계 원칙이 존재

• SRP 단일 책임 원칙
  • 클래스틑 단 한 개의 책임을 가져야 함
  • 클래스를 변경하는 이유는 단 한 개여야 함
  • 이를 지키지 않으면, 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있음
• OCP 개방-폐쇄 원칙
  • 확장에는 열려있고 변경에는 닫혀 있어야 함
  • 기능을 변경이나 확장할 수 있으면서 그 기능을 사용하는 코드는 수정하지 않음
  • 이를 지키지 않으면, instanceof와 같은 연산자를 사용하거나 다운 캐스팅이 일어남
• LSP 리스 코프 치환 원칙
  • 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 함
  • 상관관계가 아닌 클래스들을 상속 관계로 설정하면 이 원칙에 위배됨
• ISP 인터페이스 분리 원칙
  • 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 함
  • 클라이언트가 필요로 하는 인터페이스를 분리함으로써, 각 클라이언트가 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 만들어야 함
• DIP 의존 역전 원칙
  • 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안됨
  • 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 함
  • 즉 저수준 모듈이 변경되어도 고수준 모듈은 변경할 필요가 없는 것

https://ch-oi-story.tistory.com/103

[C/S 스터디 4일차] 네트워크 모델 (2) + OSI 7계층