I am studying C++ from different sources and I find confusing that sometimes I encounter the term "Non-static member" and sometimes the term "Instance Variable".
For me, they can be used interchangeably as they both refer to members of a class that are different for each instance, and can be only accessed through an instance
I would like to know if these two terms are really synonyms or I am missing something.
"Members" are not just fields/properties of your class, but also the methods in your class. See Working Draft, Standard for Programming
Language C++ - 9.2 Class members:
Members of a class are data members, member functions (9.3), nested types, and
enumerators.
"Instance variables", in most cases the term is used, is used to describe the non static "data members" of a class. So, to answer your question: "Instance variables" are a subset of "non-static members".
Related
I'm trying to learn/understand Rx, specifically RxJS, and keep seeing references to IObservable, IObserver, etc.
Can anyone tell me what the leading I means and/or where it comes from?
From my searching, it looks like the <T> is for the type. If this is wrong or naive, I'd appreciate some clarification on this as well.
Thanks!
In ye olden days of MFC for C++, Microsoft had Hungarian notation down to a very irritating artform, where all concrete classes were prefixed with C and their COM interfaces with I, this does help avoid the conflict where a COM interface and class might share the same name and so muddy your project.
Part of this notation carried over into .NET, except only interfaces kept the I prefix, but classes and other types dropped their Cs. This does make non-interface-heavy code easier to look at, but can cause ambiguity if you begin a class name with a 2-letter acronym beginning with I (as two-letter acronyms must be completely capitalised according to the the .NET style guidelines), but this is rare.
(I note that generic type name placeholders are prefixed with T too, e.g. TKey and TValue in Dictionary).
An example of why this is necessary is when dealing with collections in .NET, if you're building a reusable library and don't want to expose implementation details (e.g. if you use List<T> or T[] as an underlying collection field type), you can use IList<T> or IReadOnlyList<T> which are interfaces. If the interface was simply called List<T> it would conflict with the actual type List<T>, and ReadOnlyList<T> (an interface) might get confused with ReadOnlyCollection<T> (a class).
You might argue that this wouldn't be a problem if classes and interfaces had a different namespace. C does this: struct types and scalars exist in different namespaces, which unfortunately means that every time a struct type name is used, its usage must be prefixed with struct (e.g. a declaration: struct Foo foo). People workaround this by using typedef with anonymous structs, but I feel the end-result is messy (and the Linux kernel coding guidelines prohibit this too).
In Java, however, interfaces are not prefixed with I but instead have class-like names. Whether this is "correct" or "better" is entirely up for debate. C++ does not have interface types, just pure-abstract classes and multiple-inheritance, so the I prefix isn't typically seen at all outside of COM.
I should preface this with saying I come from a Java/Android background which has colored my understanding of the word "member". That said, I'm starting to learn Objective-C and I ran across the isMemberOfClass method and the name confuses me.
I understand that isMemberOfClass returns a Boolean value that indicates whether the receiver is an instance of a given class. However, I don't understand why it is called isMEMBER when it checks if it is an INSTANCE.
Is there something about the language protocol that I don't know that would make sense to name it this? Does member mean something different in Objective-C than it does in Java?
The way I understand the definition of member, it is something a class HAS (method or data), rather than something a class IS (a type).
Can anyone clear this seemingly odd naming convention up for me? Thanks for helping a newbie!
The key note here is that Cocoa (and SmallTalk before it), does not use the word "member" to mean "instance variable" or "function of" or any of the other ways that the word "member" is used in Java or C++. There's a useful paper on SmallTalk from Harry H. Porter III that gives some context:
As mentioned earlier, each object contains zero or more fields. The term "field" is preferable, but other languages use the term "data member" for the same concept. Smalltalk uses the term "instance variable" to mean a field, so we say, "An object contains several instance variables" to mean the same thing as "An object contains several fields" or "An object contains several data members." We will use the terms "field" and "instance variable" interchangeably.
...
In Java or C++, the programmer may add "static data members" and "static member functions" to any class. Smalltalk has a similar ability, although static data members are called "class variables" and static member functions are called "class methods". (Recall that Smalltalk calls normal fields "instance variables" and it calls normal member functions "instance methods".)
In Cocoa, the term "member" is typically used in the context of a collection (see [NSSet member:]). The question being asked by isMemberOfClass: is "is this object a member of the set of all instances of this specific class."
That's not to say isInstanceOfClass: would have been an un-Cocoa-like name. It's just that "member" doesn't have the same meaning here as in some other languages.
The concept of a member as a component of a class (method or data) does not exist in the iOS framework. The framework is also built around verbose and often lengthly method or variable names to promote "added readability" (in quotes because it isn't always necessarily the result).
It easily could be named isInstanceOfClass, but that may have caused some confusion with subclasses. isMemberOfClass just happens to be a simple method name that doesn't collide with any principles of the iOS framework and is quite self explanatory. I don't think the logic extends beyond that.
I believe the term "member" used to denote either an instance variable or a method (sorry, member function) goes back to C++. I personally have never heard it used with Java, but my hearing may not be the best.
Objective-C is pretty much everything C++ is not - and vice versa. Objective-C is historically based on smalltalk and inherits most of that environment's way of doing things. Alan Kay, one of the "inventors" of Smalltalk is quoted as saying "I invented Object-Oriented Programming, and C++ is not what I had in mind", just to illustrate the feelings between the two camps.
So to answer your question: Yes, "member" has a different meaning in Objective-C and C++, and don't be too surprised if you find other words with different meanings as you get deeper into Objective-C.
I'm trying to author documentation for some C++/CX interfaces as XML comments. The result will be parsed by Doxygen as well as by VC++'s own /doc option.
In the documentation for each interface member, I can use <see cref="..."/> syntax to crossreference members of the same interface, as well as to other types that have been forward declared. But what is the proper syntax for referencing a member of a different interface?
All of my attempts produce compiler warnings:
C4638: XML document comment applied to ...: reference to unknown symbol ...
I've seen this question and its answers, but you can't forward declare members of interface classes, can you? And due to circularity, I cannot always make sure to include the declaration of each referenced interface before the one containing the reference.
If the interface were classes, my understanding is that the XML comments could be put on the implementations of the functions rather than their declarations, but for an interface there isn't any implementations of the members that I could move the XML comments to.
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.
I see the word thrown around often, and I may have used it myself in code and libraries over time, but I never really got it. In most write-ups I came across, they just went on expecting you to figure it out.
What is a Class Factory? Can someone explain the concept?
Here's some supplemental information that may help better understand several of the other shorter, although technically correct, answers.
In the strictest sense a Class Factory is a function or method that creates or selects a class and returns it, based on some condition determined from input parameters or global context. This is required when the type of object needed can't be determined until runtime. Implementation can be done directly when classes are themselves objects in the language being used, such as Python.
Since the primary use of any class is to create instances of itself, in languages such as C++ where classes are not objects that can be passed around and manipulated, a similar result can often be achieved by simulating "virtual constructors", where you call a base-class constructor but get back an instance of some derived class. This must be simulated because constructors can't really be virtual✶ in C++, which is why such object—not class—factories are usually implemented as standalone functions or static methods.
Although using object-factories is a simple and straight-forward scheme, they require the manual maintenance of a list of all supported types in the base class' make_object() function, which can be error-prone and labor-intensive (if not over-looked). It also violates encapsulation✶✶ since a member of base class must know about all of the base's concrete descendant classes (now and in the future).
✶ Virtual functions are normally resolved "late" by the actual type of object referenced, but in the case of constructors, the object doesn't exist yet, so the type must be determined by some other means.
✶✶ Encapsulation is a property of the design of a set of classes and functions where the knowledge of the implementation details of a particular class or function are hidden within it—and is one of the hallmarks of object-oriented programming.
Therefore the best/ideal implementations are those that can handle new candidate classes automatically when they're added, rather than having only a certain finite set currently hardcoded into the factory (although the trade-off is often deemed acceptable since the factory is the only place requiring modification).
James Coplien's 1991 book Advanced C++: Programming Styles and Idioms has details on one way to implement such virtual generic constructors in C++. There are even better ways to do this using C++ templates, but that's not covered in the book which predates their addition to the standard language definition. In fact, C++ templates are themselves class factories since they instantiate a new class whenever they're invoked with different actual type arguments.
Update: I located a 1998 paper Coplien wrote for EuroPLoP titled C++ Idioms where, among other things, he revises and regroups the idioms in his book into design-pattern form à la the 1994 Design Patterns: Elements of Re-Usable Object-Oriented Software book. Note especially the Virtual Constructor section (which uses his Envelope/Letter pattern structure).
Also see the related answers here to the question Class factory in Python as well as the 2001 Dr. Dobb's article about implementing them with C++ Templates titled Abstract Factory, Template Style.
A class factory constructs instances of other classes. Typically, the classes they create share a common base class or interface, but derived classes are returned.
For example, you could have a class factory that took a database connection string and returned a class implementing IDbConnection such as SqlConnection (class and interface from .Net)
A class factory is a method which (according to some parameters for example) returns you a customised class (not instantiated!).
The Wikipedia article gives a pretty good definition: http://en.wikipedia.org/wiki/Factory_pattern
But probably the most authoritative definition would be found in the Design Patterns book by Gamma et al. (commonly called the Gang of Four Book).
I felt that this explains it pretty well (for me, anyway). Class factories are used in the factory design pattern, I think.
Like other creational patterns, it [the factory design pattern]
deals with the problem of creating
objects (products) without specifying
the exact class of object that will be
created. The factory method design
pattern handles this problem by
defining a separate method for
creating the objects, which subclasses
can then override to specify the
derived type of product that will be
created. More generally, the term
factory method is often used to refer
to any method whose main purpose is
creation of objects.
http://en.wikipedia.org/wiki/Factory_method_pattern
Apologies if you've already read this and found it to be insufficient.