Is the notion of kernel object (pipe, socket, mutex, ...) in windows linked to the notion of object in Object Oriented Programming (in oop, an object has attributes and methods attached to it)?
Although main parts of the kernel are written in pure C, implementation of the kernel objects in Windows follows some OOP principles. Certain operations are supported by all types of kernel objects which can be viewed in a way that all kernel object share the same ancestor (e.g. similar to Object in Java). Such operations include opening the object and setting/querying its security setttings.
There is a special type of kernel object called Object type the purpose of which is to describe characteristics shared by a given type of kernel object (e.g. processes, semaphores, open registry keys...). Such characteristics include the following:
size of the object body (a memory block hodling an instance of the object),
whether the object body is allocated from paged (swappable to disk) or nonpaged (always resident) memory,
whether the object supports waiting (mostly used by synchronization objects, but also by processes or threads (these objects enter signaled state when they finish their work),
(virtual) destructor,
a (virtual) procedure responsible for working with object's security descriptor,
and more.
Since each kernel object contains a reference to its type object (including the type objects themselves – there is a special type object describing type objects), and since the type object define several callbacks implemented by the individual instances of type objects (processes, threads etc.), we can say that the implementation of Windows kernel objects utilizes the polymorphism and the inheritance principles. The encapsulation principle is also present because the kernel exports various high-level routines working with individual types of objects (NtXxxProcess, NtXxxFile...).
There also exists many types of "objects" that are not based on the general kernel object implementation. Most of the GUI objects (windows, brlushes, bitmaps, ...) fall into this category, with exception of desktops and window stations. Most of the kernel objects is implemented by the main kernel module (ntoskrnl.exe), although an undocumented interface (ObCreateObjectType) allowing to implement your own type objects, exists.
To sum this answer up: the implementation of Windows kernel objects does use OOP principles but keep in mind that the kernel is written in C that has no native support for OOP constructs.
Related
I was reading a post Inheritance and Composition (Is-a vs Has-a relationship) in Java and I ambit confused by what this following statement.
It's also worth noting that in this case, the containing Computer object has ownership of the contained objects if and only if the objects can't be reused within another Computer object. If they can, we'd be using aggregation, rather than composition, where ownership isn't implied.
Here is the code snippet being referenced
public class Computer{
private Processor processor;
private Memory memory;
private SoundCard soundCard;
//... more code
}
What does it mean by being reused within another Computer object? Does it mean that when I have two instantiations of Computer that they shouldn't be sharing those composed objects (processor, memory, soundcard)?
Can someone give an example where aggregation is used instead of composition following the statement above?
The question is, how are the private fields instantiated?
Does it mean that when I have two instantiations of Computer that they shouldn't be sharing those composed objects...
Yes.
If a Computer object instantiates its own Processor so that no other object has a reference to that Processor instance, then it "has ownership of" its Processor, which the quote refers to as aggregation.
Contrast that scenario with a Computer object that receives its Processor through a getter method or constructor argument. In this case, the Processor is instantiated by some other object, and the Computer does not have sole ownership of its Processor, because it does not have the only reference to the Processor object. The quote refers to this relationship as composition.
In practice, the difference between aggregation and composition rarely matters. The difference between composition and inheritance is far more important.
Garbage collected object oriented programming languages reclaim unused memory automatically, but all other kinds of resources (i.e. files, sockets...) still require manual release since finalizers cannot be trusted to run in time (or at all).
Therefore such resource objects usually provide some kind of "close"- or "dispose"-method/pattern, which can be problematic for a number of reasons:
Dispose has to be called manually which may pose problems in cases when it is not clear when the resource has to be released (similar problem as with manual memory management)
The disposable-pattern is somewhat "viral", since each class containing a disposable resource must be made disposable as well in order to guarantee correct resource cleanup
An addition of a disposable member to a class, requiring the class to become disposable as well, changes the interface and the usage patterns of the class, thus breaking encapsulation
The disposable-pattern creates problems with inheritance, i.e. when a derived class is disposable, while the base class isn't
So, are there any alternative concepts/approaches for properly releasing such resources? Any papers/research in that direction?
One approach (in languages that support it) is to manually trigger a garbage collection event to cause finalizers to run. However, some languages (like Java) do not provide a reliable mechanism for doing so.
I'm a little confused about com threading models.
I have an inproc server and I want to create an interface accesible from any thread regardless of the threading-model and/or flags used in CoInitializeEx.
When passing interfaces from one thread to another I use CoMarshalInterface/CoUnmarshalInterface without problems but I want to know if exists any way to avoid that and directly pass the interface pointer.
I tried making the interface use neutral apartment but still have to call CoMarshalInterface/CoUnmarshalInterface to avoid problems.
Regards,
Mauro.
COM objects reside in one apartment only. Accessing a COM object via an interface pointer across apartment boundaries is never a good idea unless you're applicable scenario can utilize a free threaded marshaling aggregate. A free-threaded marshaller, essentially says that all clients of this interface, regardless of apartment and thread, are in the same process and will rely on the object itself to maintain synchronization and thread safety. The object itself must aggregate the free-threaded marshaller interface, so hopefully you're the author of it as well as the client code.
More information on free-threaded marshaling can be found at msdn.com, but one of their articles covering the object I tend to reuse again and again is this one.
I hope it helps you out.
Consider two problems:
We have a wrapper that detects if the wrapped object started a transaction, keeps the transaction number and makes it available to users of wrapper through a method. Can it be called a facade, assuming it simplifies interface of course?
There is a communication layer which provides high-level interface for low-level operations required to execute functions on attached device (these involves pushing bytes through socket and parsing the answers). Some of the answers contains a special "prompt number" which is required for some other queries. Communication layer detects answers which contains a prompt number and stores that number in a special holder which is available to caller. Could that be called a facade?
Overall those questions are related to a more general question:
Which design patterns allows to store or manage mutable or immutable state and/ or inspect the objects that are passed to wrapped objects or returned from them.
Take a look at the Observer Pattern http://en.wikipedia.org/wiki/Observer_pattern
The State pattern could be of use as well: http://en.wikipedia.org/wiki/State_pattern
and perhaps also Memento http://en.wikipedia.org/wiki/Memento_pattern
depending on what you want to accomplish.
For the Observer look at boost signals and slots or at qt signals and slots for some neat implementation.
Suppose you have an imaginary type system for an imaginary scripting language which is written in C++ (for example), and each type (and object) in the scripting language has a corresponding type (and object) in the underlying implementation language. The base class in this imaginary type system is a class called Object, and all other classes must derive from this class. Now, you have another class called HashTable, which is the basis for all variable storage (I might have said that wrong): namespaces are implemented via HashTables (associating one object with another object), global variables are stored via HashTables, and, to the point of the problem, instance variables are also stored in HashTables.
Instance variables are such that every Object has an HashTable in which to store its instance variables. However, HashTable necessarily derives from Object, therefore each HashTable has an HashTable in which to store its instance variables. And every HashTable for every HashTable has an HashTable, and so on ad infinitum.
My question is, can this type system be implemented in an object-oriented way in the underlying C++ code? If no precautions are taken, the program will enter an infinite loop and cause a stack overflow on the mere instantiation of an Object, because it will instantiate an HashTable which will call its parent constructor for Object, which will instantiate an HashTable...
Are there any viable workarounds for this design flaw which don't involve breaking the desired OO design (each type has its corollary type in the underlying code)?
Pardon the grammar in this post, English is not my first language and I might not have explained something in a comprehensible manner.
implement two different HashTable types: one for user code (UserHashTable), derived from Object and so no violating your "everything is Object" rule, and another for internal use (CoreHashTable) to implement your type system.
[EDIT] CoreHashTable can be automatically convertible to UserHashTable, e.g. UserHashTable can contain internal smart pointer to CoreHashTable.
Yes. You can emulate your own "object system" with another programing language.
That concept its called a "virtual object system".
O.O. Programming languages have its own "Object System". By an "Object System", I don't mean "O.O. libraries or O.O. Class hierarchy". By an "Object System" I mean its way of declaring and using classes and objects.
But, sometimes, your programming language its not object oriented, or even if its object oriented, some stuff is missing. C# and Java doesn't have real properties & events, C# and Object Pascal does.
When O.O. started, many programmers use non O.O. programming languages, and learn about O.O. Some make their own "plain C" to "C++" preprocessors (Objective-C maybe), some did full compilers.
And some emulate them. The programmer, conceptually, thinking, he was using classes and objects, but, in code, use structures & pointers.
I have seen several "virtual object system (s)", where a group of classes or objects is simulated by another programming language.
Once, I worked with a database conectivity tool called "Borland Database Engine", where developers read and write data into objects like "databases", "tables", "fields".
One famous, is the GLib library ("GObject" is the root object), used in the GNome visual interface for GNU/Linux. It's done in "plain C", but simulates objects and classes, using pointers.
More Info:
http://en.wikipedia.org/wiki/Gobject
You want to use a group of objects conceptually speaking, but in code, you won't have a class declaration for your conceptual class, but, some data stored in hash tables, using another O.O. programming language. Yes it can be done.