Forums

by JADE Kid - Ray Hidayat >> Fri, 12 Jan 2001 0:42:10 GMT

Have you ever come to a time when you needed to store more information in a system class, like the File class?

Now, I never came across it before, so this feeling may be rare, but in this system I need to store which 'set' this file belongs to. I can't tell you everything about sets, because of Confidentiality, but they are a bunch of files and folders. By knowing which 'set' the file belongs to, I will find it easier to use this file and to know where to put it when I synchronise it with another computer.

But the thing is, I used the 'File' class just about everywhere in my code, I have references to FileArrays and things, and I can't be bothered going through all of it just to make a little change. Maybe I should have designed better. But now it's too late.

Do you think it would be a good idea to be able to change some of those system classes in your schemas. Personally, I don't really, but I want to see what you think.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by Darrell Duniam >> Fri, 12 Jan 2001 0:55:05 GMT

Just subclass the JADE class, then add your own properties and methods etc. to it, and instantiate that class instead of the native one.

darrell.

"JADE Kid - Ray Hidayat" <BSTRhino@hotmail.com> wrote in message news:D#oEKCDfAHA.321@news.jadeworld.com...
Have you ever come to a time when you needed to store more information in a system class, like the File class?

Now, I never came across it before, so this feeling may be rare, but in this system I need to store which 'set' this file
belongs to. I can't tell you everything about sets, because of Confidentiality, but they are a bunch of files and folders. By
knowing which 'set' the file belongs to, I will find it easier to use this file and to know where to put it when I synchronise
it with another computer.

But the thing is, I used the 'File' class just about everywhere in my code, I have references to FileArrays and things, and I
can't be bothered going through all of it just to make a little change. Maybe I should have designed better. But now it's too
late.

Do you think it would be a good idea to be able to change some of those system classes in your schemas. Personally, I don't
really, but I want to see what you think.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by David Mitchell >> Fri, 12 Jan 2001 0:54:55 GMT

Are you sure you can't add properties straight onto a class in a superschema? You can add methods to Form like this, I haven't tried it with anything else.

by JADE Kid - Ray Hidayat >> Sat, 13 Jan 2001 5:39:14 GMT

It would be a bit awkward to add stuff to a superschema, since this change only applies to the current one.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by David Mitchell >> Sun, 14 Jan 2001 18:59:08 GMT

I meant add properties to a class which is defined in a superschema, but add the properties in your current schema. I'm not sure if this works for properties, but it works for methods.

David

by Richard Mitchell >> Mon, 15 Jan 2001 0:59:49 GMT

You can add methods to a superschema class in your schema, but not properties. You must subclass the superschema class and add properties to that.

Richard Mitchell
JADE Systems Group

by Warwick Hunt >> Mon, 15 Jan 2001 1:59:44 GMT

I'd go one step further and say that you should ALWAYS subclass system classes. I can't see that it costs you anything, but it is guaranteed to save you some grief later on. Anyone else have a view on that?
Warwick

by Wilfred Verkley >> Mon, 15 Jan 2001 3:51:31 GMT

I'd go one step further and say that you should ALWAYS subclass system classes. I can't see that it costs you anything, but it is guaranteed to save you some grief later on. Anyone else have a view on that?

I think this is very dangerous. Inheritence is by far the most "brittle", and hardest to change relationship in an object model. Generally, you should think fairly carefully before you subclass anything, especially the system classes.

Before you inherit anything, you should ask yourself, "am i adding new data/behaviour that is a specialisation" of this class. A lot of people confuse inheritence with one-to-one aggregation relationships IMHO.

Simple example. Assume you use your own inherited version of the File class a lot (ie "MyFile"), and then later Cardinal come out with a new object called "EncryptedFile" which is a subclass of File. Becuase youve been using your own descendents of File (with maybe their own properties and methods), youre screwed. However, if youve just been using seperate objects to hold your custom properties and behaviour, this new subclass would be fairly easy to implement.

Wilfred.

by Craig Shearer >> Mon, 15 Jan 2001 18:53:00 GMT

I think there are two distinct concepts here.

Firstly, I'd agree with Warwick that subclassing system classes is a good idea for some classes - Control classes spring to mind. My current practise is to subclass all standard JADE-supplied control classes so that I can add my own stuff to them later if I so desire. This is because JADE makes it extremely difficult to change the class of a control on a form (read delete the control and paint it again!) so it makes it worthwhile to do this.

However, for classes that only have transient instances (such as File and a whole bunch of other classes) then changing your mind later is usually a pretty easy thing to do. So, I for one probably wouldn't automatically subclass File.

Secondly, Wilfred's point about using aggregation instead of inheritance is a good one - you obviously do need to be careful with inheritance, particularly with persistent objects. Aggregation is often a better solution and one that can be both changed more freely, and also augmented easily by other developers, whereas changing an inheritance structure most times is impossible.

As an example, right now I'm working on a project where we're designing a system for two different customers. We have a generic superschema, and specific subschemas for each customer to suit their differing requirements. It has been very important to design classes carefully to allow useful subclassing in subschemas. It is very important to be careful where we subclass in the superschema as that prevents subschemas from adding properties higher up the class hierarchy!

Craig.

by Robert Barr >> Mon, 15 Jan 2001 21:49:50 GMT

... A lot of people
confuse inheritence with one-to-one aggregation relationships IMHO.

Is "one-to-one aggregation" an oxymoron?