학교생활/소프트웨어디자인패턴
-
디자인 패턴은 주로 세 가지 범주로 나뉩니다:학교생활/소프트웨어디자인패턴 2023. 11. 10. 14:25
1. 생성 패턴 (Creational Patterns): 객체의 생성 메커니즘을 다루는 패턴입니다. 이러한 패턴은 객체가 생성되거나 초기화되는 방식을 캡슐화하고, 시스템이 어떻게 객체를 생성 및 조합하는지에 관한 문제를 해결합니다. 예로는 Singleton, Factory Method, Abstract Factory, Builder, Prototype 등이 있습니다. 2. 구조 패턴 (Structural Patterns): 클래스나 객체를 조합하여 더 큰 구조를 만드는 패턴입니다. 구조 패턴은 시스템의 구조를 구성하는데 도움을 주고, 서로 다른 인터페이스를 갖는 클래스들을 함께 사용할 수 있게 합니다. 예로는 Adapter, Bridge, Composite, Decorator, Facade, Flywei..
-
Strategy Pattern학교생활/소프트웨어디자인패턴 2023. 10. 15. 16:01
Strategy pattern 은 무엇이고 왜 이렇게 하는 것이 중요한가? (예시 - 가격정책) 전략패턴은 ‘확실히 정해진 것이 없기 때문에’ 사용한다. 무엇을 한다는 것은 정해져 있지만, 어떻게 하고자 하는 것에 대해 런타임 도중 동적으로 알고리즘을 선택 할 수 있다. 직접 행위(코드)를 수정하지 않고 전략을 바꿔주기만 함으로써 행위를 유연하게 확장하는 방법이다. 간단히 말해서 객체가 할 수 있는 행위들 각각을 전략으로 만들어 놓고, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴이다. 그래서 새로운 로직을 추가하거나 변경할 때, 한번에 효율적으로 변경이 가능하다. 코드를 일일이 고치지 않아도 된다. 따라서 시스템이 확장되어도 유지보수가 용이하다. Stra..
-
SOLID Principles학교생활/소프트웨어디자인패턴 2023. 10. 13. 11:39
102 - 8. SRP 단일 책임 원칙 SRP(Single Responsibility Principle) 에서 책임(Responsibility) 는 바로 변경에 대한 책임이다! 따라서 클래스를 변경할 때 클래스를 변경하는 이유가 하나만 존재하도록 해야한다. SRP 는 모듈이나 클래스의 변경을 야기하는 응집력과 같은 개념이다. 만약 한 클래스가 하나 이상의 책임을 맡는다면(low cohesion), 한 책임에 대한 변경은 다른 책임을 충족시키는 클래스의 능력을 떨어뜨리거나 저하 시킬 수 있다. 이런 종류의 결합은 변경을 했을 때 예상치 못한 방식으로 잘못 동작하는 취약한 설계를 유발한다. 클래스나 모듈 내에서 비슷한 개념들의 관계는 tight 해야한다. SRP 를 준수해서 변경을 하면 응집도가 높아진다. ..
-
Agile Design학교생활/소프트웨어디자인패턴 2023. 10. 5. 10:25
94 - 7. Agile Team 은 처음 모듈을 설계할 때 변경될 사항을 예상하지 않고 가장 간단한 방법으로 설계한다. 나중에 변경될 요구사항에 대해서는 추가적인 처리를 지금 하지 않는다. 과도한 설계는 오히려 '불필요한 복잡성'을 초래한다. 요구사항이 변경된 다음에야 비로소 탄력적일 수 있도록 모듈의 설계를 바꾼다. 소프트웨어 개발자들은 항상 요구사항의 변화가 있을 수 있다는 것을 염두하여야 한다. Agile 의 설계는 과정에서 일어나는 것이다. 그리고 이것은 시스템의 설계를 간단하고 명료하게 유지하려는 노력이다. 이러한 노력은 어쩌다 한번 이 아닌, 꾸준한 노력이다. 악취를 맡으면 부패되지 않도록, 내버려두지 않는다. 모듈을 탄력적이게 하는 방법으로는 어떤 것이 있을까 추상화는 일반화를 통해 추상클..
-
Overview of XP with Planning, Testing and Refactoring학교생활/소프트웨어디자인패턴 2023. 9. 21. 20:12
익스트림 프로그래밍(영어: eXtreme Programming, XP)는 소프트웨어 개발 방법이다. 이는 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다. 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽힌다. 10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다. XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'이다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해..
-
Software Quality with OOP Concepts학교생활/소프트웨어디자인패턴 2023. 9. 15. 00:06
추상화는 객체들의 공통적인 특징을 뽑아내는 것이다. 객체들의 공통적인 데이터와 기능을 도출해서 추상클래스나 인터페이를 정의한다. Interface(자바에서 ADT)는 미래에 예측할 수 없는 것까지 미리 만들어둬서 flexible 하게 만들 수 있다. 다이나믹하게. maintainability(유지보수성)와 extensibility(기능의 확장성)가 가능하다. 상속은 견고한 연결이다. (Strong Coupling) subclass 는 superclass 구현에 직접적으로든 간접적으로든 영향을 받는다. 기반 클래스의 변화가 모든 파생 클래스에 영향을 주기 때문에, 예상치 못한 요구사항의 대처에 유연하게 대처하지 못한다. 의존성이 강함.
-
Software Quality Models and Philosophies학교생활/소프트웨어디자인패턴 2023. 9. 7. 16:19
다양한 퀄리티 모델 개론 1. 학습 목표 SW 퀄리티와 퀄리티 모델에 대한 의논해본다. '퀄리티' 란 무엇인지 정의한다. 2. 퀄리티란 정의는 크게 두 분류로 나뉜다. 1) Conformance to specification 사양의 적합성 - 사전에 정의한 사양/규정요건을 충족한가? 2) Meeting customer needs 고객 만족도 충족성 - 고객의 합리적이고 구체적인 요구사항을 충족하는가? 예) 레스토랑에 간 상황 [1] 1) 사양의 적합성 - '돈을 좀 아낄 건데..' 이 요구를 충족시킬 음식이었나? 2) 고객 만족도 충족성 - 음식은 맛있었나? 웨이터는 좋은 서비스를 제공했나? 음식은 돈값(혹은 그 이상)을 하는가? 주차공간은 충분했나? 3. 학자들의 의견 3.1. Philip B. Cro..