Can someone please disambiguate class attributes and methods for C++? I was under the impression that attribute means any member variable, and method means any member function.
Thanks
Define "correct".
Referring to data members and member functions as "attributes/properties" and "methods", respectively, is common practice - it's the general OO wording. ("attributes" are used in C++ for something else, though, so this may very well be a source of confusion.)
The C++ standard, however, does not use these terms (apart from attributes of course, as explained above). If you don't want to risk anything and always be correct, use "data members" and "member functions".
But if you only want to explain C++ to a Java programmer, you may get away with "property" and "method" in the beginning.
I would not do that. While it can be understood in the general context of OO, it will be confusing in C++ as attribute has a precise definition in the standard, that is not that of data member.
A class' attributes would translate to its members. A method is not the same as a member function in general. But "In object-oriented programming, a method is a subroutine (or procedure) associated with a class." - Wikipedia.
In common words, an attribute describes something, "One of the attributes of this car is that it's quite long", or "one of the attributes of the giant panda is it's striking black and white colours".
I XML, attributes are used to add extra information in a tag, e.g <species id=3212>Ailuropoda melanoleuca<common_name>Giant Panda</common_name></species> - id is an attribute, Ailuropoda melanoleuca is a value, common_name a tag within species.
But I call the variables in a class "member variables", and functions in a class "member function" or "method".
Related
I've been asked to explain what encapsulation is and I replied "bundling of data and functions that modify this data, is called encapsulation."
The answer was followed by another question—"So, by your definition if I modify a global variable from a member function of a class then the encapsulation is violated."
It made sense to answer YES.
I am not sure whether my explanation is wrong or following question is valid and my answer to it as YES is correct.
Can somebody help.
Quoting from wikipedia:
In programming languages, encapsulation is used to refer to one of two
related but distinct notions, and sometimes to the combination
thereof:
A language mechanism for restricting access to some of the object's components.
A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data
In my humble opinion the answer to the follow up question is subjective and it depends on the interpretation of the notion of encapsulation.
For example it's not a violation if the encapsulating data are limited to be the member variables of classes. A global variable that doesn't belong to an object is accessible by everyone and thus, accessing it via a member function doesn't consist any encapsulation violation.
On the other hand if you consider that encapsulation should be applied to your entire program then this global variable should have been bundled to an object and thus, raw access to it constitutes an encapsulation violation.
The bottom line is that the answer lies in the realms of theology, meaning that it depends on how encapsulation is interpreted by the different programming dogmas.
This depends on how global variable defined and accessed.
Imagine header file containing declaration, but not definitions of member functions, and corresponding implementation file containing class members implementation.
Now consider global variable defined in this header file as internal linkage one (static). Or placed in unnamed namespace. It is a global variable, but functionally it does not differ from private static class member.
It is smelly code, but, I say, that variable is encapsulated properly:
I have been told for my PhD that I have to learn fortran 2003 language. I have never used and OOP program before nor fortran. I am trying to understand what the difference between type and class is. I know that classes are declared with the 'TYPE' keyword but I have also seen examples of the keyword 'CLASS' being used used so I am getting confused. Hope that makes sense.
The keyword type is used to declare derived types -- best not to get into the habit of thinking, perhaps imported from foreign languages, that type is used for declaring something called classes.
The keyword class is used, in restricted circumstances, to mean of the type specified or any of its extended types. extended type is Fortran-speak for a type which extends another type, essentially one which specialises or inherits from another type. The restricted circumstances within which class is used are in procedure dummy-argument lists and in declarations of entities with the attribute allocatable or the attribute pointer. A class entity gets a dynamic type at run-time, and its dynamic type may vary from run to run, or across a single execution of the program.
If you don't understand the explanation in the previous paragraphs it's possibly because I've explained things poorly, but it's also possibly because you don't yet have enough of a grounding in the basics of Fortran. To acquire the grounding find yourself an up-to-date online tutorial, an online reference guide, and start programming.
As a huge fan of C++, there have been a question in my mind. The question is:
The classic book "Modern C++ Design" says: "The library writer cannot provide multiple default values. At best, a class template implementer can provide a single default implementation for each member function. You cannot provide several defaults for a template member function." (see "1.4 The benefit of templates")
What does the author actually mean?
To my understanding, "several defaults" is a paradox phrase. Because "several" explicitly means "multiple" and "default" implicitly means "unique".
Hope to receive some convincing explanations. Thanks in advance.
It just states what you are saying: a developer cannot establish two different values by default for a template member function.
Is there a good reason why should a class function member be part of the class if it does not depend on any of the members of the class?
No. In fact, you should prefer free-functions over member functions. Only functions that really need to operate on the members should be member functions, the rest should use them to provide functionality.
Assuming you mean "does not depend on any non-public members", Scott Meyers once answered a definite no to that question.
However, he focused only on encapsulation: encapsulation is improved by making those functions non-members.
Other considerations can, for example, include that you cannot call operator<< on a temporary if the operator is defined as a non-member. (Why would you ever want to do that? Well, for example to build up a string argument from constituent parts, iostream-style.)
And the considerations can include simply how natural and clear the usage notation is. The notation with nested calls (as for non-members) can be rather annoying and unclear. That's why we have -> as syntactic sugar for * dereferencing + member selection.
So, if you focus only on encapsulation, then move those member functions out of class, as Scott Meyers adviced. And otherwise, make an engineering decision where aspects such as usability and notational clarity are also considered. Anyway, don't fret about it: it's probably not incredibly important. :-)
Cheers & hth.,
If its correlated with the meaning of the class, you should put it together even if it do not use any member of the Class.
The reason it for simply the development, and for a future developer know where to look.
It often happens when overriding a virtual function. If the base class has a pure virtual along the lines of getWidgetCount(), for example, and your derived class doesn't support widgets, it would just return 0.
the most common case concern utility classes for example if i have to develop functions to convert BSTR to string and vice versa , i can create a class with static methods.
it's useful to package functions concerning the same area in the same class, another solution is to package them in the same namespace, but unfortunatly namespaces are not very used even in the well known c++ librairies.
and for other cases adding method to a class with no relation with other members increase the lack of cohesion and the metric LCOM will be high, and the design will be impacted.
I've just been browsing and spotted the following...
When should you use a class vs a struct in C++?
The consensus there is that, by convention, you should only use struct for POD, no methods, etc.
I've always felt that some types were naturally structs rather than classes, yet could still have a few helper functions as members. The struct should still be POD by most of the usual rules - in particular it must be safe to copy using memcpy. It must have all member data public. But it still makes sense to me to have helper functions as members. I wouldn't even necessarily object to a private method, though I don't recall ever doing this myself. And although it breaks the normal POD rules, I wouldn't object to a struct having constructors, provided they were just initialise-a-few-fields constructors (overriding assignment or destructors would definitely be against the rules).
To me a struct is intuitively a collection of fields - a data structure node or whatever - whereas a class is an abstraction. The logical place to put the helper functions for your collection-of-fields may well be within the struct.
I even think I once read some advice along these lines, though I don't remember where.
Is this against accepted best practice?
EDIT - POD (Plain Old Data) is misrepresented by this question. In particular, a struct can be non-POD purely because a member is non-POD - e.g. an aggregate with a member of type std::string. That aggregate must not be copied with memcpy. In case of confusion, see here.
For what it's worth, all the standard STL functors are defined as structs, and their sole purpose is to have member functions; STL functors aren't supposed to have state.
EDIT: Personally, I use struct whenever a class has all public members. It matters little, so long as one is consistent.
As far as the language is concerned, it doesn't matter, except for default private vs. public access. The choice is subjective.
I'd personally say use struct for PODs, but remember that "POD" doesn't mean "no member functions". It means no virtual functions, constructors, destructor, or operator=.
Edit: I also use structs for simple public-access aggregates of data, even if their members aren't PODs.
I tend to use struct a lot.
For the "traditional" OOP classes (the ones that represent a specific "thing"), I tend to use class simply because it's a common convention.
But most of my classes aren't really OOP objects. They tend to be functors, and traits classes and all sorts of other more abstract code concepts, things I use to express myself, rather than modelling specific "things". And those I usually make struct. It saves me having to type the initial public:, and so it makes the class definition shorter and easier to get an overview of.
I also lean towards making larger, more complex classes class. Except this rarely affects anything, because I lean even more towards refactoring large, complex classes... And then I'm left with small simple ones, which might be made struct's.
But in either case, I'd never consider it "evil". "Evil" is when you do something that actively obfuscates your code, or when you make something far more complex than necessary.
But every C++ programmer knows that struct and class mean virtually the same thing. You're not going to be confused for long because you see a struct Animal {...}; You know that it's a class designed to model an animal. So no, it's not "evil" no matter which way you do it.
When I have control over the style guides, everything is defined as a struct. Historically, I wanted all my objects to be one or the other, since I was taught it was undefined behavior to forward declared a struct as a class, and vice versa (I'm not sure if this was ever actually true, its just what I was told). And really, struct has the more reasonable default state.
I still do the same because I've never been convinced of the value of using it as a form of documentation. If you need to convey that an object only has public members, or doesn't have any member functions, or whatever arbitrary line you chose to draw between the two, you have actual documentation available for that. Since you never actually use the struct or class keyword when using the type, you would need to go hunting for the definition anyhow if you want the information. And with everybody having their own opinion on what struct actually means, its usefulness as self-documentation is reduced. So I shoot for consistency: everything as one or the other. In this case, struct.
Its not a popular way of doing things, to say the least. Fortunately for everybody involved, I very rarely have control over the coding standards.
I use a struct whenever I need an aggregate of public data members (as opposed to class, which I use for types that come with a certain level of abstractions and have their data private).
Whether or not such a data aggregate has member functions doesn't matter to me. In fact, I rarely ever write a struct without also providing at least one constructor for it.
You said, "To me a struct is intuitively a collection of fields - a data structure node or whatever". What you are describing is Plain Old Data. The C++ standard does have an opinion of what POD means with respect to C++ language features. I suggest that, where possible, you adopt the meaning of POD used in C++0x.
I need to find a reference for this, but I thought that, as far as type definitions are concerned, the keywords "struct" and "class" are to be synonyms in C++0x. The only difference being that class defaults to private members, while a struct defaults to public. This means that you'll never see complier error messages like "Type X first seen using struct, now seen using class." once we're all using C++0x.
I think that it is wrong to have strict rules on when to use class and when to use struct. If consistency is important to you, the go ahead and make a coding standard that has what ever sort of rules you like. Just make sure everyone knows that your coding standard relates to how you want you code to look - it doesn't relate to the underlying language features at all.
Maybe to give an example where I break all your rules, you say "To me a struct is intuitively a collection of fields - a data structure node or whatever - whereas a class is an abstraction." When I want to write a class that implements some abstraction, I define the interface as a struct with pure virtual methods (egad!) - this is exposed in a header, as too is a factory method to construct my concrete class. The concrete class is not exposed i a public header at all. Since the concrete class is a secret, it can be implemented however I like and it makes no difference to external code.
I'd suggest that if you think that the keywords struct and class have any relation to the concept of POD, then you're not understanding C++ yet.