1. 상속과 코드 중복 중복 코드는 두 코드가 중복이긴 한지 비교하는것부터 시간을 낭비하게 만들고 동료들을 의심하게 만든다. 그 외에도 중복 코드를 제거해야 할 결정적인 이유는 따로 있다. DRY 원칙 중복 코드가 가지는 가장 큰 문제는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다는 것이다. 중복 여부를 판단하는 기준은 변경이다. 요구사향이 변경됐을 때 두 코드를 한번에 수정해야 한다면 이 코드는 중복이다. 중복 여부를 결정하는 기준은 코드의 모양이 아닌, 코드가 변경에 반응하는 방식이다. DRY는 '반복하지 마라'라는 뜻의 Don't Repeat Yourself의 첫 글자를 모아 만든 용어로 간단히 말해 동일한 지식을 중복하지 말라는 것이다. DRY 원칙 : 모든 지식은 시스템 내에서 단일하고..
1. 책임 주도 설계를 향해 데이터 중심의 설계에서 책임 중심의 설계로 전환하기 위해서는 다음의 두 가지 원칙을 따라야 한다. 데이터보다 행동을 먼저 결정하라 협력이라는 문맥 안에서 책임을 결정하라 데이터보다 행동을 먼저 결정하라 책임 중심의 설계에서는 객체의 행동, 즉 책임을 먼저 결정한 후에 객체의 상태를 결정한다. 협력이라는 문맥 안에서 책임을 결정하라 협력에 적합한 책임을 수확하기 위해서는 객체를 결정한 후에 메시지를 선택하는 것이 아니라 메시지를 결정한 후에 메시지 스스로 객체를 선택해야 한다. 협력이라는 문맥 안에서 메시지에 집중하는 책입 중심의 설계는 캡슐화의 원리를 지키기가 훨씬 쉬워진다. 책임 주도 설계 다음은 3장에서 설명한 책임 주도 설계의 흐름을 다시 나열한 것이다. 시스템이 사용자..
객체지향 패러다임의 관점에서 핵심은 협력, 책임, 역할이다. 역할, 책입, 협력이 제자리를 찾지 못한 상태라면 응집도 높은 클래스와 중복 없는 상속 계층을 구현한다고 하더라도 우리가 만든 애플리케이션이 침몰하는 것을 구원하지 못할 것이다. 그 이유를 살펴보자. 1. 협력 영화 예매 시스템 돌아보기 객체지향 원칙을 따르는 애플리케이션의 제어 흐름은 어떤 하나의 객체에 의해 통제되지 않고 다양한 객체들 사이에 균형 있게 분배되는 것이 일반적이다. 여기서 중요한 것은 다양한 객체들이 영화 예매라는 기능을 구현하기 위해 메시지를 주고받으면서 상호작용한다는 점이다. 이처럼 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력이라고한다. 객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 한다...
https://programmers.co.kr/learn/courses/30/lessons/42583 코딩테스트 연습 - 다리를 지나는 트럭 트럭 여러 대가 강을 가로지르는 일차선 다리를 정해진 순으로 건너려 합니다. 모든 트럭이 다리를 건너려면 최소 몇 초가 걸리는지 알아내야 합니다. 다리에는 트럭이 최대 bridge_length대 올라갈 programmers.co.kr import java.util.LinkedList; import java.util.Queue; class Solution { public int solution(int bridge_length, int weight, int[] truck_weights) { int answer = 0; // 넘어가야 할 트럭의 갯수 Queue start..
import java.util.*; public class Solution { public int[] solution(int []arr) { StringBuilder temp = new StringBuilder(); StringBuilder res = new StringBuilder(); for (int i : arr) { temp.append(String.valueOf(i)); } // 중복 제거 for (int i = 0; i < temp.length(); i++) { if ((i != temp.length() - 1) && (temp.charAt(i) != temp.charAt(i + 1))) { res.append(temp.charAt(i)); } else if (i == temp.length()..
