Which is better?

I have a class which has a bunch of methods that are redirected to events for obtaining subclass constants; but I can’t help thinking if it would better to simply have a bunch of properties that are populated on the open event.

These constants are used infrequently, which is why I felt at the time they were better as method/event combos, to reduce memory usage. However I think that may be a moot point as the code required to handle the method/event and the constant it’self are probably all held in memory also.

Which do you think and why?

so the parent has a default constant and the event, if implemented, could return a different value for that subclass ?
you really dont have a choice but to do something like this via events as a subclass may / may not implement the event to “override” the supers constant

I suppose the other way to do it is to make the super class have all these as getter methods that return the supers default value
then the sub could implement the getter to override the supers - or not

events are “chain of responsibility” and unless passed on other subs will never know

overriding a method just works for the instance given and you dont have to remember to pass the event along to any subclasses

for something like this the overidden method might be simpler since you dont have to remember to pass the method along so any subclasses can return a different value

Sorry for not explaining myself correctly. The super doesn’t have any values or constants, I called them constants because the values don’t change, but they are different per subclass.

[code]mySuper
method sharingURL -> event sharingURL

mySuper subclassA
event sharingURL: return “https://thisIsSubClassAsURL.com

mySuper subclassB
event sharingURL: return “https://thisIsSubClassBsURL.com”[/code]

v.s

[code]mySuper
property sharingURL

mySuper subclassA
method constructor: sharingURL = “https://thisIsSubClassAsURL.com

mySuper subclassB
method constructor: sharingURL = “https://thisIsSubClassBsURL.com”[/code]

I’m trying to decide which design is better. I guess performance wise, design A; because the code to obtain the values only fires when those values are actually called. Whereas design B, populates all the properties everytime a class is constructed. Memory-wise, maybe B as it doesn’t require so many events/methods.

or

mySuper
      Sub SharingUrl() as string
      End Sub

class subclassA
inherits mySuper
     Sub SharingUrl() as string
              return  "https://thisIsSubClassAsURL.com"
     End Sub

class subclassB
inherits mySuper
     Sub SharingUrl() as string
              return  "https://thisIsSubClassBsURL.com"
     End Sub

that way for subclasses that have not implemented the overridden method you get “”
for those you have you get their URL

and you dont have to remember to pass along the event like you would using the events like you showed

mySuper
    method sharingURL -> event sharingURL

class subclassA
inherits mySuper
    event sharingURL: return "https://thisIsSubClassAsURL.com"

class subclassB 
inherits subclassA
    event sharingURL: return "https://thisIsSubClassBsURL.com"

the event in subclassB would never actually work because subclass A forgot to pass it along

IE this works regardless

mySuper
     Sub SharingUrl() as string
     End Sub

class subclassA
inherits mySuper
    Sub SharingUrl() as string
              return  "https://thisIsSubClassAsURL.com"
    End Sub

class subclassB
inherits subclassA
     Sub SharingUrl() as string
              return  "https://thisIsSubClassBsURL.com"
    End Sub

in the last set up the sharingURL method in subclassB works either way

simpler by design

edit : basically the subclassing and overriding lets you just add subclasses, override that method and they “just work”
The event way requires you to remember in every super to define the event and call it just in case there is a subclass some day
Or have to go back and add the event def when there is one
Either way its work you have to remember to do at some point

But the subclass + overridden methods just works

If we aren’t talking about 10k classes with values you are way overthinking the problem.

Thanks Norman; I’d not considered overriding methods.

At the moment we’re talking 20, I have another 20 on my list already and I expect that to grow in the next few months.

Ideally I’d like to implement a pretty efficient and less hassle design now, rather than have to change it all in the future.

I have another question, and that’s related to class meta data; each class has a DisplayName, Description and maybe an icon. This is used to a display a list to user allowing them to select and add these classes to their project. I’d like to keep each class responsible for it’s own meta data, but yet at the same time I’d like a nice clean method of getting this without having to instigate an instance of the class.

Currently I have a shared computed property which returns a dictionary, that does however mean for each subclass I have to manually write code to add it’s meta data to the list.

classesMeta.append subClassA.metadata

Is there a better way?

