Entity class , Boundary class , Control class and other classes
In the Object-oriented, the Entity class is the most basic. But, of course, there are other type classes.
In this page , I will explain the Entity class in the BCE pattern 1. And , I will explain about other type classess ( for example, feature and so on ).
In addition, I will explain easily the class 2 excluding the BCE pattern.
1: If you don't know the BCE pattern , please search "BCE model" , "BCE pattern" or "robustness analysis" in the Google.
By the way, the "B" of the "BCE" means "Boundary" , the "C" means "Control" , the "E" means "Entity".
And , the "C" of the BCE pattern is not the "C" of the MVC pattern. Please pay attention.
2: The number of "Classes except the BCE pattern" cannot be counted.
Because , it is very a lot , and the type of class is defined freely by a designer 3.
Therefore, in this page , I explain only the classes that I know.
3: If you stady the UML , have you heard "Stereotype"?
I explain about the class excluding the BCE pattern.
Here, I explain the class that is extracted when classifying it by the function of the class.
I explain about not the class classified by difinition type ( for example the Abstract class , Concrete class 1 , Interface class and so on ) but the class classified by function.
This class is a class like java.lang.Math.
This class offers only static methods, and this class is not able to create instances.
In a class diagram , there are cases that the stereotype 2 (<<utility>>) is added.
In Excel VBA and VB6.0 , this class is defined by the standard module.
I eplain the merit in which class is separated like Entity and Boundary and Control classes, etc.
Not separating is fewer programming source code than separating. Therefore, in only the programming process, not separating may be better. But, in the test process , separating is better.
The followings are the merits in which class is separated.
Because one class is small, the readability of the class is better. The module cohesion is too.
It becomes easy to recycle.
If the Boundary and Control are in one class, for example, when screen becomes unnecessary ( changing to batch process ) , the class are not be reused.
The influence of the change by the specification change can be suppressed.
Frequency in which the change is received is different in the Boundary, the Control, and the Entity. The possibility that the Entity receive changes most is low, and the Boundary is the highest.
The influence when changing can be reduced by dividing a point where the possibility of the change is high and a low point.
Separating becomes more testability.
The test is not an end when doing once. There are a lot case that the Regression testing is done.
Moreover, you should divide the part where the test is automated easily and the part not done easily.
I explain about the direction of the Association and Dependency.
When there are 2 classes, one class may use another class or may have an object of another class.
Though it is natural, About the direction of the Association and Dependency
Class that changes easily --> Class that doesn't change easily
is the best (The class that changes easily uses the class that doesn't change easily) .
The change frequency of the Entity , Control and Boundary is :
Therefore, the Entity must not use the Control class and must not have the object of the Control class.
If you need ... , please use Event 1 ( for example , in Java language , listener class ).
1: In VBA ( Version 6 and more ) , Event statement is supported. If the version of the VBA is 5 , it is not supported.
In Java language, the Observer pattern is used.
I doesn't assume the responsibility of any damage that occurs because of the use of this page.
Microsoft ,Windows ,Visual Basic and Excel are registered trademarks of Microsoft Corporation in the United States and other countries.
Visual Basic® for Applications may represent a VBA.
Mac ,Mac OS ,Mac OS X ,AppleScript are trademarks of Apple Inc., registerd in the U.S. and other countries.
UML ,Unified Modeling Language and CORBA are trademarks of Object Management Group Inc. in the U.S. and other countries.
Google is trademarks of Google Inc.
Other brands and their products are trademarks or registered trademarks of their respective holders and should be noted as such.
The author of this page and these companies do not have any relationship.