FrontEnd/JavaScript

Module화에 대한 생각

devdubu 2024. 10. 22. 10:03

JavaScript에서의 모듈화

Java에서의 객체를 만든다와는 조금은 다른 개념이지만, 복잡했던 부분을 설계적으로 나누며 하나의 로직들을 단순화 시키는데는 동일하다고 생각이 듭니다.

JavaScript에서는 모듈화를 시킬 수 있는 요소는 3가지 정도 되어보입니다.

기본적으로 export import의 지식이 있다는 가정하에 적어봅니다.

Object 형

말 그대로 Object형으로 모듈화를 하는 것입니다.

export const objectModule = {
    objectString: 'example',
    objectFunc : () =>{ },
}

// 외부에서 사용할 때
objectModule.objectFunc()

지극히 개인적으로 느끼는 장단점 입니다.
부족할 수도 있습니다 ㅎㅎ

장점

하나의 객체만 Export 해도 Object에 있는 걸 모두 Export 할 수 있습니다.

지극히 당연

각각의 여러 개의 함수를 export를 하는 것보단, 관련 있는 함수들끼리 묶어서 하나의 Object로 표현하고, 추후에 추가가 되더라도, export는 신경 쓰지 않아도 됩니다.

호출 및 구현이 쉽습니다.

이후에 나오는 부분보다 구현이 간단하며, 단순하게 구성하며, 또한 단순하게 사용할 때 좋습니다.

단점

단순하게 밖에 사용이 안됩니다.

장점이자 단점이지만, 예를 들면, 공통으로 사용하는 변수가 생길시 부터 문제가 생깁니다.
모든 객체들은 무조건적으로 독립적이게 됩니다.

즉, 상태를 저장하기에 적합한 모듈화 방법이 아닙니다.

Function 형

함수를 이용해서 모듈화 하는 것입니다.
말로 하는 것보다는 코드로 보여드리는게 빠를듯 싶습니다 ㅎㅎ

export const exportFunc = (_props:any) =>{
      const props = _props

    const exportInnerFunc1 = () =>{
          ...
    }

    const exportInnerFunc2 = () =>{
          ...
    }

    return { exportInnerFunc1, exportInnerFunc2 }
}


const functionModule = exportFunc(props)
const functionModule.exportInnerFunc1()

위와 같이 사용도 가능하고, 혹은 아래 처럼 사용도 가능합니다.

export const exportFunc = (_props:any) =>{
      const props = _props

    const exportInnerFunc1 = () =>{
          ...
    }

    const exportInnerFunc2 = () =>{
          ...
    }

    return { exportInnerFunc1, exportInnerFunc2 }
}


const functionModule = new exportFunc(props)
const functionModule.exportInnerFunc1()

const functionModule2 = new exportFunc(props)
const functionModule2.exportInnerFunc1()

함수를 생성자를 사용해서 사용도 가능합니다.
생성자 함수를 사용하게 된다면, 객체지향에서의 생성자 처럼

위와 같은 결론이 나올 수 있습니다.

실제 함수를 모듈화 하게 된다면, 같은 메모리 주소를 공유하지만, 생성자 함수를 이용한다면 모두 별개의 메모리 주소를 통해서 독립된 변수로 작동하게 됩니다.

단점

상속이 어렵습니다.

상속이 아예 불가능 한건 아니지만, 생각보다 그리 깔끔하게 상속이 되는 느낌은 아닙니다.
prototype 을 통해서 상속을 진행하지만,, 그리 권장하고 싶지 않습니다 저도 헷갈리더라구요 헷

prototype 관리가 힘들다

사실 이는 저도 그리 많이 본 상황은 아니라서 무조건 어렵다라고 얘기하기엔 좀 힘들지만, GPT의 예시를 보게 된다면,,충분히 객체를 생성하다가 나올 법한 오류들이 있을 듯 하여서 넣어 봅니다.

function Animal(type) {
  this.type = type;
}

Animal.prototype.traits = [];

const dog = new Animal('Dog');
const cat = new Animal('Cat');

dog.traits.push('barks');
console.log(dog.traits);  // ['barks']
console.log(cat.traits);  // ['barks'] => cat도 영향을 받음!

최근에 만들어진 소스에서 .prototype. 을 직접 사용할 일은 없어보이지만,,,예전의 코드라면 충분히 가능성이 있을듯 보입니다.
혹시라도 그런 경험이 있으신 분이 있다면, 알려주시면 감사하겠습니다 :D

Class

사실상 저의 짧은 지식으로 느끼기엔, Class와 생성형 함수와 명확한 차이점은 상속인듯 싶습니다.


여러가지 차이점도 존재는 한다만,,, 그 중에서 굳이 생성형 함수로 쓸수 있는데도 복잡한 개념으로 Class를 들고오는 것은 결국 상속 때문이지 않을까 조심스럽게 생각합니다 ㅎㅎ

 

여러 글에서도 많이 들었다싶이 사실상 내부적으로 따진다면, 생성형 함수로 상속하는 것과 class로 상속하는건 차이가 없다 이지만, 결국 개잘자들이 차이가 있기에 ㅎㅎ


class를 많이 사용하는 것 처럼 보였습니다.

export class ExampleClass{
    constructor(name){
        this.name = name
    }
}

const class1 = new ExampleClass('string')

위 처럼 class를 구성할 수 있습니다.
여느 기타 객체지향과 사용하는데는 다른점을 찾기 힘들지만, 속 사정은 많이 다릅니다.

 

장단점은 사실상 여타 객체지향의 장단점을 가지고는 있습니다만,,
사실 객체지향이 가지고 있는 완전한 class라고 부르기엔 어렵습니다.

 

완벽하게 private 하지도 않으며, protected 기능 조차도 불완전 하니까요!

그런데도 불구하고, JS에서 객체지향 적 설계가 가능하다는 점에서 다들 의의를 두로 사용하는 듯 합니다.

 

뭐 사실 해당 needs도 결국은 TS로 가면서 해결된 부분들이 몇개 있습니다.


어쩌피 객체지향에 관련된 부분들은 꾸준히 TS에서 업데이트를 해주니 저는 이정도 까지만 알게 된다면,

모듈화를 하고, 어플리케이션 아키텍트를 짜는 입장에서 위 3가지를 고려해보면 될 듯합니다.

'FrontEnd > JavaScript' 카테고리의 다른 글

NodeJS 디자인 패턴 1편  (0) 2025.04.09
정규 표현식  (0) 2024.08.16