I'm currently trying to learn how to use GObject and there's a point I absolutely don't understand: What's the difference between the class and the instance structure (like "MamanBarClass" and "MamanBar") resp. how do I use them? At the moment I'd put all my object attributes into a private structure (like "MamanBarPrivate"), register it with "g_type_class_add_private" and define properties/getters/setters to access them. But when I leave the class structure empty I get the following error at "g_type_register_static_simple":
specified class size for type `MamanBar' is smaller than `GTypeClass' size
And why are all object methods defined in the class structure (like "GtKWidgetClass")? Probably I'm just screwing up everything, but I only worked with Delphi for OOP yet (I know, nothing to be proud about :D)
Regards
I'm currently trying to learn how to use GObject and there's a point I absolutely don't understand: What's the difference between the class and the instance structure (like "MamanBarClass" and "MamanBar") resp. how do I use them?
The class structure is only created once, and is not instance-specific. It's where you put things which are not instance-specific, such as pointers for virtual methods (which is the most common use for the class struct).
At the moment I'd put all my object attributes into a private structure (like "MamanBarPrivate"), register it with "g_type_class_add_private" and define properties/getters/setters to access them.
Good. That's the right thing to do.
But when I leave the class structure empty I get the following error at "g_type_register_static_simple":
You should never leave the class structure empty. It should always contain the class structure for the type you're inheriting from. For example, if you're trying to create a GObject, the class structure should look like this (at a minimum):
struct _MamanBarClass {
GObjectClass parent_class;
};
Even if you're not inheriting from GObject, you still need the base class for GType:
struct _FooClass {
GTypeClass parent_class;
};
This is how simple inheritance is done in C.
And why are all object methods defined in the class structure (like "GtKWidgetClass")? Probably I'm just screwing up everything, but I only worked with Delphi for OOP yet (I know, nothing to be proud about :D)
Those are virtual public methods. As for why they're defined in the class structure instead of the instance structure, it's because the implementations are the same for every instance.
Related
I am trying to interface with TeamCity using Kotlin.
When you convert a project to Kotlin (from .xml) you will have a file called Project.kt which is where you can set all your configurations.
With no editing mine looks like this:
object Project : Project(/* Some Function Literal with Receiver */)
This looks like circular inheritance? There are imports that I am omitting, but surely that wouldn't make that big of a difference? Could the name be interpreted in different ways depending on where it appears in the file?
My mind is interpreting the object signature like this:
object = Object declaration for singleton.
Project (first occurrence) = Name of object.
: = Inheritance marker.
Project (second occurrence) = Base class to inherit from.
() = Constructor call to the base class.
Is this circular inheritance or have I missed something big about Kotlin? I have looked here and here and can't seem to find my answer.
Assuming qualified classes other.Project and my.Project, you'd have two different classes defined with the same name, in different packages.
Since my.Project is defined as a Singleton, you cannot extend from it and the actual base class is other.Project. Kotlin is clever enough to differentiate. If you would try to do the same with a class declaration, you'd get a circular inheritance.
You could even try to force extending from the Singleton explicitly, but then you'll have the error Cannot inherit from a Singleton. So basically this only works well if you imported the right classes.
I work with a codebase where there are many classes with thousands of lines of code. I've noticed inconsistencies in style concerning prepending class names when using their methods and I'm trying to figure out the previous developer's reasoning. If we
import GeneralCode
in Class A, is it bad practice to write
GeneralCode.DoSomething()
in Class A since we already imported it (instead of simply using DoSomething())? I would think so, but I suppose it's also nice to know which methods come from which classes at a glance, since Class A imports many classes and uses methods from several of them.
EDIT: This is for VB.NET, not Java (sorry for the wrong tag, rough morning). I am new to VB.NET but GeneralCode and DoSomething() are not declared as static, neither is the import in Class A.
Might be something to do with VB.NET, but DoSomething() can indeed be used with or without prepending GeneralCode.
A method need to be prefixed with
The class name if it's a static method.
The name of the instance when it's not a static method.
Unless you are calling a method from your own class.
I want to be able to define in my web.config the type of connexion my object will use to get data (variable) (from an xml or from a databases).
I though about using a Strategie Pattern, but I'm somewhat stuck by the need to write somewhere the name of the class, which I do not want.
Any suggestions?
Additionnal info
I have the interface IContext.
It's implemented in ContextXML and ContextDB.
I have the class Context which has a IContext member (called _context).
The Context class reads (through ContextConfiguration) app.config.
I want _context to be able to be a ContextXML or a ContextDB... or a ContextJSon or any other new class that would implements IContext.
Have you thought about creating a ContextManager class and employing "configuration by convention"?
What I would do, is add a member getName to your IContext interface - this just returns a nice human-readable string for each implementation - as simple as "ContextXML" for your ContextXML class.
When your ContextManager (probably a Singleton, BTW) starts up, it scans a known directory for IContext implementations, instantiating them by reflection (or some other mechanism, I'm not familiar with VB.Net but I'm sure there's a way), and placing them in a collection.
Now when you are building up Context objects, you can ask your ContextManager for a suitable IContext - either explicitly [e.g. getIContextByName("ContextDB")] or with a simpler method that just returns whatever has been configured by some other mechanism - i.e. a suite of methods something like this:
getPossibleIContextImplementationNames()
setCurrentIContextImplementation({name})
getCurrentIContext()
Just as an aside, are you stuck with that naming? Because having a Context object that uses an IContext seems a little unusual. If your IContext implementations are actually used to retrieve data from somewhere, why not call the interface IDAO or IDataAccessor?
I've been battling with AS3 for a little while now, and I'm working on a simple application using only actionscript and the FlashDevelop/flex-compiler combo. I've hit a bit of a wall in my fledgling OOP understanding, and I'm wondering whether someone might be able to point me in the right direction. I have genuinely read several books, and spent many hours reading online tutorials etc, but something's just not clicking!
What's baffling me is this: When something is declared 'public', according to what I read, it is therefore available anywhere in the application (and should therfore be used with care!) However, when I try to use public properties and methods in my program, they most definitely are not available anywhere other than from the class/object that instantiated them.
This leads me to conclude that even if objects (of different class) are instantiated from the same (say 'main') class, they are not able to communicate with each other at all, even through public members.
If so, then fair enough, but I've honestly not seen this explained properly anywhere. More to the point, how do different objects communicate with other then? and what does Public actually mean then, if it only works through a direct composition hierarchy? If one has to write applications based only on communication from composer class to it's own objects (and presumably use events for, er, everything else?) - isn't this incredibly restrictive?
I'm sure this is basic OOP stuff, so my apologies in advance!
Any quick tips or links would be massively appreciated.
There are different topics you are covering in your question. Let me clarify:
What does the modifier public mean?
How can instances of the same class communicate to each other?
--
1.
In OOP you organize your code with objects. An object needs to be instantiated to provide its functionality. The place where you instantiate the object can be considered as the "context". In Flash the context might be the first frame, in a pure AS3 movie, it might be the main class, in Flex it could be the main mxml file. In fact, the context is always an object, too. Class modifier of your object public class MyClass tells your context whether it is allowed to instantiate the object or not. If set to internal, the context must live in the same directory as the class of the object. Otherwise it is not allowed to create a new object of the class. Private or protected are not valid class modifiers. Public class ... means that any context may create an object of that class. Next: Not only instantiation is controlled by these modifiers but also the visibility of a type. If set to internal, you cannot use an expression like var obj : InternalType in a context that does not live in the same directory as Internal type.
What about methods and properties? Even if your context is allowed to access a type, certain properties and methods might be restricted internal/protected/private var/method and you perhaps are not able to invoke them.
Why we're having such restrictions? Answer is simple: Differnent developers may develop different parts of the same software. These parts should communicate only over defined interfaces. These interfaces should be as small as possible. The developer therefore declares as much code as possible to be hidden from outside and only the necessary types and properties publicly available.
Don't mix up with modifiers and global properties. The modifier only tells you if a context is allowed to see a type or method. The global variable is available throughout the code. So even if a class is declared to be public, instances of that class do not know each other by default. You can let them know by:
storing the instances in global variables
providing setter such as set obj1(obj1 : OBJ1) : void where each object needs to store the reference in an instance variable
passing the object as method arguments: doSomething(obj1 : OBJ1)
Hope this helps you to more understand OOP. I am happy to answer your follow up questions.
Jens
#Jens answer (disclaimer: I skimmed) appears to be completely correct.
However, I'm not sure it answers your question very directly, so I'll add a bit here.
A public property is a property of that class instance that is available for other objects to use(function: call, variable: access, etc). However, to use them you must have a reference (like a very basic pointer, if that helps?) to that object instance. The object that instantiates (creates, new ...) that object can take that reference by assigning it to a variable of that class type.
// Reference is now stored in 's'
public ExampleClass s = new ExampleClass();
If you'd like to, you do have the option of making a static property, which is available just by knowing the class name. That property will be shared by all instances of that class, and any external class can refer to it (assuming it's public static) by referring to the class name.
A public property is referred to by the reference you stored.
//public property access
s.foo
s.bar(var)
A static property is referred to by the class name.
//static property access
ExampleClass.foo
ExampleClass.bar(var)
Once you've created the instance, and stored the reference, to an object, you can pass it around as you'd like. The below object of type OtherExampleClass would receive the reference to 's' in its constructor, and would have to store it in a local variable of its own to keep the reference.
public OtherExampleClass s2 = new OtherExampleClass(s);
When programming C++ we used to create copy constructors when needed (or so we were taught). When switching to Java a few years ago, I noticed that the Cloneable interface is now being used instead. C# followed the same route defining the ICloneable interface. It seems to me that cloning is part of the definition of OOP. But I wonder, why were these interfaces created, and the copy constructor seems to have been dropped?
When I thought about it, I came to the thought that a copy constructor would not be useful if one needs to make a copy of an object whose type is not known (as in having a reference to a base type). This seems logical. But I wonder whether there are other reasons that I do not know of, for which the Cloneable interfaces have been favored over copy constructors?
I think it's because there is no such inherent need for a copy constructor in Java and in C# for reference types. In C++ objects are named. You can (and you will most often) copy (and in C++1x move) them around e.g when returning from functions, since returning pointers require you to allocate dynamic memory which would be slow and painful to manage. The syntax is T(x) so it makes sense to make a constructor taking a T reference. C++ couldn't make a clone function, since that would require returning an object by value again (and thus another copy).
But in Java, objects are unnamed. There are only references to them, which can be copied, but the object itself isn't copied. For the cases when you actually need to copy them, you can use the clone call (but i read in other anwers clone is flawed. i'm no java programmer so i cannot comment that). Since not the object itself is returned, but rather a reference to it, a clone function will suffice. Also a clone function can be overriden. That's not going to work with copy constructors. And incidentally, in C++ when you need to copy a polymorphic object, a clone function is required too. It's got a name, the so-called virtual copy constructor.
Because C++ and Java (and C#) aren't the same thing. C++ has no built-in interfaces because interfaces aren't part of the language. You can fake them with abstract classes but they aren't how you think about C++. Also, in C++ assignment is normally deep.
In Java and C# assignment just involves copying the handle to the internal object. Basically when you see:
SomeClass x = new SomeClass();
in Java or C#, there's a level of indirection builtin that doesn't exist in C++. In C++, you write:
SomeClass* x = new SomeClass();
Assignment in C++ involves the dereferenced value:
*x = *another_x;
In Java you can get access to the "real" object as there is no dereference operator like *x. So to do a deep copy, you need a function: clone(). And both Java and C# wrapped that function into an interface.
It's the issues of final type and of cascading the clone operation through the super classes which is not addressed by copy constructors - they are not extensible. But the Java clone mechanism is widely considered badly broken too; especially problems where a subclass does not implement clone(), but inherits from a superclass that implements cloneable.
I strongly recommend you research cloning carefully, whatever path you choose - you will likely choose the clone() option, but make sure you know exactly how to do it properly. It's rather like equals() and hashCode() - looks simple on the surface, but it has to be done exactly right.
I think you haven't get the right point. I give you my two cents.
Fundamentally there's a problem: creating a clone of a class without knowing the exact class type. If you use copy constructor, you cannot.
Here is an example:
class A {
public A(A c) { aMember = c.aMember }
int aMember;
}
class B : A {
public B(B c) : base(c) { bMember = c.bMember }
int bMember;
}
class GenericContainer {
public GenericContainer(GenericContainer c) {
// XXX Wrong code: if aBaseClass is an instance of B, the cloned member won't
// be a B instance!
aBaseClass = new A(c.aBaseClass);
}
A aBaseClass;
}
The Clone method, if declare virtual, could create the right class instance of the generic member.
An this problem is common to every language, C# C++ or Java...
Maybe this is what you was meaning, but I cannot understand this from any answer.
Just wanted to add that in Java the copy constructor is not completely useless.
There are cases where your class has a private instance variable of a mutable non-final type, e.g. Date, and has a setter and getter for the variable. In the setter, you should make a copy of the given date, because the caller could modify it later and thereby manipulate your object's internal state (usually by accident, but maybe intentional). In the getter, the same precaution is required.
The defensive copy could be implemented by calling clone() (the class Date is cloneable), but a malicious caller could call the setter with a subclass of Date which overrides the clone() method with {return this;}, and so the caller might still be able to manipulate your object. This is where the copy constructor comes into play: By calling new Date(theDate), you are sure to get a fresh Date instance with the same timestamp as the given date, without any connection between the two date instances. In the getter, you could use the clone method, because you know the private variable will be of class Date, but for consistency, usually the copy constructor is used there, too.
Also note that the copy constructor would note be required if the Date class was final (calling clone() were safe) or immutable (no copy required).
I think its only because once u have defined a copy constructor, you could never pass the reference itself again. (Unless it would have a function that does that...but thats not any easier than using the clone() method.)
In C++ its not a problem: you can pass the whole object or its reference.