SOLID 개방폐쇄의 원칙 OCP

[@sorrymommy]

좋은 내용 항상 올려주셔서 감사합니다. 제가 좋아하는 객체지향이 나와서 혹시나 저같은 삽질하는 분들이 계실까봐 댓글 달아봅니다. (주인장님한테 탯클 거는거 아닙니다.) 객치지향 5원칙이 아니라. 객체지향 설계 5원칙입니다. 이렇게 접근을 해야 안 헷갈려요. OOP자체를 이야기하는 것이 아니라 OOP를 기반으로 시스템을 설계할 때 지켜야될 5대 원칙이기 때문에 OOP의 특징이나 원칙으로 접근하다가는 산으로는 갑니다. (초보분들 조심하시길...) 즉 설계이기 때문에 시스템 내 OOP로 구현되어야되는 클래스, 인터페이스 등의 구조를 잡을 때 이런 원칙을 기준으로 잡아야 OOP로 구현된 좋은 시스템이 되는 것이고 이는 곧 유지보수의 용의성으로 이어진다고 이야기하는 것이 핵심입니다. 저는 삽질을 많이 했지만 후배님들은 삽질하지 마시길...

[@nullnull_not_eq_null]

좋은 의견 감사합니다. 다행히도 영상 내에서는 '설계'라는 점을 언급하고 있어서 크기 혼란은 없지 않을까 기대해봅니다. ^^ 그리고 '원칙'은...번역이다 보니 어쩔 수 없는데...그게 사실 '원칙'이라고 까지 해야 하는 것인가에 대한 의문이 있긴 합니다. ^^;;;;

[@갈가마구]

@@nullnull_not_eq_null 뎃글도 참고가 될만한 의미 있는 부분이 많네요.... 원래 뎃글은 잘 안보는데....한번씩 봐야 겠습니다... 감사합니다.

[@발언계산기]

전 레고에 빗대곤 합니다. 높은 응집도는 레고의 "수준높은 에디션" 낮은 결합도는 레고의 "특수블럭 사용최소화" 확장가능은 "신규블럭 제작가능" 변경불가는 "블럭규격 절대준수"

[@nullnull_not_eq_null]

좋은 표현 감사합니다. 영상의 부족한 부분을 채워줄 수 있을 것 같습니다. ^^

[@4song997]

감사합니다!

[@marunarae550]

바깥에서 건드리지 못하게 해서 내부적인 메서드들을 이용하게 만들면 응집성이 높아지고, 실수할 가능성도 줄고.. 미래에 대한 확장은 가상함수로 구현하거나, 생성자 수준에서 어떤 객체를 줄지 조절하는 코드를 주면 되겠네요. 이해한게 맞는지는 모르겠지만..

[@marunarae550]

전역 변수 쓰면 안되는 이유가 thread-safe한가 아닌가 하는 관점에서만 봤었는데, 코드가 과한 의존성을 띠게 되는것도 있었군요..

[@nullnull_not_eq_null]

음...멤버를 감추는 것은 객체의 기본 특성으로 보고...관련이 깊은 객체간에는 응집성을 높여 줍니다. 이 때, 생성단계에서 둘을 엮도록 코드를 강제화 하는 방법으로 특정 객체의 참조자를 생성단계에서 인수로 받도록 하는 방법이 활용되기도 합니다. 참고하시기 바랍니다. ^^

[@nullnull_not_eq_null]

스레드도 스레드인데...'의존성'문제가 정말 큽니다. 나중에 유지보수 이슈로 이어지죠. 참고하시기 바랍니다. ^^

[@marunarae550]

@@nullnull_not_eq_null 사실 멤버를 아무리 감춰도 get과 set을 메서드로 수행하기 때문에.. 얼마나 의미가 있는지는 잘 모르겠긴 합니다 ㅎㅎ

[@Pushing_Daisies_]

1 2024-0128-1009