I would be interested in an elaboration of why it's so meaningful or important whether or not there is a single common root class. Have you seen a langauge where the root class defines actual behaviors that are useful to all possible classes?

In SmallTalk, it seems to me that the root class is a mechanism that allows you to encode algorithms that depend only on the interface to an object, and not on any of its behaviors. It's a nice trick, in that it re-uses semantics related to class hierarchies, thus keeping the language small. But it's a bit of a cheat, since class hierarchies in SmallTalk are supposed to be about shared behavior.

C++ uses a different approach to allow for generic algorithms -- templates. Although templates add new syntax and semantics to the language, it's definitely the right choice given the performance-sensitive applications C++ (vs. SmallTalk) is targetted at.

Java tries to follow in SmallTalk's footsteps, but it doesn't really work well. Lacking templates, a shared interface in Java can only be captured in a common base (interface). Interface inheritance in Java (and C++) doesn't work with primitive types and can't capture many aspects of an object interface, especially when you get into interfaces that defines "geometries" of multiple types rather than "algebras" of a single type. Java muddles through by defining a small common interface in the root class that allows a library of the most common generic containers to be provided. This leaves Java reciting the mantra of Pascal: the problem isn't that you can't do it, the problem is that you want to do it.

> In this interview, C++ creator Bjarne Stroustrup suggests
> C++ programmers can get the most from C++ by avoiding the
> perils of staying too low level and venturing too
> object-oriented in C++ programming style.
>
> http://www.artima.com/intv/goldilocks.html
>
> What do you think of Bjarne's comments?

Dr.Stroustrup's conceptual view is useful and makes practical sense of Classes. Made things more clear .
Thanks Dr.Stroustrup for a great language and the fact you still wear blue jeans.

Sweetspot resolve:
The Sweet spot is formed through the center and gathering or letting go as required from start to the end of the applications runtime but stays in the sweet spot all the while.

The how's I figured. I hope reasonably correct :

Validation:
The sweet spot validation helps to clarify the significance of class construction. Defining the class with this in mind given use makes sense too. Moreso, as the constituients of the class/objects are accounted for, given the task.

Defining class form:
I gathered to define the class in terms of a work shop with a table in the center of it.

Tools you are going to use most of the time and only those for the immediate task at hand at a given time are placed on the table.

Tools which you may use but at different times are on the walls and can be retrieved anytime as required.

Defining requirements of the class
A class is formed where resolve to design is achieved given the requirements of the immediate problem domain.

Other classes:
All other classes can be developed and instanced as needed or as the domain morphs to demand it.

Consider too high or too low level programming:
Resolve undue problems which might otherwise be done
well enough anyway with what the existing class can do already.

Thanks again

Viewpoint

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)

C++ Principle infraction !


In this article it was stated that you do not like data only classes. A struct is better considered for data only requirements.

With this in mind the above example could illustrate the misuse of the class shoe in the shoe store.

Data classes seem a practical sollution and a good consideration in place of a struct though. Is the consideration only semantic as a principle or is there significant resource considerations to evaluate given general (but a specific set) of data requirements?

Argument Statement:
For the shoe store shoe class structs may be a better consideration. Why?

Reasons:
The Shoe store class is a data class which displays information about a shoe. The consideration of a class in this instance may better be handled with a struct.

Functionality of the struct and class
functionality associated with the struct could be better left in a file and called for the struct only as required. A leaner sollution.

A class by definition usually holds functions as well which acts on the data it contains. The instancing of the object of the class would present additonal overhead which is not needed.


Counter Questions to the why considerations?:
B). Could a Data Class not be created in place of a struct. Objects created as required from the class and a function object(s) instanced to service the Data object?

Resolve to question : Semantics and resources
Is there much difference in overhead or other factor with the instancing process of a struct or Data class given this general requirement?

Classes and object by conceptual design seem to work together naturally with more promise than structs. However,regardless of objects as a preference structs do have a good and valued purpose.


Viewpoint

> In this interview, C++ creator Bjarne Stroustrup suggests
> C++ programmers can get the most from C++ by avoiding the
> perils of staying too low level and venturing too
> object-oriented in C++ programming style.
>
> http://www.artima.com/intv/goldilocks.html
>
> What do you think of Bjarne's comments?

My question pertains to Object Oriented style in C++.

I would like to ask Bjarne if an object - oriented resolve
can be made correctly given change factors of his Date example. I include the Bjarnes comments from page 4 bottom paragraph for ease of reference to the problem domain.

Bjarne's comments Start
I've seen the Date problem solved by having a base class Date with some operations on it and the data protected, with utility functions provided by deriving a new class and adding the utility functions. You get really messy systems like that, and there's no reason for having the utility functions in derived classes. You want the utility functions to the side so you can combine them freely. How else do I get your utility functions and my utility functions also? The utility functions you wrote are independent from the ones I wrote, and so they should be independent in the code. If I derive from class Date, and you derive from class Date, a third person won't be able to easily use both of our utility functions, because we have built dependencies in that didn't need to be there.
Bjarne's comments finish.

Viewpoint change considerations:

Question is : I wonder if you might evaluate the following consideration of outside function groupings for class use with inheritance or derived class formatting please.

Date Class:
Date class purpose : To evaluate/display current date of any TimeZone

I Used the Invariant factor to create date class thus clearly defined.

Exact change to consider for class correctness:

If I have 60 functions which can be segregated to 6 groups. Each are premised in context as clearly defined. Is it ok to use these functions to create a class for the purpose of deriving a class with the Date class.

The stipulation is that the 6 groups are clearly defined.

Using the functions as classes derived from groups
// group example is : finding times given ships compass
// group example is : finding times given star positions
// group example is : finding times given sun locations
// extend hypothetical examples to 6 groups 10 functions each.

// Windows application use
Instance the derived classes as required through code in events or text based code processing .

Is there anything wrong with doing this given resources are not a problem.

Thankyou

Viewpoint

> Invariants
> What do you think of Bjarne's comments?

Viewpoint Topic:
Invariants use and dangers to class development.

The Invariant factor is a means of validating the contents of a class. With this factor there is a danger in creating classes which are too large or out of scope with the class definition and purpose.

This is because validation in itself allows for the significance of member functions and variables in a class. With this you may validate that which may be better defined in another class as well as left outside the class as a function.

Therefore the use of Invariant factoring is an integral part but not less important to creating a class than other considerations for defining and developing a class. Moreso, if the class is to achieve definition for use in a clear and correct perspective of the application domain.

An example is : If you have a shoe class defined and it is provisional to an applications purpose it is always a shoe class. Even if other classes which define the shoe can be created they should never replace the class defined if it is has been defined correctly. Other classes which support the shoe in definition can only compliment and be complimented by its design and therefore included or excluded for development use given an applications purpose.


Thankyou for your article.


Viewpoint Stubbs