The Wikipedia COM article is vague when it comes to this issue.
Can anybody give an explanation that would be suitable for a COM beginner, or article link(s) providing the same.
It helped me to think about it the following way:
A COM class to me is an instance of a class that implements a certain interface. I don't need to know how the implementation is done, as long as it works as expected. Also, a COM class is not language dependent - it's a description of methods.
A Co-Class is an actual implementation that gets instantiated when requesting a COM class.
For example: A COM class could define method to encrypt or decrypt data. There could be two Co-Classes, each for a special encryption algorithm.
coclass is nothing but a type library declaration of a class. There are no assumptions on interfaces implemented by a class (other than perhaps IUnknown, or the class makes no sense), however if a declaration references certain interfaces within the type library, it is expected that real instance would implement those.
To answer your exact question, coclass stands for "component object class"; it is the same thing as "COM class". Your Wikipedia link answers this exactly:
A COM class (coclass) is...
Related
I'm wondering why protocols are used in swift. In every case I've had to use one so far (UICollectionViewDelegate, UICollectionViewDataSource) I've noted that they don't even have to be added to the class declaration for my code to work. All they do is make it such that your class needs to have certain methods in it so that it can compile. Beats me why this is useful other then as a little post it note to help you keep track of what your classes do.
I'm assuming I'm wrong though. Would anyone care to point out why to me please?
A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol doesn’t actually provide an implementation for any of these requirements—it only describes what an implementation will look like.
So it's basically an interface, right?
You use an interface when you want to define a "contract" for your code. In most cases, the purpose of this is to enable multiple implementations of that contract. For example, you can provide a real implementation, and a fake one for testing.
Further Reading
Protocols
What is the point of an Interface?
It allows flexible linkage between parts of code. Once the protocol is defined it can be used by code that doesn't need to know what will be done when the methods are called or exactly what object (or struct or enum) is actually being used. An alternative approach could be setting callbacks or blocks but by using a protocol as complete set of behaviours can be grouped and documented.
Some other code will typically create the concrete instance and pass it to the code expecting the protocol (sometimes the concrete instance will pass itself). In some cases neither the implementation of the code using it need to be aware of each other and it can all be set up by some other code to keep it reusable and testable.
It might be possible to do this in some languages by duck typing which is to say that a runtime inspection could allow a object to act in such a context without particular declaration but this is probably not possible to do at compile time in all cases and it could also be error prone if worked out implicitly.
I'm learning MVP patter. In some examples, I saw this! Any one could demonstrate why programmers use this name convention?
Usually I is there to indicate an Interface. Without the I is it a class. Personally I am not a fan of this. I think it is more common in dot net. I havent seen it too much in Java
Reasons why I dislike:
IDEs now show icons that indicate whether a class is an interface or not.
If I want to change the interface to an abstract class I then have to rename the class
It hurts readability.
'I' stands for interface. It's a common naming convention to distinguish interfaces from classes / structures.
Interfaces are not classes - they define behaviour and classes provide implementation.
Read this article on MSDN for more info: Choosing Between Classes and Interfaces
An interface defines the signatures for a set of members that
implementers must provide. Interfaces cannot provide implementation
details for the members. For example, the ICollection interface
defines members related to working with collections. Every class that
implements the interface must supply the implementation details for
theses members. Classes can implement multiple interfaces.
It is an artifact from age when Hungarian notation was thought to be a good idea. It lets the user know that the name is for an interface.
Also, it is an extremely stupid practice.
Name of the interface should reflect what sort of contract between classes it signifies. It should not tell you to which class it has been tied to.
It should be class PDF extends Document implements Printable because it lets you know that class implements print() method for some reason (in a real world it would be actually a bad API design, but this is an example) instead of class PDF extends Document implements IDocument .. because this tell you nothing.
In Spring MVC, one can define interceptors that can perform work before and after a particular controller is invoked. This can be used, for example, to do logging, authentication etc.
The programmer who wishes to write a custom interceptor is supposed to implement the HandlerInterceptor interface. To aid this task, the HandlerInterceptorAdaptor abstract base class has been provided, which provides default implementations of all the methods specified in the interface. So, if just wants to do some pre processing, one can just extend HandlerInterceptorAdaptor and #Override public boolean preHandle(...), and not worry about implementing the postHandle function.
My doubt concerns the name. From what I understand of the Adapter pattern, it adapts syntactic impedance mismatches between interfaces.
Is that so? If yes, should the class providing the boilerplate implementations be called HandlerInterceptorDefaultImpl, or something along those lines?
Is there a different nomenclature/pattern for what is happening here?
Is the fact that we need a boilerplate class a code smell, and could be removed by refactoring the HandlerInterceptor interface into two: HandlerPreInterceptor and HandlerPostInterceptor? Or is that overkill?
From GOF book about the Adapter pattern:
Adapters vary in the amount of work they do to adapt Adaptee to the Target Interface. There is a spectrum of possible work, from simple interface conversion-for example,changing the names of operations-to supporting an entirely different set of operations. The amount of work Adapter does depends on how similar the Target interface is to Adaptee's.
The boilerplate class that you are referring to is called skeletal implementation class. This is mentioned in Effective Java by Joshua Bloch. From the book:
You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. The interface still defines the type, but the skeletal implementation takes all of the work out of implementing it.
By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement. For example, the Collections Framework provides a skeletal implementation to go along with each main collection interface: AbstractCollection, AbstractSet, AbstractList, and
AbstractMap. Arguably it would have made sense to call them SkeletalCollection, SkeletalSet, SkeletalList, and SkeletalMap, but the Abstract convention is now firmly established.
From the Go documentation on method declarations:
The receiver type must be of the form T or *T where T is a type name. T is called the receiver base type or just base type. The base type must not be a pointer or interface type and must be declared in the same package as the method.
Can anyone give me some insight on why this might be? Are there any other (statically typed) languages that would allow this? I really want to define methods on an interface so I can treat any instance of a given interface type as another. For example (stealing the example from the Wikipedia article on the Template Method Pattern) if the following was valid:
type Game interface {
PlayOneGame(playersCount int)
}
type GameImplementation interface {
InitializeGame()
MakePlay(player int)
EndOfGame() bool
PrintWinner()
}
func (game *GameImplementation) PlayOneGame(playersCount int) {
game.InitializeGame()
for j := 0; !game.EndOfGame(); j = (j + 1) % playersCount {
game.MakePlay(j)
}
game.PrintWinner()
}
I could use any instance implementing "GameImplementation" as a "Game" without any conversion:
var newGame Game
newGame = NewMonopolyGame() // implements GameImplementation
newGame.PlayOneGame(2)
UPDATE: the purpose of this was to try and achieve all the benefits of abstract base classes without all the coupling that goes with an explicit hierarchy. If I wanted to define a new behaviour PlayBestOfThreeGames, abstract base classes would require me to change the base class itself - whereas here I just define one more method on top of the GameImplementation interface
It's probably for the same reason you can't define methods on interfaces in Java.
An interface is meant to be a description of a part of, or the whole of, the external interface for a set of objects and not how they implement the underlying behavior. In Java you would probably use an abstract class if you need parts of the behavior to be pre-defined but I think the only way to do that in Go is to use functions rather than methods.
I believe that for your example the more Go idiomatic code would be something like this:
type GameImplementation interface {
InitializeGame()
MakePlay(player int)
EndOfGame() bool
PrintWinner()
}
func PlayOneGame(game GameImplementation, playersCount int) {
game.InitializeGame()
for j := 0; !game.EndOfGame(); j = (j + 1) % playersCount {
game.MakePlay(j)
}
game.PrintWinner()
}
Where PlayOneGame and any specific game implementation are probably living in different packages.
Here is some discussion on golang-nuts
In answer to your question of whether there are other statically typed languages that allow this: yes, most. Any language with multiple inheritance allows classes to have arbitrary mixes of abstract and concrete methods. Also, see Scala's traits, which are like Java's interfaces but can have concrete methods. Scala also has structural types, which are really all that Go's interfaces are.
What you're describing as in Interface is really what might elsewhere be referred to as an abstract class -- that is, a class with some methods defined but not all, which must be subclassed in order to be instantiated.
However, Go doesn't have any concept of a class hierarchy -- the whole type structure is flat. Each method on a class is defined for that class specifically, not on any parent class or subclass or interface. This was a conscious design decision, not an omission.
In Go, an Interface is therefore not a component of a type hierarchy (as there is no such thing). Instead, it is simply an ad-hoc specification of the set of methods which must be implemented for a given purpose. That's all. They're a stand-in for dynamic typing whereby you can declare ahead of time which functions on a given type you'll be using -- then any variable who's type satisfies those requirements can be used.
This makes it impossible to use patterns like Generics with Go, and Rob Pike has said at a conference that this might be changed in the future if someone can come with a an elegant implementation and a compelling use case. But that remains yet to be seen.
First, it's important to notice that types implement interfaces implicitly — that is, interfaces are "duck types". Any type that provides the methods required by the interface is assignable to a variable of the interface type, without any cooperation from the original type. This is different from, say, Java or C# where a class that implements an interface has to declare its intention to implement the interface, in addition to actually providing the methods.
Go also has a pretty strong tendency against "action at a distance". For example, even though methods are declared separately from types, it's illegal to declare a method in a different package from its receiver type. You can't just go adding methods to os.File.
If interfaces could provide methods (making them traits/roles) then any type that implemented an interface would gain a bunch of new methods out of nowhere. Someone reading the code and seeing those methods used probably have a hard time figuring out where they came from.
There's a problem with fragility — change the signature of a method that's required by an interface, and a bunch of other methods appear or disappear. In the case where they disappeared, it's not obvious where they "would have" come from. If types had to declare their intention to implement an interface then breaking the contract would prompt an error (and "accidentally" implementing an interface does nothing), but when interfaces are satisfied implicitly things are trickier.
Worse, there could be name conflicts — an interface provides a method with the same name as a method provided by a type that implements that interface, or two interfaces both provide a method with the same name, and some type happens to implement both of those interfaces. Resolving that conflict is the kind of complication that Go really likes to avoid, and in a lot of cases there is no satisfying resolution.
Basically, it would be really cool if interfaces could provide methods — roles as composable units of behavior are cool, and mesh well with Go's composition-over-inheritance philosophy — but actually doing it would be too complicated and too action-at-a-distance-y for Go to contemplate.
I want to have an abstract base class for some of my custom UserControl's. The reason is obvious: they share some common properties and methods (a basic implementation of some elements of an interface actually), and I want to implement them only once.
I have done this by defining my abstract base class:
public abstract class ViewBase : UserControl, ISomeInterface
Then I went to implement one of my views, as usual, with the designer:
public partial class SpecialView : UserControl //all OK
Up to here all is fine. Now I replace the derivation of my SpecialView class with the abstract base class:
public partial class SpecialView : ViewBase //disrupts the designer
Now, the designer in Visual Studio 2008 won't work anymore, stating: The designer must create an instance of type 'ViewBase' but it cannot because the type is declared as abstract.
How can I circumvent this? I just do not want to have the same code copied for all those views.
Info: there is a question question with virtual methods, instead of abstract classes, but there is no suitable solution for me.
Instead of using abstract class, you can mark the functions virtual and override them in the inheriting classes
The best solution is here:
http://wonkitect.wordpress.com/2008/06/20/using-visual-studio-whidbey-to-design-abstract-forms/
Using it now, it's elegant and gets around the underlying problem without breaking your nice OOP design.
Try this solution from Urban Potato, which worked for me, with a strange side effect that I never really had explained, and never got a good workaround. Maybe you'll get lucky and won't have that side-effect!
One could argue that it doesn't make sense in terms of design philosophy to expect to be able to work with an abstract control in the Designer. An abstract class tends to model a type of object for which simply knowing that it's an 'X' doesn't adequately describe it - there's no such thing as an abstract Bird or Car, it's always a specific type of bird or car. Looking at it this way, if you want to view a custom control in the designer, it has to be a specific type of control rather than an abstract one, otherwise what are you looking at? I can see why it's annoying, but I can also see why the Designer was coded in this way.