저는 몇 개의 다른 회사에서 일해 왔으며, 이제는 클래스와 패키지의 이름을 지정하는 방법에 대한 규칙이 다릅니다. 그것들은 각각 다른 패키지 레이아웃과 클래스 간의 워크 플로우를 가지고 있습니다. 이러한 경험을 통해 프로젝트를 레이아웃하는 방법에 대한 이해를 얻었습니다. 그러나 프로젝트를 레이아웃하는 방법에 대한보다 구체적인 정의를 원합니다. 이 질문은 명명 규칙에 관한 것보다 uml에 관한 것입니다.Java 아키텍처 코딩 규칙
내가 궁금한 점은 다음과 관련하여 공식 아키텍처 정의가 무엇입니까 (필자는 도우미가 유틸리티 및 관리자로 도우미로 사용되는 것을 보았습니다).
:
도우미는 외관이다, 또는 코드/특정 데이터 포맷을 디코딩하고 호출 사이에 상태가 없습니다.
유틸리티는 형식을 코딩/디코딩하거나 IO를 수행하기위한 것이며, 연결을 생성하는 경우 연결을 유지하지 않거나 호출간에 파일을 열어 두는 경우가 많습니다.
관리자는 도우미와 같지만 통화간에 상태가 있습니다.
팩토리는 개체를 가져 오거나 만든 다음 사용자 지정 개체 또는 API 개체를 반환하는 클래스입니다.
간단하고 기본값은 종종 단순히 기본 클래스를 의미합니다.
A 내 "클래스"는 예를 들어 MyApplication 및 MyView (본질적으로 싱글 톤으로 지정)와 같이 프로덕션 코드에서 사용 되기는하지만 사전 비행 아이디어 및 코드 예제의 경향이 있습니다.
이 클래스 이름은 사실상입니다. 이것들은 내가 자주 만들어보고 보는 의미이지만 모순 된 명명 체계와 불일치가 종종 있습니다. 그것들은 형식적인 디자인 패턴 이름이 아니며 실제로이 이름들의 선택은 거의 자의적 인 것으로 보인다. 어떤 사람들은이 이름들 중 하나를 가지고 쓰레드 - 안전하고 다른 클래스들과 다르지 않은 모든 클래스를 브랜드화한다.
종종 "Manager"이름이 객체 나 키와 ORM 유사 기능을 수행하는 클래스 또는 연결을 중재하는 객체에 부여되는 것을 볼 수 있습니다.
편집
나는 프레임 워크로 일반적으로 이러한 주요 객체 가진 기반으로 구축 응용 프로그램을 참조하십시오 스텁을
테스트 가능성을 극대화하고 패키지 이름과 파일 이름보다 인터페이스의 표면적을 최소화하는 데 초점을 맞추고 있습니다. 나는 당신이 당신의 자신의 코를 따라 당신의 프로젝트에 대한 상세한 분류와 명명을해야한다고 생각한다. SCM 목적을 위해 다른 파일로 코드를 분할하는 것은 위의 두 개 이상의 글 머리 기호에 의존하는 공유 파일에 특히 중요합니다.
편집
나는 일상의 문제로 싱글, 플라이급, 복합, 반복자, 유품, 관찰자, 주, 전략을 사용합니다. 내가 facade, proxy, 모듈 사이의 책임 체인 및 UI 코드를 사용합니다. 때때로 복잡한 시스템에서 공장, 프로토 타입 및 빌더를 사용하고 시스템이 특히 복잡 할 때 템플릿과 방문자를 사용합니다. 행동이 복잡 할 때 때때로 어댑터, 브리지, 팩토리, 추상 팩토리, 데코레이터를 사용합니다. 나는 거의 통역사를 사용하지 않으며 어떤 경우에는보다 일반적인 코드를 작성할 수 있도록 중재자를 사용합니다. 나는 개인적으로 GoF 이후에 수업에 이름을 올리는 것을 원하지 않지만 많은 사람들이 매우 행복하다. 좋은 생각이 될 수 있으며 나는 연습에 반대하지 않는다. 매우 유용 할 수 있습니다. 사람들을 행복하게 만들고 특정 상황에서 어떤 일이 일어나고 있는지를 모든 사람에게 분명히 알려주는 것이 좋습니다.
내 응용 프로그램 객체를 Singleton, Composite 또는 ChainOfResponsibilityLink (?)로 호출하면 기분이 좋지 않고 내 네트워크 및 데이터베이스 코드 어댑터를 호출하는 것이 좋지 않아 관리자라고 부르는 느낌 만 들었습니다.GoF, 헬퍼 또는 유틸리티 아래에서 Facades라고 부르면 안되는 것들을 많이 부릅니다. 왜냐하면 그것이 의미하는 바가 더 명확하다고 생각하기 때문입니다.
+1 GoF가 어휘의 문제 일 수있는 IMHO 관리자와 도우미가 반대 인 경우에도 괜찮은 어휘를 제공하기 때문에 +1. – stacker
솔직히 말해서, 나는 무엇을 당신은이 용어의 대부분을 의미합니다. 디자인 패턴에 대해 이야기하고 있다면 Gang of Four 서적 (Design Patterns)에 그들이 사용하는 패턴 각각의 다이어그램이 있다고 생각합니다. 다른 것에 대해 이야기하고 있다면, 당신은 지나치게 복잡해질 수 있습니다.
또한 공식적인 용어가 아닌 공식적인 정의는 어디에서 얻을 수 있습니까?
감사합니다. 나는 당신이 옳다고 생각하고, 다른 것을 고려하기 전에 디자인 패턴을 더 잘 이해해야한다. – slimbo
다른 대답은 PEAA (Enterprise Architecture의 패턴)입니다. Eric Evans의 도메인 기반 디자인. 이 리소스는 입증 된 아키텍처 접근 방식을 설명하며 클래스 이름 지정은 일반적으로 사용되는 패턴의 이름을 기반으로합니다. –
일반적으로 이러한 용어가 많이 쓰이지 만 공식적인 표준은 없습니다. 나는 실제로 이들 중 일부는 나쁜 습관이라고 말하고 싶습니다. 많은 시간 동안 "도우미"와 "매니저"수업은 너무 많이하고 다른 곳에서해야 할 행동에 대한 모든 것을 포착하는 수업입니다.
나는 그것에 정말로 동의한다. 올바른 기능을 어디에 두어야하는지 모르기 때문에 대부분의 사람들이 도우미를 사용하는 것처럼 보입니다. – slimbo
절차 코드를 작성하는 것이 반드시 잘못된 것은 아닙니다. 크기가 조정되면 잘 알려진 문제가 있다는 것입니다. –
"ApplicationManager"및 "Managed the application"의 클래스 설명과 같은 것을 보았을 때 나는 아주 좋아합니다. –
필자가 보았던 것부터, 프로젝트의 패키지 레이아웃은 클래스의 유형 (즉, java.awt.image, java 대신 java.awt.font)이 아닌 코드의 기능에 따라 더욱 중요시됩니다. awt.utils, java.awt.singletons).
나는 다른 사람들에게 다른 것을 의미하기 때문에이 용어의 "공식적인"정의를 찾을 수 없을 것이라고 생각합니다. 이름은 어렵습니다. 궁극적으로 임의적 인 반면, 클래스의 역할을 정확하고 간결하게 설명하는 이름을 갖는 것이 좋은 목표이기 때문입니다. GoF 디자인 패턴 책은 좋은 제안입니다. 자바 중심의 것을 원한다면 Core J2EE Patterns를 확인해 볼 수도있다. 나에게
패키지 이름을 지정하고 해당 패키지에 어떤 유형의 클래스가 존재하는지 결정하는 표준은 실제로 없습니다. 그것은 모두 당신의 선호도와 당신에게 의미있는 것을 기반으로합니다. 그룹 환경에서는 패키지 이름 지정과 각 패키지에 속한 클래스 유형이 일반적으로 합의에 의해 결정에 도달 할 수있는 디자인 회의 중에 결정됩니다. 또는 당신은 단지 통제 괴물을 위해 일할 수 있습니다.
FooManager라는 클래스는 OO 시스템에서 가장 의문스러운 디자인이라고 생각합니다. 그들은 수십 톤의 국가 였고 많은 글로벌 변수가 유지되는 경향이 있습니다.
"아키텍처"와 어떤 관련이 있는지 잘 모르겠다 - "받아 들여지는 정의"에 대해 묻고있는 것처럼 보입니다 –
더 적절한 것으로 다시 제목을 붙이십시오. – slimbo
엄밀히 말하면 아키텍처는 여기에 아무것도 없습니다 (이론적으로!) 사용자 경험이나 제품 설명서 내용을 결정해야합니다. 유지 관리 세부 사항은 제품 경험이나 사용자 노하우의 일부가 아니어야합니다! 정말 디자인입니다.하지만 이것은 건축가 관점에서 볼 때 최소한의 디자인이므로 아키텍처 태그 아래에 그대로 남아있을 수 있습니다. – martinr