What is the use case of composable_factory? It seems it is related to m_outer, but I can not find any code calling it (Searched all files in the cppwinrt directory). Many thanks!!!
composable_factory is used for constructing types that allow inheritance. In the Windows Runtime, since base class and derived classes may be in separate components, or even written in separate languages, they use COM aggregation to stitch the base and derived classes together into what appears to be, to the client, a single object. A good example of this would be if you created your own MyButton class that is not sealed / final. It would both compose with Button and be derivable by other classes.
Much like activation_factory, composable_factory serves as a specialized activation factory for instantiating objects while taking a base class to derive from during construction. You can see how that fits together with the inner & outer args here:
https://github.com/microsoft/cppwinrt/blob/c36cf05f5030726c8ada1b89fc78bd470f737032/strings/base_composable.h
I believe m_outer is typically the base class, and inner is the derived.
Ben
Related
What is the difference between these 2 relationships?
Edit: Also if you could provide a simple code example illustrating the difference, that would be really helpful!
I'm trying to give simple examples of the two types of lines.
In the first diagram, the solid line shows an association:
If the classes were declared in Java, this would be like ClassA storing a reference to ClassB as an attribute (it could be passed in to the constructor, created, etc.). So, you might see something like:
public class ClassA {
ClassB theClassB = ...
...
}
In the second diagram, it shows a dependency:
A dependency is much weaker than an association. To quote from UML Distilled:
With classes, dependencies exist for various reasons: One class sends a message to another; one class has another as part of its data; one
class mentions another as a parameter to an operation. [...] You use dependencies
whenever you want to show how changes in one element might alter other elements.
Again, using Java, a couple of examples exist: an argument of type ClassB is passed to a method, or a method declares a local variable of type ClassB:
public class ClassA {
...
public void someMethod(ClassB arg1) {...}
...
public void someOtherMethod() {
ClassB localReferenceToClassB = ...
}
...
}
Other ways ClassA could depend on ClassB without having an association (not an exhaustive list):
ClassB has a static method that ClassA calls
ClassA catches exceptions of type ClassB
Whenever ClassB is modified, ClassA must also be modified (e.g., some logic is shared)
Your question gave me a good chance to learn myself, here is what I found -
Association: Ownership of another type (e.g. 'A' owns a 'B')
//#assoc The Player(A) has some Dice(B)
class Player {
Dice myDice;
}
Dependency: Use of another type (e.g. 'C' uses a 'D')
//#dep The Player(C) uses some Dice(D) when playing a game
class Player {
rollYahtzee(Dice someDice);
}
Here's a crisp ref I found - Association vs. Dependency
This webpage says enough I think
The following text comes from it, but should be enough to understand the difference.
So basically the solid line is an association and the dashed/dotted line is a dependency.
Associations can also be unidirectional, where one class knows about
the other class and the relationship but the other class does not.
Such associations require an open arrowhead to point to the class that
is known and only the known class can have a role name and
multiplicity. In the example, the Customer class knows about any
number of products purchased but the Product class knows nothing about
any customer. The multiplicity "0..*" means zero or more.
A dependency is a weak relationship between two classes and is
represented by a dotted line. In the example, there is a dependency
between Point and LineSegment, because LineSegment's draw() operation
uses the Point class. It indicates that LineSegment has to know about
Point, even if it has no attributes of that type. This example also
illustrates how class diagrams are used to focus in on what is
important in the context, as you wouldn't normally want to show such
detailed dependencies for all your class operations.
Since my reputation is only 8 I can't place the images itself, but they can still be found on the webpage I mentioned at the start.
[EDIT]
I don't have code examples right here, but how I personally would explain it is as simple as a car and a door.
When a car has a door (or more) it's just a car
Car --- has a --> Door
But when you have a door which can be opened the door class will have a function like
public void openDoor(){
this.open();
}
To use the function above the car will have to create an instance of the door
Class Car(){
Door door1 = new Door();
door1.open();
}
In this way you have created a dependency.
So the solid line is just pointing an object(1) to another object(2), but when you start using the object(1) it becomes a dependency.
Okay, since you didn't accept the first answer; let me try.
Arrow 1: A normal association
UML has different types of lines and arrows. Above is the simple association arrow, that means that one class can have a link to the other class. Below I will explain each type WITH code examples.
In the first example, you can see that there isn't really specified who knows who (who is the owner of the relationship). An animal can know the human and the human can know the animal. It's not specified and thus not really helpful for the programmer.
In the second example, the artist can have a guitar. Because there is an arrow and there isn't one on the other side, we know that the guitar doesn't know the artist. A guitar is an object that can totally exist on its own and doesn't need anybody.
In the third example, you see a marriage. Really simple; the husband knows the wife and the wife knows her husband. In our situation, the husband has only one wife and vice versa.
How do we accomplish this usually in code?
class Husband{
Wife bestWomanInTheWorld;
public Husband(Wife theWife){
this.bestWomanInTheWorld = theWife;
}
}
Because the husband always needs a wife, we put the required relationship in the constructor. Because an artist can have a guitar, we would leave the constructor empty like this:
class Artist{
List<Guitar> guitars;
public Artist(){
}
public AddGuitarToCollection(Guitar newGuitar){
Guitars.Add(newGuitar);
}
}
So, that's how we accomplish this in code (most of the time!). You won't usually need different types of lines and arrows if you are new to programming. Keep it simple.
Arrow 2: Dependency
Okay, so we know about normal associations which we will use most of the time. But when will we use the 'dependency' arrow? Well, lets define a dependency (wikipedia):
Dependency is a weaker form of bond which indicates that one class depends on
another because it uses it at some point in time. One class depends on
another if the independent class is a parameter variable or local variable of
a method of the dependent class. This is different from an association, where
an attribute of the dependent class is an instance of the independent class.
Sometimes the relationship between two classes is very weak. They are not
implemented with member variables at all. Rather they might be implemented as
member function arguments.
If there is a connection, relation, association etc. that requires to be present, to the classA to work; it's a dependency. Example: Husband needs the Wife to exist. A car needs a wheel to be a car (and drive). A car factory needs a car class to make an object from it. Your RSSNewsItem class needs an XMLReader class to do anything.
When to use which?
Well, this is the only valid question in my eyes; since google shows alot of valid answers to your question. Try to never use a dependency in a class diagram because it usually means that you aren't specific enough. Always aim for associations, realisations etc. Only use realisations (in my opinion) if there is a required need to use an other class without maintaining a relationship. Example; Utility classes (like the XMLReader).
If you have any questions after reading this full explanation, feel free to ask. :-)
Dotted line indicates dependency to (in the direction of the arrow). Assuming you have assembled your source code neatly into separate files and headers for each class
- the give away is simply that the code includes the line #include ClassB.h.
HOWEVER The fact of the matter is that all class relationships (generalisation, realisation, composition, aggregation, association etc) all inherit the dependency relationship. For this reason I never use dotted arrows when documenting code. Where possible I would aim to document the relationship in more specific terms eg. diamonds, triangles etc. If I don't know the exact relationship my starting point is a solid line with arrows (an association, with (implicit) dependence).
Notwithstanding this the dotted arrow notation can be useful in other aspects of UML modelling eg. showing dependencies to requirements in Use Case analysis for example.
NOTE The Thought Police would have us reduce coupling & dependencies between classes by using interfaces (pure virtual classes) as far as practical.
Whilst pure virtual classes offer the prospect of multiple inheritance and tightest coupling of all between classes as is possible. Interface classes have the advantage that they are made entirely out of dark matter and so totally invisible to the police. With this in mind it is possible to write c++ code with apparently zero coupling between classes -which they love because they never really did understand all those funny looking symbols anyway.
dotted mean implements (an interface)
solid means extends (a base class)
I read quite a lot about the visitor pattern and its supposed advantages. To me however it seems they are not that much advantages when applied in practice:
"Convenient" and "elegant" seems to mean lots and lots of boilerplate code
Therefore, the code is hard to follow. Also 'accept'/'visit' is not very descriptive
Even uglier boilerplate code if your programming language has no method overloading (i.e. Vala)
You cannot in general add new operations to an existing type hierarchy without modification of all classes, since you need new 'accept'/'visit' methods everywhere as soon as you need an operation with different parameters and/or return value (changes to classes all over the place is one thing this design pattern was supposed to avoid!?)
Adding a new type to the type hierarchy requires changes to all visitors. Also, your visitors cannot simply ignore a type - you need to create an empty visit method (boilerplate again)
It all just seems to be an awful lot of work when all you want to do is actually:
// Pseudocode
int SomeOperation(ISomeAbstractThing obj) {
switch (type of obj) {
case Foo: // do Foo-specific stuff here
case Bar: // do Bar-specific stuff here
case Baz: // do Baz-specific stuff here
default: return 0; // do some sensible default if type unknown or if we don't care
}
}
The only real advantage I see (which btw i haven't seen mentioned anywhere): The visitor pattern is probably the fastest method to implement the above code snippet in terms of cpu time (if you don't have a language with double dispatch or efficient type comparison in the fashion of the pseudocode above).
Questions:
So, what advantages of the visitor pattern have I missed?
What alternative concepts/data structures could be used to make the above fictional code sample run equally fast?
For as far as I have seen so far there are two uses / benefits for the visitor design pattern:
Double dispatch
Separate data structures from the operations on them
Double dispatch
Let's say you have a Vehicle class and a VehicleWasher class. The VehicleWasher has a Wash(Vehicle) method:
VehicleWasher
Wash(Vehicle)
Vehicle
Additionally we also have specific vehicles like a car and in the future we'll also have other specific vehicles. For this we have a Car class but also a specific CarWasher class that has an operation specific to washing cars (pseudo code):
CarWasher : VehicleWasher
Wash(Car)
Car : Vehicle
Then consider the following client code to wash a specific vehicle (notice that x and washer are declared using their base type because the instances might be dynamically created based on user input or external configuration values; in this example they are simply created with a new operator though):
Vehicle x = new Car();
VehicleWasher washer = new CarWasher();
washer.Wash(x);
Many languages use single dispatch to call the appropriate function. Single dispatch means that during runtime only a single value is taken into account when determining which method to call. Therefore only the actual type of washer we'll be considered. The actual type of x isn't taken into account. The last line of code will therefore invoke CarWasher.Wash(Vehicle) and NOT CarWasher.Wash(Car).
If you use a language that does not support multiple dispatch and you do need it (I can honoustly say I have never encountered such a situation though) then you can use the visitor design pattern to enable this. For this two things need to be done. First of all add an Accept method to the Vehicle class (the visitee) that accepts a VehicleWasher as a visitor and then call its operation Wash:
Accept(VehicleWasher washer)
washer.Wash(this);
The second thing is to modify the calling code and replace the washer.Wash(x); line with the following:
x.Accept(washer);
Now for the call to the Accept method the actual type of x is considered (and only that of x since we are assuming to be using a single dispatch language). In the implementation of the Accept method the Wash method is called on the washer object (the visitor). For this the actual type of the washer is considered and this will invoke CarWasher.Wash(Car). By combining two single dispatches a double dispatch is implemented.
Now to eleborate on your remark of the terms like Accept and Visit and Visitor being very unspecific. That is absolutely true. But it is for a reason.
Consider the requirement in this example to implement a new class that is able to repair vehicles: a VehicleRepairer. This class can only be used as a visitor in this example if it would inherit from VehicleWasher and have its repair logic inside a Wash method. But that ofcourse doesn't make any sense and would be confusing. So I totally agree that design patterns tend to have very vague and unspecific naming but it does make them applicable to many situations. The more specific your naming is, the more restrictive it can be.
Your switch statement only considers one type which is actually a manual way of single dispatch. Applying the visitor design pattern in the above way will provide double dispatch.
This way you do not necessarily need additional Visit methods when adding additional types to your hierarchy. Ofcourse it does add some complexity as it makes the code less readable. But ofcourse all patterns come at a price.
Ofcourse this pattern cannot always be used. If you expect lots of complex operations with multiple parameters then this will not be a good option.
An alternative is to use a language that does support multiple dispatch. For instance .NET did not support it until version 4.0 which introduced the dynamic keyword. Then in C# you can do the following:
washer.Wash((dynamic)x);
Because x is then converted to a dynamic type its actual type will be considered for the dispatch and so both x and washer will be used to select the correct method so that CarWasher.Wash(Car) will be called (making the code work correctly and staying intuitive).
Separate data structures and operations
The other benefit and requirement is that it can separate the data structures from the operations. This can be an advantage because it allows new visitors to be added that have there own operations while it also allows data structures to be added that 'inherit' these operations. It can however be only applied if this seperation can be done / makes sense. The classes that perform the operations (the visitors) do not know the structure of the data structures nor do they have to know that which makes code more maintainable and reusable. When applied for this reason the visitors have operations for the different elements in the data structures.
Say you have different data structures and they all consist of elements of class Item. The structures can be lists, stacks, trees, queues etc.
You can then implement visitors that in this case will have the following method:
Visit(Item)
The data structures need to accept visitors and then call the Visit method for each Item.
This way you can implement all kinds of visitors and you can still add new data structures as long as they consist of elements of type Item.
For more specific data structures with additional elements (e.g. a Node) you might consider a specific visitor (NodeVisitor) that inherits from your conventional Visitor and have your new data structures accept that visitor (Accept(NodeVisitor)). The new visitors can be used for the new data structures but also for the old data structures due to inheritence and so you do not need to modify your existing 'interface' (the super class in this case).
In my personal opinion, the visitor pattern is only useful if the interface you want implemented is rather static and doesn't change a lot, while you want to give anyone a chance to implement their own functionality.
Note that you can avoid changing everything every time you add a new method by creating a new interface instead of modifying the old one - then you just have to have some logic handling the case when the visitor doesn't implement all the interfaces.
Basically, the benefit is that it allows you to choose the correct method to call at runtime, rather than at compile time - and the available methods are actually extensible.
For more info, have a look at this article - http://rgomes-info.blogspot.co.uk/2013/01/a-better-implementation-of-visitor.html
By experience, I would say that "Adding a new type to the type hierarchy requires changes to all visitors" is an advantage. Because it definitely forces you to consider the new type added in ALL places where you did some type-specific stuff. It prevents you from forgetting one....
This is an old question but i would like to answer.
The visitor pattern is useful mostly when you have a composite pattern in place in which you build a tree of objects and such tree arrangement is unpredictable.
Type checking may be one thing that a visitor can do, but say you want to build an expression based on a tree that can vary its form according to a user input or something like that, a visitor would be an effective way for you to validate the tree, or build a complex object according to the items found on the tree.
The visitor may also carry an object that does something on each node it may find on that tree. this visitor may be a composite itself chaining lots of operations on each node, or it can carry a mediator object to mediate operations or dispatch events on each node.
You imagination is the limit of all this. you can filter a collection, build an abstract syntax tree out of an complete tree, parse a string, validate a collection of things, etc.
I see Java has only one metaclass (the Class class), but other languages, say Smalltalk, have one metaclass for each Class.
Why is that? What's the need for metaclasses? What difference does it make to have them one way or another?
The fundamental need for at least one metaclass is that if you want objects that represent classes (or want classes to be objects), then those objects must have a type.
Wikipedia says:
In early Smalltalks, there was only one metaclass called Class. This
implied that the methods all classes have were the same, in particular
the method to create new objects, i.e., new. To allow classes to have
their own methods and their own instance variables (called class
instance variables and should not be confused with class variables),
Smalltalk-80 introduced for each class C their own metaclass C class.
So the question is, do you want every class object to have the same type (and hence the same members), or do you want class objects to differ in ways that require them to have different types, so that there are type-checked operations which can be performed on the object that represents class A but not on the object that represents class B? Java and early Smalltalks answered that question differently from later Smalltalks.
So for example java.lang.Class.newInstance() takes no constructor arguments, whereas you can imagine that it might be nice to be able to call clz.newInstance(1) where clz is the class object for a class that has a constructor with takes an int. In Java you can still look through the constructors of the class yourself to find a match for the arguments you want to pass, but the type of the class object doesn't tell you whether you will find one.
Also note that Smalltalk stops at one level. The type of C is C class, but the type of C class is Metaclass. There's no infinite recursion of types C class class etc, because although different class objects in Smalltalk accept different messages, there's no demand for different metaclass objects to accept different messages.
Is this a good idea? Instead of create a class with two method (insert and update) and two validation methods (validateInsert and validateUpdate), create three classes: one called ProductDB, another ProductInsert (with methods Insert and Validate) and another ProductUpdate (with same methods of ProductInsert).
Is this more readable, flexible and testable?
PaulG's answer leans more towards the traditional domain object pattern, which I'm not in favor of. Personally, my preference is to have a separate class for each process (like your ProductInsert and ProductUpdate). This is akin to what one sees in the simple bank example where Deposit is a instance of a class as opposed to a method on a BankAccount class. When you start thinking about business processes that have more stuff, like rules and actions to be taken and auditing/persistence of the action itself (say a ProductInsert table to track insertions), the more you realize the business process should be a first class citizen in its own right.
This sounds like a language-independent question. I would just create the one class and call it Product, and have the appropriate methods within the class. Think about what a mess it would be when actually instantiating your separate objects (unless you have static methods).
Also having a concrete Product class will allow you to store object specific information.
Ex:
Product myProduct = new Product()
myProduct.name = "cinnamon toast crunch"
myProduct.price = 3.99
In my opinion have separate classes would make your code a lot less readable and testable.
The word abstract is when we talk about a queue class or any class. A class is abstract right? How's the word abstract used in programming. Somehing that is abstract? What does that mean?
Abstract in OO is used to indicate that the class cannot be instantiated directly and must be inherited from before instantiation. Wiki explains this nicely.
Abstract means that you are discussing an idea one or more levels away from any specific example that you can actually point to or create.
As far as classes are concerned, an abstract class is abstract because it can't be instantiated. A specific class that can be instantiated is concrete, and it may be an example of a certain abstract class.
Similarly, if your data structures class discusses an 'abstract' data type such as a Queue, the teacher means Queue as 'a FIFO data structure'. Slightly less absract is Java's AbstractQueue. A concrete queue that you can "point to" (not in the sense of pointers and memory, but in the sense "THERE is a queue!") could be Java's LinkedBlockingQueue
`Abstract` ... ... ... ... ... ... ... ... ... `Concrete`
a queue AbstractQueue LinkedBlockingQueue
a group an infinite group positive integers
a car a Ford 1995 Ford Taurus My 1995 Ford Taurus VIN# 3489230148230
The term "abstract" can mean a whole bunch of different things, depending on the context.
The two most common uses of "abstract" pertain to object-oriented programming. A method is called "abstract" (or, in C++-speak, "pure virtual") if the method does not have an implementation. The purpose of an abstract method is to indicate that classes that inherit from the given class will all have a method with the given signature, but there is no reasonable default behavior for that method. A common example is, in a class hierarchy of shapes, that the base class for shapes might have an abstract method that draws the shape on the screen. There is no good default behavior for drawing "a shape" - what shape it it? - but any individual shape will have a concrete implementation of this function.
A related term is an "abstract class," which is a class that contains an abstract method. Because the class contains this abstract method, you can't have a concrete object of that class type. Otherwise, if you tried calling the abstract method, you'd find out that there was no implementation associated with it.
In an entire different context, the word "abstract" sometimes shows up in the term "abstract data type," which is a term used to describe an object supporting some set of mathematical operations without necessarily explaining how those operations are implemented. For example, "stack," "queue," and "list" are all abstract data types, since they describe what behaviors are expected of a given type of object without giving implementation (e.g. dynamic array? linked list? hash table?)
The term "abstract" also comes up in "abstraction," which is some simplification of a complex system into something more managable. For example, network routing is usually broken down into a different number of "layers," each of which are responsible for handling some part of the end-to-end communication. Each layer is tasked with a specific job, and must take in input and produce output in a predetermined fashion. This lets programmers work on one layer treat all the other layers as "black boxes" that magically get the job done, since provided that you give input to the layer in the right form or read the output of some layer in a specific manner, you don't need to worry about the details of how that layer works.
Hope this helps!
Well a good example in OO is an Animal, you'd have an abstract class like so:
abstract class Animal
{
public AnimalType Type { get; set; }
}
Now you can't declare an animal outright, you must have a class that inherits from an animal, like a cat:
class Cat : Animal
{
public Cat()
{
Type = AnimalType.Feline;
}
}
So this wouldn't work:
Animal a = new Animal();
But this would:
Animal a = new Cat();
So in essence, what you're saying, is this is a base class, you can't make one on it's own, you need more information, say a class that inherits from it. Kind of hard to explain, so hope the example helps!
Abstract classes cannot be instantiated and instead are inherited from by other classes, generally concrete ones. They usually contain code that is common to inheriting classes to minimize code duplication.
I think it can mean a couple of things related to programming. But, for me, I think of it related to virtual methods, which may perform different tasks depending on the underlying object type. That would be in contrast to a method that always does the same, fixed set of operations.
In fact there are "abstract classes", where one or more methods are pure virtual, which means they are not implemented by that class. Such a class cannot be instantiated. Instead, you must derive a new class from it that implements the pure virtual methods, and then you can instantiate the second class.
Abstraction is a way of building compound objects from simpler ones. A function for example can be seen a form of black box abstraction ..where the inner workings of the function are hidden from the user.
Data abstraction in general is a methodology that enables programmers to isolate how a compound data object is used from the details of how it is constructed from more primitive data objects.