|
|
Re: The C++ Style Sweet Spot
|
Posted: Feb 17, 2004 10:15 PM
|
|
The Sweetspot of a C++ style. To find if this existed and for the benifet of Mr.Kite with thanks I developed the following Truth test.
Purpose:
To challenge or highlight the significance of class qualification through simplistic C++ techniques as a norm rather than sophisticated techniques as a norm.
The following test of a practical class design was developed to establish the strength or weakness of the concept. Overview as follows.
Classes developed
Class shoe : for a shoe shop, shoe designer and shoe materials chemist lab.
Results:
I was surprised to see what happened. As it turns out Bjarne was righton in a most explicit, useful and practical sense.
Resolve overview:
Class definitions refined is very important. The result
should be a succinct collective of definitions working in harmonic association for the domain written for whether one class or more. Each class can be defined naturally for use in full or in part depending on its purpose.
Conclusion:
Given the results I was very happy to have read and more importantly learned from this article.
To clarify resolve:
Classes are used for different purposes. With this in mind a class in an application should be thought out from the most simplest format first.
Develop one class, another class if needed, and another class if needed.
Call em as needed. If this dosn't work functionality wise then reconsider the use of other available C++ formatting techniques.
The Truth test:
To show the strength and truth of this approach.
Here in this example I have developed 3 levels of class use. I could have used more and still can using the simplist technique noted above.
Consider a class called Shoe within two different levels of possible use. After... watch where the class goes and ask too where else it can go. It is Sweet!
A class shoe for a shoe store and a class shoe for a shoe designer.
You would not write everything about the shoe store business in a shoe class. But you could. A shoe to a shoe store manager is stock and by way of object instantiation the description of any number of shoes ordered.
However,it is just one class as part of the shoe store business.
The shoe store business has other classes as well which define the domain.
Hence, defining -- defining the integral associations as distinctive class entities is important for symetrical (and if the word elegant is functional and not just gloss), elegant functionality.
Besides the above this shoe class may be borrowed from the shoe store and placed in a group or set of classes for a shoe designers shoes as well. That's neat!
Once again the destinction of the class design is for a higher level purpose but is needed as an objective result for the description of the shoes which the shoe designer designs.
Given this how does the shoe designer get this high level class result?
Defines other classes. This is why distinctive class dev is important. Classes can work together.
Class shoe for a shoe designer may be the result of details found in many classes which make up the shoe definition. In this case they are the materials classes of the shoe.
Examples would be found by defining parts of the shoes to get a shoe result.
Soooo- shoe soles, shoe sides, shoe tongue, shoe holes, shoe laces could each be a class. They would be put together later to arrive at the description for the shoe store or also as a reference for the shoe designer.
To define the shoe with as many classes as "IS REQUIRED" to define the shoe "FOR THE SHOE DESIGNER" are the criteria for the classes. Why? The results of materials selection for each class would be a part of the finish design for a proposed shoe for the shoe designer. Wouldn't it? The results would then fit into one Class/ object which is found at the shoe store as well, the shoes description.
Why not just put it all together in one class and hand the class to the shoe store and use the same class for the shoe designer? For the same reason the details of the chemists or physics labs information is not handed to the shoe store. The don't need it. A class like that WOULD be cluttering the mind and hard to manage.
Wouldn't it be better to work on just one part of the shoe at a time ? One way to work with the group of classes using windows would be a group of functions in the application to call 2 or 3 other classes and assign to
a form or dialogs class for informations display as required.
Now extend it to a 3rd level of classes for shoes:
All of the classes of the class designer define various materials found in different shoes.
Each class too is different and can work on their own in a different class setting if there is a requirement. Another advantage of defining the class carefully. It fits in any setting a shoe fits.
Now bring the materials classes of a proposed shoe down to different level. Another set of classes can be be developed in order for the chemist to resolve the quality of the shoe designers shoe design. How about for defining each class at the level of a chemist. This would be the chemical constituents of each material which goes into the shoe.Or physics lab the physical properties of the shoes in action.
Here then the above classes though in different settings help to qualify or serve in each others domain.
The chemist like the shoe designer uses the information of the level above and vice versa to get the the information needed to work with and understand the shoe to be sold.
Interesting : Now you have lateral groups of classes created by a vertical process of a shoe class which started at the shoe store and can be traced all the way to the chemists and physics lab.
A simple approach to resolve a complex domain. Ha. really wonderful.
It looks like this on the map if you can C -|- -|-
So simply put: These three businesses related to the shoe have been handled with distinct and different classes without other formats of class development techniques. Do you agree ?
The point taken by this birdbrain given the format of Dr. Stroustrups is his elaboration towards simplicity in class development the abuse of class development techniques found within the C++ arsenal can muddle things up and offset the object from hitting the sweetspot of better functionality.
Like hitting the tennis racket in other than the sweet spot make the object wobble off its most direct course.
Of course the above approach could also be applied to the
format of code which execute the classes as noted in the main article. I believe similar results would be the norm.
Clearly Thanks again Dr. Bjarne Stroustrup, and C++.
David W. Stubbs (Viewpoint)
|
|
Previous Topic
