Skip to content
This repository has been archived by the owner on Feb 4, 2023. It is now read-only.

pnu refactoring project by team 9 #964

Open
wants to merge 48 commits into
base: master
Choose a base branch
from

Conversation

HyeonSeong-P
Copy link

pnu refactoring project by team 9

HyeonSeong-P and others added 30 commits May 21, 2022 13:06
박현성_리팩토링_pull request
1. BlacklistFolderChooserDialog
2. Introduce Explaining Variable
3. IF문의 조건들을 다른 개발자가 이해하기 쉽게 만들기 위해서입니다
1. AddToPlaylistDialog
2. Extract Method
3. 한 메서드 안에 메서드 이름과 다른 동작을 하는 부분이 있고 메서드 길이가 길어져 extract method를 해주었습니다.
1.BlacklistFolderChooserDialog, ScanMediaFolderChooserDialog, ChooserDialog
2. Extract Superclass, Encapsulate Field
3. 먼저 두 클래스 간의 공통되는 메서드가 많아 Extract superclass를 해주었습니다. 그리고 superclass의 필드는 encapsulation을 위해서 private으로 두고 getter/setter 메서드를 만들어 적용했습니다.
1. ChangelogDialog
2. Extract Method
3. onCreateDialog라는 메서드 안에 webview를 로드하는 로직이 길게 작성되어 있어 메서드 길이를 줄이고 다른 개발자가 이해하기 쉽게 만들기 위해 적용했습니다.
1. CreatePlaylistDialog
2. Extract Method
3. onCreateDialog 메서드 안에 노래들을 플레이리스트에 추가하는 로직이 작성되어 있어 메서드 길이를 줄이고
다른 사용자가 이해하기 쉽게 만들기 위해 Extract Method를 적용했습니다.
1. DonationsDialog
2. Rename 
3. 안드로이드엔 리사이클러뷰라는 컴포넌트 관련 클래스로 이미 ViewHolder가 존재하는데 안드로이드 개발자라면 모호하게 생각할 수 있을 거 같아 어떤 뷰의 홀더인지 정확히 나타내기 위해  Rename을 해줬습니다.
1. SongDetailDialog, ScanMediaFolderChooserDialog,
2. Extract Method, Introduce Explaining Variable
3. 먼저 Extract Method의 경우 dialogView를 구성하는 로직 중 SongFile과 Song으로 view를 그리는 부분이 나뉘어 있기도 하고 이 때문에 한 메서드 안에 너무 많은 코드가 작성되어 있어 메서드 길이를 줄이고 다른 개발자가 이해하기 쉽게 만들기 위해 적용했습니다. 
Introduce Explaining Variable은 if문 안의 조건을 다른 개발자가 이해하기 쉽도록 만들기 위해 적용했습니다.
1. SleepTimerDialog
2. Extract Method
3. createDialog라는 메서드 안에는 dialogview의 버튼들을 누를 때 각각의 로직이 존재하는데 이들이 한 메서드 안에서 길게 작성되어 있고 하는 동작(sleep timer setting, cancel sleep timer)도 뚜렷하여 각각 Extract method를 적용하여 메서드 길이도 줄이고 다른 개발자가 이해하기 쉽게 만들었습니다.
refactoring by 박현성( commit 내용 수정 )
showListener를 Extract method를 활용하여 이 코드를 별도의 새 메서드(또는 함수)로 옮기고 이전 코드를 메서드 호출로 바꿉니다. 또한 CSS를 Hex로 바꾸어 문자열 내장 메서드를 줄였습니다.
CreatePlayListDialog 클래스 리팩토링 by Alikhan
201624491 변기수 리팩토링
All refactored files for now. by Alikhan
1. CalendarUtil
2. Singleton Pattern
3. 앱을 develop시키다 보면 CalendarUtil이 후에 여러 곳에서 사용될 가능성이 있다고 생각하여 이를 매번 새로운 instance로 생성하여 사용하는 것은 불필요하다고 판단되어 프로젝트 내에서 단 하나의 인스턴스로 CalendarUtil을 사용할 수 있도록 Singleton Pattern을 적용했습니다.
HyeonSeong-P and others added 18 commits May 27, 2022 14:28
All classes refactored for now.
1. AbsPlayerFragment, DialogFactory(새로 생성한 클래스)
2. Factory Method Pattern, Singleton Pattern
3. AbsPlayerFragment에 새로운 Dialog가 추가된다면 OCP가 위반되는 부분이 있어 이에 Factory Method Pattern을 적용시켰고 새로 생성한 팩토리 클래스는 AbsPlayerFragment를 상속받은 Fragment들이 생성될 때마다 인스턴스를 생성하는 것보다 하나의 인스턴스를 두고 사용하는 게 더 좋다고 판단하여 Singleton Pattern을 적용시켰습니다.
title 클래스를 객체를 만들어내는 부분을 서브 클래스(SUB-CLASS)에 위임하는 패턴
즉 new 키워드를 호출해 객체를 생성하는 역할을 서브 클래스에 위임하는 것입니다.  결국 팩토리 메소드 패턴은 객체를 만들어내는 공장을 만드는 패턴이라 할 수 있습니다.
팩토리 메소드 패턴에서는 인스턴스를 만드는 방법을 상위 클래스 측에서 결정하지만 구체적인 클래스명 까지는 결정하지 않습니다.
구체적인 내용은 모두 하위 클래스 측에서 수행합니다. 따라서 인스턴스 생성을 위한 골격(framework)과 실제의 인스턴스 생성의 클래스를 분리해서 생각할 수 있습니다.
객체를 만들어내는 부분을 서브 클래스(SUB-CLASS)에 위임하는 패턴
즉 new 키워드를 호출해 객체를 생성하는 역할을 서브 클래스에 위임하는 것입니다.  결국 팩토리 메소드 패턴은 객체를 만들어내는 공장을 만드는 패턴이라 할 수 있습니다.
팩토리 메소드 패턴에서는 인스턴스를 만드는 방법을 상위 클래스 측에서 결정하지만 구체적인 클래스명 까지는 결정하지 않습니다.
구체적인 내용은 모두 하위 클래스 측에서 수행합니다. 따라서 인스턴스 생성을 위한 골격(framework)과 실제의 인스턴스 생성의 클래스를 분리해서 생각할 수 있습니다. 현재 playlistNames 클래스를 아래쪽에 빼서 추가로 지정해주는 복잡한 방식을 가지고 있는데 이 부분을 하위 클래스에서 구현함. 또한 기존의 itemsCallback을 onSelection으로 쪼개서 구분하기 쉽게 만들음.
201624491 변기수 디자인 패턴
201624491 변기수 디자인 패턴
201724636 Alikhan Design Pattern
/**
     * Purpose: to confirm Singleton Pattern
     * Input: getInstance dialogFactory1:()->DialogFactory, dialogFactory1:()->DialogFactory
     * Expected:
     *      dialogFactory1 = dialogFactory2
     */
    @test
    public void testGetInstance() {
        System.out.println("test start");
        DialogFactory dialogFactory1 = DialogFactory.getInstance();
        DialogFactory dialogFactory2 = DialogFactory.getInstance();
        Assert.assertEquals(dialogFactory1,dialogFactory2);
    }