dont use a dictionary as a replacement for designing a suitable mechanism
you’ll learn to regret it later as things grow
you get no type safety or any other help from the compiler

one thing that you cannot do though is override shared class methods
mostly thats because since you do no t hav an instance there is no virtual dispatch table which is how an instance knows whether it does or doesnt have an override for a method from a super

how do you call this method to know swhich items meta data youre getting ?
knowing how you use it might help figure out how to best design this

When I display a list of the classes that the user can add to their project, I currently create an array of dictionaries.

[code]Dim hedgehogs() as dictionary
hedgehogs.append subClassA.metadata
hedgehogs.append subClassB.metadata
~
hedgehogs.append subClassZZ.metadata

Dim classNames() as string
For each cItem as dictionary in hedgehogs
classNames.append cItem.value( kMDDisplayName )
Next

classNames.sortWith hedgehogs

// Code here to build a list in the selector window.[/code]

Then when the user adds one of these classes to their project, I have a function on the super class, createWithIdentifier which…

select case inIdentifier case subClassA.kIdentifier return new subClassA case subClassB.kIdentifier return new subClassB ~ Else reportError( "Identifier """ + inIdentifier + """ not recognized." ) break End Select

I’m going to have to redesign this as I’m creating one huge project to rule them all, but not each app will feature all the classes, so I don’t want them included when they’re not going to be used.

How on earth did I forget about the classIdentifier? it’s a constant manually added to each subClass “kIdentifier”, this constant is also included in the meta data dictionary and again via a method/event pair on the super class.

[quote=434170:@Sam Rowlands]
At the moment we’re talking 20, I have another 20 on my list already and I expect that to grow in the next few months.[/quote]

It’s been my experience that once you get to around 7 or 8 subclasses it’s time for a rethink. Very often working with interfaces provides a more robust solution. How much of your subclass’s functionality is supported by your super class? More than say 60%?

Sounds like the super class is, in this case, doing “new class by name” or “new class by id” which I’d factor out of the super and into a module since this creates a dependency cycle between the supers & subs.
Any app that doesnt have all these subclasses has to have a modified super that comments out the subs that wont exist otherwise you wont be able to compile

Fundamentally that doesnt solve the problem but it moves the problem OUT of the super class so it cane be shared without the dependency issues

A module would be a decent choice for the “factory” method as that module doesnt have to be shared around and could be custom per app

Sam, are your subclasses defining behavior and/or acting as placeholders for future behavior? Or are they simply serving as placeholders to store information?

You’ve said these subclasses have unique URLs, display names, descriptions, and icons, but you haven’t indicated that they have unique behavior. If these subclasses are only storing data then I would recommend making them records in a local SQLite database, or entries in some other local store (XML file, text file, constant) which can be quickly parsed into an in-memory SQLite database or Dictionary.

You could still have a class which represented the data and provided properties/methods as an interface for other code. What you have currently defined as a subclass would simply be an instance of that class with the unique data loaded into properties. You could also have a module with a factory method which would allow you to create instances of subclasses with unique behavior if that’s needed for some records (or record types) in the future.

But if you have subclasses which do nothing but hold unique static data, my thought is they shouldn’t exist at all.

[quote=434223:@Daniel Taylor]
But if you have subclasses which do nothing but hold unique static data, my thought is they shouldn’t exist at all.[/quote]

I’d while heartedly agree with this

All the classes in question are functional; I’m just wondering about better ways of handling constants within a subclassing structure. There’s two that I have in mind right now. One is a product controller; from one single project I can spawn multiple products, the product controller pretty much covers the basics of what makes it each product different (generating new document instances, determining what filters to use in an open dialog, loading product specific plugins, handling sharing meta data).

Then there’s the optional extras; in some products, the user will be able to add these little extras to their workflow to manipulate the data. The extra’s contain the meta data as there is an interface where the user can choose which to add, currently it only displays the “DisplayName”, but I intend to add descriptions via a help tag. Some may include include an icon, some may not not. I also propose to expand the meta data to hold keywords to make it easier for the user to search for extras as the list grows. Currently there’s 20, I just checked my list and there’s 30 more that can be added, and I’m sure there will be even more.

Right now; almost all the functions are method/event pairs; except meta data, as the meta data must be accessible without having a instance of the class.