OOP problem

To instantiate an object I can do something like this:

Add a property to the App object:
Test As cTest

Then instantiate it in the open event of App:

Dim t As New cTest
Me.Test=t

To call a method of this class from outside I can use:

App.Test.myMethod

Now my question:

I don’t want my object Test to be a member of the App class, I’d rather have it as a standalone object (in the same way as the App object is) so that I can call e.g. a method of the class like this:

Test.myMethod

Is this possible?

Hank

dim Test As new cTest
test.myMethod

thats whats known as an INSTANCE method and requires you have created an instance using NEW

There are also SHARED methods which do NOT require an instance

This sort of thing is covered in Introduction to Programming with Xojo or the users guides available from http://documentation.xojo.com

Thank you for your answer, but:

I don’t want my object Test to be a member of the App class, I’d rather have it as a standalone object (in the same way as the App object is).

This is my problem (not the way how I call its members).

What Norman says is the correct way. You want a property of your class to be unique to that class and access it w/o having to instantiate the class aaand… encapsulate it. It’s the way it should be done. Globals are not OOP.

A shared or static variable or property is shared among all instances. You don’t even need to call a constructor ever… it serves that purpose. But remember, it’s shared among all instances, so you need to have a keep on this behavior.

So…

[code]Class Foo

 Shared Property Bar as Integer = 20

End Class[/code]

Just access Foo.Bar property and you will be able to get/set that encapsulated property.

Dim temp as Integer = Foo.Bar

or

Foo.Bar = (int)value.

Hope it helps. And reality good OOP question.

Amando

If there is only one instance for the application (a Singleton) then…

  • Add a protected shared property to the class: mSingleton As cTest
  • Add a public shared method to the class: Singleton() As cTest
  • In the shared method test to see if mSingleton has an instance. If not, create one. The next line returns mSingleton. Example:
  If mSingleton = Nil Then mSingleton = New cTest
  Return mSingleton

Now you can call cTest.Singleton from any where in the project to get the instance and call its methods. You can add it to a project without requiring changes to App. And if you ever do run into a situation where you need additional instances, you do not have to refactor all of the code as you would if the methods and properties were all shared. (Just don’t rely on mSingleton for anything except the Singleton accessor method.)

Shared methods and properties should be things that are truly global to the class. Things that do not change whether you have 1 or 1,000 instances of the class. If the method or property would break with 2 or more instances, then it should not be shared even if you can’t imagine having 2 or more instances at this time.

@Daniel Taylor I thought this as well, but I think he wants to encapsulate a variable instead of avoiding more than once class instance.

Could be, in which case you and Norman have the right suggestion.

This is not possible in OOP. Somebody needs to hold a reference to the instance, so it can stay alive when the method where the object is instantiated ends.

App is not an instance of Application. It is a method returning the sole instance of Application.
To mimic that, create a module like that:

[code]Module cTest

Private Class cTest

End Class

Private cTestInstance As cTest

Public Function cTest() As cTest
If cTestInstance Is Nil Then
cTestInstance = New cTest()
End
Return cTestInstance
End Function

End Module[/code]

I read the question in terms of name spacing. Ie., “How do you declare the property so you can refer to it as Test rather than App.Test?” If so, then the answer is simple: Add a Module to your project and add the property to that module. Set the scope of the property to Global.

Thanks to all of you, for your explanations, especially Eli, for yours. Now I understand the relationship of these things.

A last question:

I think I have read that modules don’t allow events. So what if I want to have my class to send events?

Use AddHandler.

A Module is not a class. I mean, you can use modules for what you want to achieve, simply it’s not the correct way.

If it solves a problem, it is the correct way. Not using modules because they are “not OOP” is ridiculous.

Seems there are so many things I have not understood yet. The basic theory of OOP is clear, but every time I want to create an instance of a class (to work with it) there is the question WHERE to instantiate it …

E.g. if I want to create an object that should do the job of a data base (methods of the class would be add/delete/save records) then there is the question:

Who should instantiate the object DB? The open event of the main window - or the open event of the app - or another object?

These are design aspects - and really difficult to answer for beginners like me …

I emphasized the “correct way” not the impossibility. Quite different, but only one approach is academical right.

I hope you’re joking…

No. I’m tired. Cheers!

By the way, public shared properties are globals too.

Oh, and I almost forgot: singletons are globals too.

[quote=212748:@Eli Ott]By the way, public shared properties are globals too.
[/quote]

Really? I did not know it. I’m too old. That ends my post in this thread. You go on.