2010-08-02 3 views
3

저는 OO 원칙을 배우고 있습니다. 연습을 위해 저는 Java로 응용 프로그램을 개발하고 있습니다.OO 설계 관련 문제

응용 프로그램은 모든 포커 손을 플레이 한 후 포커 사이트에서 발행 한 핸드 기록 텍스트 파일을 구문 분석하고 핸드 기록이있는 사이트와 상관없이 파일에서 동일한 유형의 데이터를 추출합니다.

핸드 기록 파일은 포커 사이트에 따라 매우 다른 형식 일 수 있습니다. 일부 사이트는 매우 손에 쥘 수있는 스타일로 각 손을 가지고 있습니다. 예 :

NL $0.25/$0.50 Texas Hold'em - Tuesday, June 22, 19:55:24 GMT 2010 

및 기타는 XML 스타일입니다.

내 질문은 : 위의 줄을 텍스트에서 구문 분석 할 때 각 요소를 구문 분석 할 별도의 클래스가 있어야합니까? 예를 들어, parseStack() 메서드를 사용하여 StakesParser 클래스를 만들고 parseCurrency() 메서드 등을 사용하여 CurrencyParser 클래스를 만들어야합니다. 그렇지 않으면 해당 클래스를 구문 분석하고 모든 정보 비트를 가져올 수있는 단일 클래스를 사용해야합니까?

구문 분석하려는 각 항목에 대해 별도의 클래스를 사용하려면 OO가 더 많지만 효율성은 떨어집니다. 어떤 충고?

파싱 프로세스의 결과로 원하는 것은 포커 한 손으로 모든 정보를 보유 할 GameState 클래스입니다. 따라서 핸드 히스토리 파일이 어떤 사이트에서 왔는지에 관계없이 HHParser 클래스가 파싱 한 모든 관련 정보를 GameState 유형의 객체로 만들 수 있습니다.

이 목적을 위해 각 포커 사이트의 HHParser가 GameState 클래스를 생성하게하는 인터페이스를 구현하는 것이 좋은 생각이라고 생각했습니다. 따라서 인터페이스에는 parseStakes(), parseCurrency() 등의 메서드가 있습니다. 올바른 방법입니까?

다른 사이트에서는 그 정보가 다른 순서로 정보가 다르기 때문에 정보가 다른 사이트에 있으므로 텍스트 파일의 사이트에 따라 각 메서드가 올바른 순서로 호출되는지 확인하는 컨트롤러 클래스가 필요할 수 있습니다 입니다.

와플에 대해 유감스럽게 생각하지만, 최선을 다할 수있는 포인터에 대해 감사드립니다.

미리 감사드립니다. :-)

답변

4

"요소 당 클래스"전략이 너무 세분화되어 있는지 궁금합니다. 특정 사이트에 대해 올바른 파서 구현을 반환하는 일종의 팩토리를 생각하고 있습니다.

public class ParserFactory { 
    public static Parser get(String url) {...}; 
} 

따라서 포커 핸드의 속성을 캡슐화하는 일종의 자바 빈을 반환하는 파서 인터페이스로 끝납니다.

public interface Parser { 
    public Collection<Hand> parse(); 
} 

그리고 당신은 당신이 공장에서 올바른 하나를 반환 손을 얻을 수있는 각 사이트에 대해 파서를 구현합니다.XML 사이트는 Commons Digester이고 비 XML 양식은 ANTLR 또는 정규 표현식을 사용할 수도 있습니다.

+0

감사합니다. jcrossley3. 나는 코드의 많은 부분을 재사용 할 수 없을 것 같은데 "내가 그것을 만들 때"매듭으로 매듭을 짓고 있었다. 내가 그렇게한다면 나는 수천 개의 수업이 나를 혼란스럽게했다. 내가 할 수있는 곳에서 코드를 재사용하려고 노력할 것이지만, 텍스트 파일의 읽기 및 구문 분석과 GameState Java bean 객체 생성을 제어하는 ​​사이트 당 하나의 Parser 클래스를 가질 수있다. 건배. – Joe

+0

설교가 너무 강하지 만, OO는 "수단"이지 "끝"이 아니라는 것을 항상 기억하십시오. OO는 훌륭한 도구이지만, 전기 톱과 마찬가지로 엄청난 파괴가 가능합니다. OO의 가장 까다로운 부분은 추상화의 최적 세분화를 파악하는 것입니다. 물론 도메인 모델의 모든 명사를 하나의 클래스로 추상화 할 수도 있지만 이렇게하면 코드를 유지 관리해야하는 사람들 만 혼란을 겪을 수 있습니다. 사실 그것은 좋은 경험 법칙입니다. 디자인을 괴롭히는 친구가 뒤에서 오는 데 도움이된다고 생각할 때 추상화 (클래스) 만 추가하면됩니다. :) – jcrossley3

+0

또한 IMHO 재사용은 OO의 베스트 셀링 포인트가 아닙니다. 재사용은 어렵지 않으며, OO만으로는 거기에 도달하지 못할 것입니다. OO의 베스트 셀링 포인트는 컴퓨터와 더 중요한 것은 HUMANS가 이해할 수있는 방식으로 의사를 표현할 수있게 해주는 명확성입니다. 행운을 빕니다! – jcrossley3

1

그것은 단지 하나의 데이터 라인이기 때문에 통화, 스테이크 등을 분석하는 단일 파서 개체를 사용하는 것이 좋습니다.이 클래스는 다른 개체를 인스턴스화하여 데이터를 보유 할 수 있습니다.

파서 클래스는 텍스트 데이터를 읽고 거기에서 Java 객체를 생성 할 책임이 있기 때문에 객체 지향 원칙에 위배되지 않습니다. 그리고 각 자바 객체는 프로그램에서 사용할 데이터를 가지고 있어야합니다.

+0

안녕 저스틴. 답장을 보내 주셔서 감사합니다. 간결함을 위해 모든 포커 핸드의 각 핸드 기록이 약 20 줄 정도 길다는 것을 설명하지 않았습니다. 그것은 새로운 손의 시작이라고 말할 라인을 가지고 있습니다. 그러면 원래의 게시물에서와 같은 스테이크가 무엇인지 알려주는 몇 줄의 라인이 생깁니다. 그런 다음 선수가 누구인지와 스택 크기를 설명하는 몇 줄의 라인이 표시 될 것입니다. – Joe

+0

한 줄을 읽는 단일 개체가있는 문제는 다른 사이트의 정보가 다른 순서 또는 다른 줄 또는 XML 형식으로되어 있다는 것입니다. 인터페이스를 구현하고 올바른 유형의 파서를 설치하는 데 필요한 모호한 아이디어가 있지만 현재로서는 마음이 조금 울립니다. – Joe

+0

글쎄, 좋아, 우려를 분리하려면 각 데이터 형식에 대해 하나의 파서 개체가 필요합니다. 따라서 텍스트 파서, XML 파서 등이 있어야 할 것입니다. 물론 각각의 클래스는 여전히 동일한 기본 클래스를가집니다 ... –