[💬] 밑에 좆문가 2명 싸우는거 나도 반박해봄

[익명(175.214)]

1. 객체지향에서 객체는 실제 세계에 존재하지 않는다

(O)

-> 객체는 대부분 실제 존재하는 모델들을 대상으로 판단하는 경우가 많은건 사실이긴 한데

함수들의 기능적 특성이나, 형태들도 객체로 삼을 수 있음

2. 객체지향은 멤버변수, 메서드를 묶은 게 끝이다

(X)

-> 객체지향은 코드를 설계하는 패러다임의 일종이고,

언어가 제공하는 멤버변수, 멤버함수와 같은 기능적 특성이랑은 의미하는 바가 다름

3. SOLID, 디자인 패턴은 객체지향에 필수가 아니다

(O)

-> 디자인 패턴은 단어 그대로 그저 패턴과 같이 흔하게 사용되는 구성을 일반화한 레퍼런스임

4 객체지향은 프로그래밍을 쉽게 하기 위해 생겨났다

(X)

-> 절반은 맞는 말인데, 협업 중심인 IT산업에서 절차지향이 가지는 코드의 재활용성 부재라던지,

코드를 덩어리채 관리해야하는 유지보수의 난해함을 해결하기 위한 목적이 더 강함

5. 객체지향언어로 절차적 프로그래밍 못 함

(X)

-> 애초에 객체지향이랑 절차지향은 코드를 설계하는 방식의 차이일 뿐이고

만약, 언어가 절차지향이든 객체지향이든 지원한다면 짤 수 있는거임. 심지어 C로도 객체지향 비슷하게 재구조할 수도 있음.

물론 고급언어로 갈수록 특정 패러다임을 실현할 수 있도록 맞춤식으로 기능을 제공하는 경우도 있지만,

그게 꼭 해당 패러다임에만 활용되어야한다는 보장이 없음.

실제로 C++같은 멀티패러다임의 언어는 발표되는 표준마다 함수형, 메타, 객체지향에서 골고루 사용됨

예를 들어 템플릿 메타프로그래밍의 설계 원칙에서 만들어진 STL을 객체지향 모델에서 활용이 가능한 것처럼

서로가 서로를 보완하는 것도 가능함.

6. 패러다임과 언어는 완벽하게 구분할 수 없다

(X)

-> 패러다임과 언어는 명백히 구별될 수 있음.. 비유하자면 옷입는 스타일, 유행같은건 프로그래밍에서 패러다임으로 볼 수 있고

옷은 프로그래밍 언어라고 볼 수 있음.

기계어 동작 방식같은건 나도 몰라서 입꾹닫함

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[익명(175.214)]

절반만 맞았으니까 틀린거지

[익명(175.214)]

절차지향보다 무조건 객체지향이 프로그래밍이 쉽다고 볼 수 없으니까

[익명(222.99)]

절차지향으로 프로그래밍 하는게 더 쉬운 경우도 있고, 난 개인적으로 프로그래밍 난이도는 절차지향보다는 객체지향이 더 어렵다고 생각함. 짜는건 어렵지만 나중에 유지보수하고 관리하는게 편한건 다른거지

[익명(222.99)]

프로그래밍하는게 어려운거랑 관리하기 편한거랑 다른거지.. 잘 생각해보면 뭐가 다른지 알거임

[익명(222.99)]

객체지향으로 짤려면 여러가지 효율적인 클래스 구조나 상호작용도 고민해야해서 프로그래밍하기에는 정말 어렵고 그지같은데, 막상 해놓고나면 유지보수하기 편하고 객체끼리 상호작용하는거라 다시 꺼내서 다른데 붙이는 식으로 모듈화하기 편한거 이런 차이임

[익명(222.99)]

그리고 프로그래밍 쉽게하려고 절차지향에서 객체지향이 됐다기보단 ( 객체지향이 절차지향보다 무조건적으로 쉽다고 볼 수 없기때문에 ) 유지보수나 코드재활용성을 이용한 생산성 향상에 목적을 둔게 강하다라는게 내 생각임

[익명(222.99)]

그런 말장난으로 말꼬리 물고늘어지지 말고 잘 생각해봐.. 객체지향이 왜 필요한지? 객체지향이 절차지향보다 프로그래밍하는거 더 어려워. 다만 코드를 다시 가져다 쓰기 좋아서 생산성이 향상되잖아? 이 차이를 이해를 못함?

[익명(183.100)]

그냥 서로 둘다 쉽게 한다 라는개념을 다르게 생각하는거 같은데 고닉쪽은 쉽게 한다는 거가 과정이야 어쨌든 기존 절차지향에서 불편한점이 있고 유지보수도 어려우니까 그걸 편하게 하려고=> 쉽게 하려고 만들었다 이건거 같고 유동은 쉽게 한다=> 프로그래밍 하기 쉽다라는 하나의 뜻만 가지고 말하는거 같음

[소닉쫄따구테일즈(dcz3xv7zgu14)]

객체지향은 직관적인 관점으로 코드를 짜는거라 설계가 나름 쉽고 이해가 빠른데. 비직관적인 상황에서는 그냥 C처럼 절차적 프로그래밍이 더 쉬울수도 있음. 객체지향으로 짜면 느린데, 절차지향으로 짜면 빠른것들이 있음. 이 경우에는 빨라야하는게 목표인데, 객체지향으로 목적을 달성하기 힘들다면 코드 짜기 쉬워도 그건 쉬운 상황이 아닌거지. 이거랑 비슷한 말인가? 모르겠넹

[익명(222.99)]

183말이 맞음. 쟤는 유지보수하고 관리하고 이런걸 전부 프로그래밍으로 이야기하는거같은데, 난 프로그램만들때 코드짜는 과정 이걸 빗대서 이야기하는거임.

[익명(222.99)]

내가 저기서 절반만 맞았다는 이유는, 절차지향으로 짜는게 더 쉬운경우도 있기때문에, 무조건적으로 객체지향이 프로그래밍하는게 더 쉽다가 아니라고 이야기하는건데 고닉이 이해를 못하는거같네

[소닉쫄따구테일즈(dcz3xv7zgu14)]

근데 프로그래밍하는거랑 관리하는거랑 다른게 아니라 둘다 프로그래밍이지. 관리(확장 혹은 수정)에 취약한거는 다른이야기고. ECS하자 ECS!!

[익명(222.99)]

프로그래밍하는 과정 자체는 객체지향이 어렵다고 생각하는데, 한번 추상화해놓으면 나중에 그 기능을 하는 건 다시 짤 필요가 없으니까 편리한건 맞지, 근데 이런 맥락으로 해석하면 템플릿 메타 프로그래밍도 프로그래밍하기 쉽게하려고 만들었다라고 해석해야됨. 근데 현실은 그게아니잖아? 난이도만보면 절차지향<객체<메타 니까

[익명(222.99)]

이런 가벼운 맥락으로 이해하면되는데 뭔, 모든 과정이 프로그래밍 아니냐? 이런식으로 말꼬리나 물고늘어지는데, 내가 뭐라고 이해시켜야 되는지 모르겠네? 니 말대로면 사업부나 기획에서 작업하는 모든것도 프로그래밍으로 퉁쳐하는 포괄적인 개념이 되어버림

[익명(183.100)]

한표 던지자면 프로그래밍이란 단어는 포괄적인 개념이 맞다고 생각하는바

[익명(222.99)]

똑같이 건들지만 그게 더 쉽다는 보장이 없으니까 하는말이지.. 절차지향이 객체지향보다 무조건 어렵다는 보장이 없다고.. 너가 저 유동임? 적당히 이해선에서 넘어가도 될 문제를 계속 말꼬리물고늘어지네

[익명(222.99)]

객체지향에서 특정 목적에만 활용되는 코드를 다양한 목적에도 대응되게끔 메타 프로그래밍이 나왔는데, 니 논리대로면 개나소나 STL갖다 쓰니까 템플릿 메타 프로그래밍이 객체지향보다 더 쉬운게 됨?

[익명(222.99)]

STL에서 컨테이너 주구장창 갖다쓴다고 객체지향보다 템플릿 메타 프로그래밍이 더 쉬워? 이건 애초에 쉽고 안쉽고 문제가 아니라 서로가 추구하는 장단점에 상쇄되는 개념이라니까?

[익명(222.99)]

절차지향이 객체지향보다 단순 프로그래밍을 하는데는 가볍게 접근이 가능하지만 재활용이 어렵다는 단점이 있는 반면에 객체지향은 처음에 구조를 짤 땐 어렵지만 나중에는 다시 활용하기 편한, 이렇게 서로의 장단점을 상쇄하는거라고.. 이걸 이해를 못하냐?

[익명(222.97)]

프밍 쉽게 하려고는 좀 부족하긴 함

[익명(222.99)]

너처럼 일차원적으로 사고하는 애들이 딱 하나의 장점만 보고 절차지향은 쓸모없다는둥 더 불편하다는둥 고정관념갖는데, 프로그래밍은 어떤 패러다임으로 작업하든 똑같이 어려워. 목적만 다를 뿐이지. 수단과 방법을 가리지않고 다양하게 활용할 생각을 해야지

[익명(183.100)]

난 고닉없음 그냥 개인의견 이긴한데 175게이는 좀 쉽다 라는 단어에 대해서 너무 뜻을 하나로 한정지어서 말하는거 같음 여기 다들 너가 뭔 말하는지는 앎 객체지향으로 코드 짜는것과 절차지향으로 짜는것 난이도는 일반화 할수 없고 각기 다르기때문에 쉽다라고 단정지을수 없다 가 너의 의견인거 같은데 단순히 그건 프로그래밍의 한 과정이라고 보고 전체적 프로그래밍으로 따지면 모든 과정들을 종합해보았을때 이득이 있으니까 다들 절차지향에서 객체지향으로 갔을거 아니야 그걸 미루어 보았을때 쉽게 하다=> 편하게 하다=> 사용하기 용이하다 정도로 받아드리면 될거같은데

[익명(222.97)]

틀린 답이라기보단 그 설명만으론 부족한듯

[익명(222.99)]

마지막으로 이야기하자면, 밑단에서 설계할 때, 프로그래머가 객체지향으로 모듈화해서 컴포넌트처럼 만드는 과정이랑, 그런 모듈화나 컴포넌트를 갖다 쓰면서 편한거랑은 다르다고 생각함

[익명(222.99)]

한마디로 말해서 객체지향을 잘 모르는 사람이 쓰기 편하도록 다 추상화나 캡슐화해놓고 배포해놓은 라이브러리를 사용한다고 객체지향 프로그래밍이 쉽다고 볼 수 없는거임. 애초에 절차지향보다 객체지향이 더 쉽다는게 논지니까 각각의 난이도를 비교하자면 그렇다는거지

[익명(222.99)]

너가 멍청하게 일차원적으로 해석하니까 그렇지 더 풀어서 이야기해줘? 내가 가령, 프로그래밍을 1달 배운 사람도 편하게 모델링을 할 수 있도록 C++로 파이프라인 잡아주고 관련 고급언어로 인터페이스를 랩핑해서 제공했다 치자, 그걸 사용하는 사람은 프로그래밍을 하는게 쉬워졌겠지만, 그렇다고 객체지향 프로그래밍이 쉽다는 의미는 아니잖아?

[익명(222.99)]

이렇게까지 이야기해줘도 이해못하면 그냥 포기할게. 니 말이 맞다

[익명(222.99)]

참고로 난 고닉 댓글에만 초점맞추고 대댓단거라 다른분들 의견에 이야기하는건 아님. 진짜 자러감 ㅂㅂ 반박시 니 말 맞다고 할게

[익명(211.197)]

4번은 나도 동의하기 어렵네 유지보수가 뭐임 기능추가 버그잡기 아님? 결국 코드수정하고 리펙토링하고 새로운 코드짜는 행위 = 프로그래밍임. 결국 유지보수용의=프로그래밍이쉬움이 되는거지. 그리고 재활용? 덩어리코드? 협업용의? 절차지향에서도 파일나누고 git만 잘쓰면 되는건데 이건 패러다임이랑 큰상관 없는 말인듯

[익명(222.99)]

위에 어떤 고닉이 병림픽 벌여놔서 나도 주절주절댔으니까 그거 읽어봐.. 난 자야되서 슬슬 발빼겠음

[익명(211.197)]

왜 처음 설계할때 코딩하는건 프로그래밍인데 유지보수를 위해 코드를 만지는 행위는 프로그래밍이라 생각안하는지 궁금하네. 프로토타입만 만들고 출시를 한번도 못해봐서 그런거아님?

[익명(211.197)]

내가 가령, 프로그래밍을 1달 배운 사람도 편하게 모델링을 할 수 있도록 C++로 파이프라인 잡아주고 관련 고급언어로 인터페이스를 랩핑해서 제공했다 치자, 그걸 사용하는 사람은 프로그래밍을 하는게 쉬워졌겠지만, 그렇다고 객체지향 프로그래밍이 쉽다는 의미는 아니잖아? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ >> 객체지향을 통해 프로그래밍이 쉬워졌지.