Avoid code duplication because of subclasses?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoid code duplication because of subclasses?

Mariano Martinez Peck
Hi All, 

In my domain classes, I have several hierarchies in which I have several instance variables along this hierarchy. Let's assume I want a different table for each concrete subclass (the easiest way I think). In the DescriptorSystem, I have to write the mappings not only for the "state" of the concrete subclass but also from all its superclasses. So superclass state' mapping is duplicated in each subclass.

I understand your reasons of why having the mappings in a separate class rather than in domain classes their-self  Still, may be missing something here that could be done using the DescriptorSystem. 

Thanks in advance, 

--
Mariano
http://marianopeck.wordpress.com

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Avoid code duplication because of subclasses?

Tom Robinson
On 6/7/13 7:04 AM, Mariano Martinez Peck wrote:
Hi All, 

In my domain classes, I have several hierarchies in which I have several instance variables along this hierarchy. Let's assume I want a different table for each concrete subclass (the easiest way I think). In the DescriptorSystem, I have to write the mappings not only for the "state" of the concrete subclass but also from all its superclasses. So superclass state' mapping is duplicated in each subclass.
Sometimes you want a different table for each concrete class, but there are situations when you don't. To deal with the situation where you have the same state in several classes because they inherit from a common superclass (or because you have good reason for duplicate state in classes which are not part of the same hierarchy), creating a methods in the DescriptorSystem which define the duplicated state, and calling them from the descriptor, class and table methods which need them.

The StoreDescriptorSystem is a good example of a descriptor system built to support an existing database schema *not* built with Glorp in mind. Neither the descriptorSystem nor the schema are perfect, but they are used every day in production Smalltalk shops. Improvements are in the works. Using Glorp to support Store allows us to be Glorp users (and see places for improvement) in the same way you do.

I understand your reasons of why having the mappings in a separate class rather than in domain classes their-self  Still, may be missing something here that could be done using the DescriptorSystem.
A non-trivial Glorp DescriptorSystem definition can be found in the recent releases of VisualWorks (including the currently available Personal Use License version). The class is StoreDescriptorSystem, which has 2 subclasses to represent later versions of the schema. Within that class, here are examples:
  • descriptors - #addStandardStoreDescriptorTo:forTable:andClass:
  • classes - #classModelForStoreBinaryBlob:
  • tables - #addStandardAndVersionRecordFieldsIn:

In addition, VisualWorks provides the following:

  • GlorpActiveRecord parcel which automates a lot of DescriptorSystem building work (also available in the Cincom open repository)
  • a test parcel for the above, which includes some examples (open repository)
  • Glorp User's Guide documentation which talks about use of Glorp, use of the ActiveRecord functionality and it's limitations



Thanks in advance, 

--
Mariano
http://marianopeck.wordpress.com
--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Avoid code duplication because of subclasses?

Alan Knight-2
What Tom said. Basically you can split it up into multiple methods and avoid the duplication. It's also possible to have the descriptor methods as class methods on the classes in question, and there are examples of that in the tests. That makes the lack of duplication clearer and probably a little cleaner. Personally, I prefer having them all on the descriptor system, but other people have different tastes.


On 7 June 2013 07:46, Tom Robinson <[hidden email]> wrote:
On 6/7/13 7:04 AM, Mariano Martinez Peck wrote:
Hi All, 

In my domain classes, I have several hierarchies in which I have several instance variables along this hierarchy. Let's assume I want a different table for each concrete subclass (the easiest way I think). In the DescriptorSystem, I have to write the mappings not only for the "state" of the concrete subclass but also from all its superclasses. So superclass state' mapping is duplicated in each subclass.
Sometimes you want a different table for each concrete class, but there are situations when you don't. To deal with the situation where you have the same state in several classes because they inherit from a common superclass (or because you have good reason for duplicate state in classes which are not part of the same hierarchy), creating a methods in the DescriptorSystem which define the duplicated state, and calling them from the descriptor, class and table methods which need them.

The StoreDescriptorSystem is a good example of a descriptor system built to support an existing database schema *not* built with Glorp in mind. Neither the descriptorSystem nor the schema are perfect, but they are used every day in production Smalltalk shops. Improvements are in the works. Using Glorp to support Store allows us to be Glorp users (and see places for improvement) in the same way you do.


I understand your reasons of why having the mappings in a separate class rather than in domain classes their-self  Still, may be missing something here that could be done using the DescriptorSystem.
A non-trivial Glorp DescriptorSystem definition can be found in the recent releases of VisualWorks (including the currently available Personal Use License version). The class is StoreDescriptorSystem, which has 2 subclasses to represent later versions of the schema. Within that class, here are examples:
  • descriptors - #addStandardStoreDescriptorTo:forTable:andClass:
  • classes - #classModelForStoreBinaryBlob:
  • tables - #addStandardAndVersionRecordFieldsIn:

In addition, VisualWorks provides the following:

  • GlorpActiveRecord parcel which automates a lot of DescriptorSystem building work (also available in the Cincom open repository)
  • a test parcel for the above, which includes some examples (open repository)
  • Glorp User's Guide documentation which talks about use of Glorp, use of the ActiveRecord functionality and it's limitations



Thanks in advance, 

--
Mariano
http://marianopeck.wordpress.com
--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.