# SOLID

17개의 포스트

SOLID 객체지향 5대 원칙

SRP(단일 책임 원칙), OCP(개방-폐쇄 원칙), LSP(리스코프 치환 원칙), ISP(인터페이스 분리 원칙), DIP(의존 역전 원칙)▶︎ 하나의 클래스에는 하나의 책임만 져야 한다.▶︎ 책임이 많으면 코드끼리 결합도를 높일 가능성이 높다. 따라서 다양한 사유로

2020년 10월 19일
·
0개의 댓글
post-thumbnail

📚OOP의 5원칙과 4가지 특성

Object-Oriented Programming 의 줄임말객체 지향 프로그래밍 방식입력을 받아 명시된 순서대로만 처리하고 결과를 내는 방식절차적 프로그래밍 방식의 개선된 형태프로그램을 함수단위로 나누고 함수끼리 호출하는 방식큰 문제를 해결하기 위해 문제를 작은 단위들

2020년 9월 24일
·
0개의 댓글
post-thumbnail

[Design Patterns] SOLID Principles

Definition: There should never be more than one reason for a class to changefocuses on a single functionalityaddresses a specific concernExampleProtoc

2020년 9월 13일
·
0개의 댓글

OCP와 전략 패턴

소프트웨어의 구성 요소(컴포넌트, 클래스, 모듈, 함수)는 확장에 개방되어야 하지만 변경에는 폐쇄되어야 한다. 즉, 기존 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계되어야 한다.전략 패턴을 이용하는 역할 수행필요에 따라 동적으로 구체적인 전략을 바꿀 수 있다

2020년 8월 27일
·
0개의 댓글
post-thumbnail

Swift 개발에 SOLID 적용하기

해당 글은 'SOLID Pirincipels Applied to Swift Development'를 번역한 글입니다. Introduction 개발자로서, 아마 SOLID 원칙을 들어보거나 사용해 본 적이 있을 것이다. Robert C. Martin(Uncle Bob)

2020년 7월 1일
·
0개의 댓글
post-thumbnail

객체지향의 원칙쓰?!

SOLID 원칙에 대한 글이에요 !

2020년 6월 4일
·
1개의 댓글
post-thumbnail

객체지향 5원칙 : SOLID

디자인 패턴에 대해 공부하던 중 예전 소프트웨어 공학 때 배운 객체지향 5원칙(SOLID)에 대해 다시 정리해보기로 했습니다.원칙의 사전적인 의미를 먼저 살펴보면 다음과 같습니다.원칙 (原則)어떤 행동이나 이론 따위에서 일관되게 지켜야 하는 기본적인 규칙이나 법칙.위의

2020년 5월 28일
·
0개의 댓글

Solid의 원칙(객체지향 설계)

Java의 기초 객체지향을 배우면 Solid를 모르면 객체지향에 대해 완벽하게 이해를 한거라고 할 순 없다.Solid는 앞글자를 따서 만든 객체지향 원칙이다.

2020년 4월 9일
·
0개의 댓글

객체지향 5원칙 SOLID

결국 SOLID는 주어진 문제와 해결 방식을 잘 추상화하라는 뜻이다. 추상화는 공통되는 부분을 찾는 행위로서, 코드를 추상화한다는 것은 공통되는 부분은 같은 인터페이스로 묶어서 관리하고 상황마다 다른 부분은 다른 인터페이스로 분리해야 한다는 뜻이다.

2020년 4월 6일
·
0개의 댓글
post-thumbnail

practice - 공연 예약 / 등록 애플리케이션

나는 보통 언어나 프레임워크를 처음 학습한 후 전반적인 기능개발에 관한 실습을 해보기 위해서 '공연 예약/등록 어플리케이션'을 만들어보곤 한다. 그 이유는 이 어플리케이션을 만들기 위해서는 보편적인 CRUD 기능이 존재해야 하고 DB 스키마 설계를 어느정도 신경써야 하

2020년 3월 8일
·
0개의 댓글
post-thumbnail

객체지향 SOLID 원칙 이란?

객체지향에서 SOLID 원칙이란 무엇인가?

2020년 2월 27일
·
2개의 댓글

객체 지향 설계 5원칙 (SOLID)와 SoC

단일 책임 원칙::Single Responsibility Principle 어떤 클래스를 변경해야 하는 이유는 오직 하나여야 한다. 메소드가 단일 책임 원칙을 지키지 않을 경우 나타나는 대표적인 예가 분기 처리를 위한 if문이다. 개방 폐쇄 원칙::Open Close

2020년 1월 31일
·
0개의 댓글
post-thumbnail

RecoFashion - JUnit을 이용한 유닛테스트

들어가기에 앞서 이번 프로젝트에서 중요하게 여겼던 점 중 하나는 백엔드 아키텍쳐에 관한 것이었는데, 객체 지향 SOLID 원칙 및 clean architecture의 기저에 있는 원칙들을 지켜가며 코드를 작성하려고 노력했다. 구조화된 코드를 작성하는 이유는 두 가지이다. 1. 유지 보수 용이성 어차피 혼자 진행하는 프로젝트이고 따라서 전체적인 어플리케...

2019년 12월 2일
·
0개의 댓글
post-thumbnail

project 계획 : 코디 추천 서비스

목표 서비스 패션 코디 추천 서비스 기능 매일 데일리 코디를 추천해준다. 배색 조합 관련 이론을 참고해 사용자에게 상하의 배색 조합 추천 추가로 피부톤, 개인 선호, 지난 날들의 데이터 등을 고려해 종합적인 recommendation 제공 그 날의 날씨를 고려해 입을만한 옷의 종류 추천 상하의 배색 조합을 추천해 주면서 참고할 만한 관련 패션 사진들 띄...

2019년 11월 12일
·
0개의 댓글

[Software Design] ISP (Interface Segregation Principle)

Clients should not be forced to depend upon interfaces that they do not use. > 클라이언트(기능을 사용하는 클래스)는 사용하지 않는 인터페이스(+ 기능, 메소드 등)에 의존하면 안된다. > 《Agile Software Development, Principles, Patterns, and Pract...

2019년 11월 4일
·
0개의 댓글

[Software Design] SRP (Single Responsibility Principle)

책임 로버트 C. 마틴은 책임을 변경하려는 이유라고 정의했다. 변화의 시기와 이유가 같다면 같은 책임 아래 있다고 보는 것이다. 반대로, 한 객체 내에서 변화의 시기, 이유가 다른 부분이 존재한다면 그 객체는 여러 책임을 가지고 있는 것이다. 그에 따라 이렇게 좀 더 알아보기 쉽게 정의할 수 있을 것 같다. > 책임은 객체에 의해 정의되는 응집도있는 ...

2019년 10월 28일
·
0개의 댓글

[Software Design] DIP (Dependency Inversion Principle)

Dependency? 변경에 초점을 맞춤 B가 변경될 때 A가 함께 변경되는 것 클래스 명 메소드 명 구현 이외의 어떤 것이든 변경에 의해 영향을 받을 수 있는 모든 가능성 설계를 어떻게 하느냐에 따라 B의 내부 구현이 변경되더라도 A가 영향을 받지 않을 수도 있음 Class 의존성 연관 관계 인스턴스 생명 주기 동안 영구적으로...

2019년 10월 21일
·
0개의 댓글