높은 응집력이란 무엇이며 어떻게 사용 / 만드는가?
저는 컴퓨터 프로그래밍을 배우고 있으며 여러 곳에서 응집의 개념을 우연히 발견했으며 소프트웨어가 "고 응집력"을 갖는 것이 바람직하다는 것을 이해합니다. 그러나 그것은 무엇을 의미합니까? 저는 색인에 포함되지 않고 응집력을 언급하는 책 C ++ 입문서에서 C ++를 배우는 Java, C 및 Python 프로그래머입니다.이 주제에 대한 링크를 알려 주시겠습니까? 컴퓨터 과학 응집력에 관한 위키피디아 페이지는 정보를 얻지 못했습니다. 단지 정 성적 측정이라고 말하고 실제 코드 예제를 제공하지 않기 때문입니다.
높은 응집력은 잘 정의 된 작업을 수행하는 클래스가있는 경우입니다. 낮은 응집력은 수업이 공통점이 많지 않은 많은 일을 할 때입니다.
이 예를 들어 보겠습니다.
두 개의 숫자를 더하는 클래스가 있지만 동일한 클래스가 결과를 표시하는 창을 만듭니다. 이것은 창과 추가 작업이 공통점이 많지 않기 때문에 응집력이 낮은 클래스입니다. 창은 프로그램의 시각적 부분이며 추가 기능은 그 뒤에있는 논리입니다.
응집력이 높은 솔루션을 만들려면 Window 클래스와 Sum 클래스를 만들어야합니다. 창은 Sum의 메서드를 호출하여 결과를 가져와 표시합니다. 이렇게하면 애플리케이션의 로직과 GUI를 별도로 개발할 수 있습니다.
Steve McConnell의 Code Complete 에서 설명 :
응집력은 클래스의 모든 루틴 또는 루틴의 모든 코드 가 중심 목적 을 얼마나 밀접하게 지원 하는지를 나타냅니다 . 밀접하게 관련된 기능 을 포함 하는 클래스는 강력한 응집력을 갖는 것으로 설명되며 휴리스틱 목표는 응집력을 가능한 한 강력하게 만드는 것입니다. 응집력은 복잡성을 관리하는 데 유용한 도구입니다. 클래스에 더 많은 코드가 중심 목적을 지원할수록 두뇌는 코드가 수행하는 모든 것을 더 쉽게 기억할 수 있습니다.
Uncle Bob의 Clean Code 에서이를 달성하는 방법 :
클래스에는 적은 수의 인스턴스 변수 가 있어야 합니다 . 클래스의 각 메서드는 이러한 변수 중 하나 이상을 조작해야합니다. 일반적으로 메서드가 더 많은 변수를 조작할수록 해당 메서드는 클래스에 대해 더 응집력이 있습니다. 각 변수가 각 메서드에서 사용되는 클래스는 최대한 응집력이 있습니다.
일반적으로 이러한 최대로 응집력있는 클래스를 만드는 것은 바람직하지도 가능하지도 않습니다. 반면에 우리는 응집력이 높기를 바랍니다. 응집력이 높으면 클래스의 메서드와 변수가 서로 의존적이며 논리적 전체로 함께 연결되어 있음을 의미합니다.
응집의 개념은 결합의 개념과 밀접한 관련이 있습니다. 또한 Single Responsibility Principle (SOLID의 S)이라는 높은 응집력의 휴리스틱 기반 원칙이 있습니다.
높은 응집력은 소프트웨어 엔지니어링 개념입니다. 기본적으로 클래스는해야 할 일만해야하며 완전히 수행해야한다고 말합니다. 하지 말아야 할 함수로 오버로드하지 마십시오. 직접적으로 관련된 것은 다른 클래스의 코드에도 나타나지 않아야합니다.
규모도 고려해야하므로 예제는 매우 주관적입니다. 간단한 프로그램은 너무 모듈화되어서는 안됩니다. 그렇지 않으면 조각화 될 것입니다. 복잡한 프로그램은 복잡성을 처리하기 위해 더 많은 수준의 추상화가 필요할 수 있습니다.
예 : 이메일 클래스. 여기에는 참조, 숨은 참조, 제목, 본문에 대한 데이터 멤버가 포함되어야하며 saveAsDraft (), send (), 폐기 Draft () 메소드를 포함 할 수 있습니다. 하지만 여기에는 많은 이메일 프로토콜이 있기 때문에 login ()이 없어야하며 별도로 구현해야합니다.
응집력은 일반적으로 LCOM (응집력 부족) 메트릭 중 하나를 사용하여 측정되며 원래 LCOM 메트릭은 Chidamber 및 Kemerer에서 제공됩니다. 예 : http://www.computing.dcu.ie/~renaat/ca421/LCOM.html
보다 구체적인 예 : 예를 들어 클래스에 하나의 개인 필드와 세 개의 메서드가있는 경우; 세 가지 방법 모두이 필드를 사용하여 작업을 수행하면 클래스가 매우 응집력이 있습니다.
응집력있는 클래스의 의사 코드 :
class FooBar {
private SomeObject _bla = new SomeObject();
public void FirstMethod() {
_bla.FirstCall();
}
public void SecondMethod() {
_bla.SecondCall();
}
public void ThirdMethod() {
_bla.ThirdCall();
}
}
예를 들어 클래스에 3 개의 개인 필드와 3 개의 메소드가있는 경우; 세 가지 방법 모두 세 필드 중 하나만 사용하면 클래스의 응집력이 떨어집니다.
잘 응집되지 않은 클래스의 의사 코드 :
class FooBar {
private SomeObject _bla = new SomeObject();
private SomeObject _foo = new SomeObject();
private SomeObject _bar = new SomeObject();
public void FirstMethod() {
_bla.Call();
}
public void SecondMethod() {
_foo.Call();
}
public void ThirdMethod() {
_bar.Call();
}
}
한 가지 원칙을 수행하는 클래스 는 Robert C. Martin이 제공 하는 단일 책임 원칙 이며 SOLID 원칙 중 하나입니다 . 원칙은 클래스가 변경할 이유가 하나만 있어야한다고 규정합니다.
Single Responsibility Principle에 가깝게 유지하면 더 일관된 코드를 만들 수 있지만 제 생각에는 두 가지가 다릅니다.
이것은 낮은 응집력의 예입니다.
class Calculator
{
public static void main(String args[])
{
//calculating sum here
result = a + b;
//calculating difference here
result = a - b;
//same for multiplication and division
}
}
그러나 높은 응집력은 클래스의 함수가해야하는 일을 수행한다는 것을 의미합니다 (이름이 지정된 것처럼). 그리고 다른 기능의 일을하는 기능이 아닙니다. 따라서 다음은 높은 응집성의 예가 될 수 있습니다.
class Calculator
{
public static void main(String args[])
{
Calculator myObj = new Calculator();
System.out.println(myObj.SumOfTwoNumbers(5,7));
}
public int SumOfTwoNumbers(int a, int b)
{
return (a+b);
}
//similarly for other operations
}
A general way to think of the principle of cohesion is that you should locate a code along with other code that either depend on it, or upon which it depends. Cohesion can and should be applied to levels of composition above the class level. For instance a package or namespace should ideally contain classes that relate to some common theme, and that are more heavily inter-dependent than dependent on other packages/namespaces. I.e. keep dependencies local.
cohesion means that a class or a method does just one defined job. the name of the method or class also should be self-explanatory. for example if you write a calculator you should name the class "calculator" and not "asdfghj". also you should consider to create a method for each task, e.g. subtract() add() etc... the programmer who might use your program in the future knows exactly what your methods are doing. good naming can reduce commenting efforts
also a principle is DRY - don't repeat yourself
The term cohesion was originally used to describe modules of source code as a qualitative measure of how well the source code of the module was related to each other. The idea of cohesion is used in a variety of fields. For instance a group of people such as a military unit may be cohesive, meaning the people in the unit work together towards a common goal.
The essence of source code cohesion is that the source code in a module work together towards a common, well defined goal. The minimum amount of source code needed to create the module outputs is in the module and no more. The interface is well defined and the inputs flow in over through the interface and the outputs flow back out through the interface. There are no side effects and the emphasis is on minimalism.
A benefit of functionally cohesive modules is that developing and automating unit tests is straightforward. In fact a good measure of the cohesion of a module is how easy it is to create a full set of exhaustive unit tests for the module.
A module may be a class in an object oriented language or a function in a functional language or non-object oriented language such as C. Much of the original work in this area of measuring cohesion mostly involved work with COBOL programs at IBM back in the 1970s so cohesion is definitely not just an object oriented concept.
The original intent of the research from which the concept of cohesion and the associated concept of coupling came from was research into what where the characteristics of programs that were easy to understand, maintain, and extend. The goal was to be able to learn best practices of programming, codify those best practices, and then teach the practices to other programmers.
The goal of good programmers is to write source code whose cohesion is as high as possible given the environment and the problem being solved. This implies that in a large application some parts of the source code body will vary from other parts as to the level of cohesion of the source code in that module or class. Some times about the best you can get is temporal or sequential cohesion due to the problem you are trying to solve.
The best level of cohesion is functional cohesion. A module with functional cohesion is similar to a mathematical function in that you provide a set of inputs and you get a specific output. A truly functional module will not have side effects in addition to the output nor will it maintain any kind of state. It will instead have a well defined interface which encapsulates the functionality of the module without exposing any of the internals of the module and the person using the module will provide a particular set of inputs and get a particular output in return. A truly functional module should be thread safe as well.
Many programming language libraries contain a number of examples of functional modules whether classes, templates, or functions. The most functional cohesive examples would be mathematical functions such as sin, cosine, square root, etc.
Other functions may have side effects or maintain state of some kind resulting in making the use of those functions more complicated.
For instance a function which throws an exception or sets a global error variable (errno in C) or must be used in a sequence (strtok() function is an example from the Standard C library as it maintains an internal state) or which provides a pointer which must then be managed or issues a log to some log utility are all examples of a function that is no longer functional cohesion.
I have read both Yourdon and Constantine's original book, Structured Programming, where I first came across the idea of cohesion in the 1980s and Meilir Page-Jones' book Practical Guide to Structured Systems Design, and Page-Jones did a much better job of describing both coupling and cohesion. The Yourdon and Constantine book seems a bit more academic. Steve McConnell's book Code Complete is quite good and practical and the revised edition has quite a bit to say about good programming practice.
MSDN's article on it is probably more informative than Wikipedia in this case.
참고URL : https://stackoverflow.com/questions/10830135/what-is-high-cohesion-and-how-to-use-it-make-it
'developer tip' 카테고리의 다른 글
| 문자열을 부울로 변환하는 방법 (0) | 2020.10.15 |
|---|---|
| 정규식을 사용하여 문자열이 회문인지 확인하는 방법은 무엇입니까? (0) | 2020.10.15 |
| emacs는 3 개의 짝수 창으로 분할됩니다. (0) | 2020.10.15 |
| 프로그래밍 방식으로 UIView의 고정 높이 제약 조건을 업데이트하는 방법은 무엇입니까? (0) | 2020.10.15 |
| UITextField에서 텍스트 들여 쓰기 (0) | 2020.10.15 |