README 리스코프 치환 원칙 (Liskov Substitution Principle) 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다. 이 원칙은 상속하지 말아야할 때를 생각해볼수있다. Rectangle - Square problem 우리회사 시스템에 Rectangle.class가 필요했다고 예를 들자. -> 코드짰다 // Rectangle.class public class Rectangle { private int width; private int height; public void setWidth(int width){ this.width = width; } public void setHeight(int height) { this.height..
README 개방-폐쇄 원칙 (Open-closed principle) 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 기능을 변경하거나 확장할 수 있으면서 (개방)그 기능을 사용하는 코드는 수정하지 않는다. (폐쇄)-> 추상화와 매우 관련깊은 원칙인듯. 자쿰 몸통 / 팔몸통 : Main팔 : 기능 팔에는 개방(Open)몸통은 폐쇄(Closed) 기능 8개 추가 기능 추가시 몸통소스 건드리지말고 팔을 붙였다 뗏다하자~~!! 기능을 몸통에 다넣어버리면 서로 엉키고 엉켜서 한 기능이 다른기능에 의존적이게 짤지도 모릅니다.나중에 어떤 기능을 제거 했을 때 딸려오는 에러(?) 들이 있을지도 몰라요. 최소한 그런 불안감을 가지고 갑니다.코드 가독성..
README 단일 책임 원칙 (Single Responsibility Principle) 객체는 단 한개의 책임만을 가져야 한다. Mission. 한수 Procedure-Oriendted Code import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; class Main { public static void main(String[] args) throws IOException { //입력 BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); final int N = Integer.parseInt(br.readLine(..
README 자바로 문제 풀면서 OOP 정복 가즈아! 안녕하세요. 컴퓨터공학과 학생입니다. 저는 2018년 1월부터 Java로 백준 알고리즘 문제를 풀어왔는데 절차지향적인 사고방식으로 코드를 짜왔습니다. 알고리즘 문제를 풀다보면 절차지향으로 짜도 별 문제가 없었죠 ? (오히려 더 빠릅니다.) 허나, 몇 달이 지나서 문제의 Output이 바뀌어 내 코드를 수정해야 한다면 어떨까요 ? 객체지향프로그래밍(OOP)에 대해 공부하던 중에 어떻게하면 몸소 느낄 수 있을까 생각하다가 이왕 알고리즘 문제 푸는거 객체지향적인 코드로 짜보자 하는 생각이 들었습니다. 어떻게 하면 객체지향스럽게 적용할 지 고민하며 제 나름대로 코드를 짜보고 기록하여 올리는 공간입니다. 저와 같이 알고리즘 문제를 객체지향적으로 구현 하고 싶은..