/**
     * Purpose: to confirm Singleton Pattern
     * Input: getInstance calendarUtil1:()->CalendarUtil, calendarUtil2:()->CalendarUtil
     * Expected:
     *      calendarUtil1 = calendarUtil2
     */
    @test
    public void calendarUtilTestGetInstance() {
        System.out.println("test start");
        CalendarUtil calendarUtil1 = CalendarUtil.getInstance();
        CalendarUtil calendarUtil2 = CalendarUtil.getInstance();
        Assert.assertEquals(calendarUtil1,calendarUtil2);
    }
/**
     * Purpose: to verify leap year
     * Input: getDaysInMonth (2024,2) -> days in that month/year
     * Expected:
     *      (2024,2) = 29
     */
    @test
    public void testLeapYearGetDaysInMonth() {
        int februaryDays = CalendarUtil.getInstance().getDaysInMonth(2024, 2);
        Assert.assertEquals(29,februaryDays);
    }
/**
     * Purpose: to verify leap year
     * cf. month parameter value is needed to minus 1
     * Input: getDaysInMonth (2024,1) -> days in that month/year
     *        getDaysInMonth (2023,1) -> days in that month/year
     * Expected:
     *      (2024,1) = 29
     *      (2023,1) = 28
     */
    @test
    public void testLeapYearGetDaysInMonth() {
        int februaryDaysInLeafYear = CalendarUtil.getInstance().getDaysInMonth(2024, 1);
        Assert.assertEquals(29,februaryDaysInLeafYear);

        int februaryDays = CalendarUtil.getInstance().getDaysInMonth(2023, 1);
        Assert.assertEquals(28,februaryDays);
    }
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants