refactoring of similar simple-method

[Jacques Le Roux <ja...@les7arts.com>]

De : "Adam Heath" <do...@brainfood.com>

> Another point; in lots of simple method definitions, there are blocks
> for doing CRUD to entities; in the vast majority of cases, these method
> definitions are *identical*, except for the entity name and property to
> pull error messages from.  This points to a need to refactor.

IMHO, this point is very interesting, but of course need some work...

Jacques

Re: refactoring of similar simple-method

[Adrian Crum <ad...@hlmksw.com>]

Something similar was done with permission checking - see the CommonPermissionServices.xml file in 
framework/common and how it is used in FixedAssetMaintServices.xml in specialpurpose/assetmaint.


Jacques Le Roux wrote:

> De : "Adam Heath" <do...@brainfood.com>
> 
>>Another point; in lots of simple method definitions, there are blocks
>>for doing CRUD to entities; in the vast majority of cases, these method
>>definitions are *identical*, except for the entity name and property to
>>pull error messages from.  This points to a need to refactor.
> 
> 
> IMHO, this point is very interesting, but of course need some work...
> 
> Jacques
> 

Re: refactoring of similar simple-method

[Jonathon -- Improov <jo...@improov.com>]

 > So, yeah, it was intentional to have separate operations for things like (all
 > of these are just for creates, different combinations for different things):

Overly tight coupling of any of the building-block functions will mean less flexibility.

Quick example. I decide to create a class called MyGUI. Then I thought I would subclass that and 
create AnotherGUI. Before I know it, MyGUI and AnotherGUI drift apart and become less common. But 
because both classes use common methods, I have to be careful when changing MyGUI. At some point, 
possibly due to time constraints, I give up, and I create AnotherGUI from scratch, completely 
decoupled from MyGUI. When I do have time, I will refactor MyGUI and AnotherGUI, and possibly 
create BaseGUI as a parent for both classes. On hindsight, it was probably better to have started 
out with separate classes MyGUI and AnotherGUI, and then spot commonalities along the way. 
Hindsight is always better and cheaper than foresight.

 > We could identify a few variations and have single operations,

We could identify commonalities on hindsight, yes. Still, the basic building-block codes must be 
available, just so users and their myriad of use cases can still be served. On really clear 
hindsight in future, we may decide that 2 or more building-block codes simply CANNOT be split up 
or be called in any other than 1 order. Then we cobble those together for good.

 > It does us no good to create something that supports super fast development
 > if it makes ongoing maintenance and extension/customization more difficult

The Widget framework is already "shrink-wrapped" enough to make certain customizations difficult. 
Maybe we shouldn't "shrink-wrap" the CRUD-related minilang functions and shouldn't make 
customizations just that bit more difficult?

 > but rest assured that if I shut up others will fill in because lots of people
 > in the ofbiz community have experience with this and know what kind of a
 > difference it makes.

I don't mind additive changes. If functions need to be removed, deprecate obsolete usages and give 
us time to move!

Jonathon

David E Jones wrote:
> 
> On Oct 16, 2007, at 12:51 PM, Jacques Le Roux wrote:
> 
>> De : "Adam Heath" <do...@brainfood.com>
>>
>>> Another point; in lots of simple method definitions, there are blocks
>>> for doing CRUD to entities; in the vast majority of cases, these method
>>> definitions are *identical*, except for the entity name and property to
>>> pull error messages from.  This points to a need to refactor.
>>
>> IMHO, this point is very interesting, but of course need some work...
> 
> These were designed VERY specifically to be this way. It is true there 
> are only a few common variations for different data structures and 
> corresponding create/updated/delete operations.
> 
> The point of having simple-methods exist for this instead of just have 
> "call create variation A" in the service definition is to make it easy 
> to customize and enhance. As functionality around certain entities grows 
> these methods do tend to grow beyond the base 2-4 operations that the 
> typical minimal methods include.
> 
> So, yeah, it was intentional to have separate operations for things like 
> (all of these are just for creates, different combinations for different 
> things):
> 
> 1. make a value object
> 2. put a sequenced id in a single pk field for the object
> 3. move all primary key fields from the parameters or other Map into the 
> value
> 4. move non-pk fields from a Map into the value
> 5. set individual fields on the value
> 6. and so on...
> 
> We could identify a few variations and have single operations, or avoid 
> writing simple-methods altogether with the service def thing I mentioned 
> above, but that would just reduce consistency between different 
> simple-methods and make customization and extension more difficult.
> 
> It seems like some recent comments stem from a disagreement that 
> consistency and ease of customization are important... that might be an 
> interesting thing to talk about explicitly. Much of the OFBiz framework 
> is meant for help just those things, where necessary sacrificing other 
> priorities, all part of optimizing the development experience at the XML 
> file level.
> 
> The driving factor behind that priority is that in most large software 
> it is complexity that kills projects and causes budgets to spiral out of 
> control. As complexity increases the time and cost tends to increase in 
> a non-linear way, ie something like exponentially or logarithmically 
> instead of linearly. When I say complexity I mean general solution 
> complexity across hundreds of entities and services and screens, and not 
> the complexity of a single service. The point of defining the scope and 
> purpose of a service is to limit the complexity of that one piece to 
> make it possible to write and maintain it with a reasonable volume of 
> requirements.
> 
> For OFBiz (both the framework and the applications) it is critical that 
> we all keep this in mind. It does us no good to create something that 
> supports super fast development if it makes ongoing maintenance and 
> extension/customization more difficult (including other people's code or 
> years later when you've forgotten and it might as well be something 
> someone else wrote). The point is to be as clear and consistent as 
> possible across a variety of data structures and business processes.
> 
> When talking about framework improvements that should be the first thing 
> considered and written about when presenting ideas. Ideas that don't 
> help with that will be fought pretty hard by various people, me being 
> the most vocal, but rest assured that if I shut up others will fill in 
> because lots of people in the ofbiz community have experience with this 
> and know what kind of a difference it makes.
> 
> -David
> 

Re: refactoring of similar simple-method

[David E Jones <jo...@hotwaxmedia.com>]

On Oct 16, 2007, at 2:51 PM, Adam Heath wrote:

>> The driving factor behind that priority is that in most large  
>> software
>> it is complexity that kills projects and causes budgets to spiral  
>> out of
>> control. As complexity increases the time and cost tends to  
>> increase in
>> a non-linear way, ie something like exponentially or logarithmically
>> instead of linearly. When I say complexity I mean general solution
>> complexity across hundreds of entities and services and screens,  
>> and not
>> the complexity of a single service. The point of defining the  
>> scope and
>> purpose of a service is to limit the complexity of that one piece to
>> make it possible to write and maintain it with a reasonable volume of
>> requirements.
>
> Exactly the point I'm trying to make.
>
> If every CRUD implementation on every entity has it's own
> implementation, then there are that many *more* things that have to be
> learned.

Um, but that's NOT the point I was making. You're talking about  
sacrificing flexibility and ease of customization for ease of initial  
implementation. As for understanding and reading, once you've seen  
one of each pattern you've seen them all so there isn't anything more  
to keep a handle on, until you find an exception to the pattern you  
are used to and then it's important to look and understand why it is  
different, and yada yada yada.

-David

Re: refactoring of similar simple-method

[Adam Heath <do...@brainfood.com>]

David E Jones wrote:
> These were designed VERY specifically to be this way. It is true there
> are only a few common variations for different data structures and
> corresponding create/updated/delete operations.
> 
> The point of having simple-methods exist for this instead of just have
> "call create variation A" in the service definition is to make it easy
> to customize and enhance. As functionality around certain entities grows
> these methods do tend to grow beyond the base 2-4 operations that the
> typical minimal methods include.

The refactoring I mentioned never talked about implementation of the
common services; they could very well still be simple methods.

> So, yeah, it was intentional to have separate operations for things like
> (all of these are just for creates, different combinations for different
> things):
> 
> 1. make a value object
> 2. put a sequenced id in a single pk field for the object
> 3. move all primary key fields from the parameters or other Map into the
> value
> 4. move non-pk fields from a Map into the value
> 5. set individual fields on the value
> 6. and so on...
> 
> We could identify a few variations and have single operations, or avoid
> writing simple-methods altogether with the service def thing I mentioned
> above, but that would just reduce consistency between different
> simple-methods and make customization and extension more difficult.
> 
> It seems like some recent comments stem from a disagreement that
> consistency and ease of customization are important... that might be an
> interesting thing to talk about explicitly. Much of the OFBiz framework
> is meant for help just those things, where necessary sacrificing other
> priorities, all part of optimizing the development experience at the XML
> file level.
> 
> The driving factor behind that priority is that in most large software
> it is complexity that kills projects and causes budgets to spiral out of
> control. As complexity increases the time and cost tends to increase in
> a non-linear way, ie something like exponentially or logarithmically
> instead of linearly. When I say complexity I mean general solution
> complexity across hundreds of entities and services and screens, and not
> the complexity of a single service. The point of defining the scope and
> purpose of a service is to limit the complexity of that one piece to
> make it possible to write and maintain it with a reasonable volume of
> requirements.

Exactly the point I'm trying to make.

If every CRUD implementation on every entity has it's own
implementation, then there are that many *more* things that have to be
learned.

However, if you see that entity #1 uses one implementation, then entity
#2 uses it, and entity #3 uses it, ..., then that's *less* that you have
to learn.

It should *always* be possible to have per-entity implementations; no
one is suggesting that that feature be removed.  But reducing code, by
refactoring, and reducing the learning requirements, *is* a win.

Commonality is *good*.  If it weren't, we wouldn't have an entity
engine, or a service engine.  We'd have hard-coded jdbc calls and bsf
usage scattered all over.

If just 2 entities share the same CRUD implementation, then we have
reduced the knowledge workload, and that is a win.

> For OFBiz (both the framework and the applications) it is critical that
> we all keep this in mind. It does us no good to create something that
> supports super fast development if it makes ongoing maintenance and
> extension/customization more difficult (including other people's code or
> years later when you've forgotten and it might as well be something
> someone else wrote). The point is to be as clear and consistent as
> possible across a variety of data structures and business processes.

Please stop making my points for me.

Re: refactoring of similar simple-method

[Jacques Le Roux <ja...@les7arts.com>]

I see the point, thanks for comment David

Jacques

De : "David E Jones" <jo...@hotwaxmedia.com>

> 
> On Oct 16, 2007, at 12:51 PM, Jacques Le Roux wrote:
> 
> > De : "Adam Heath" <do...@brainfood.com>
> >
> >> Another point; in lots of simple method definitions, there are blocks
> >> for doing CRUD to entities; in the vast majority of cases, these  
> >> method
> >> definitions are *identical*, except for the entity name and  
> >> property to
> >> pull error messages from.  This points to a need to refactor.
> >
> > IMHO, this point is very interesting, but of course need some work...
> 
> These were designed VERY specifically to be this way. It is true  
> there are only a few common variations for different data structures  
> and corresponding create/updated/delete operations.
> 
> The point of having simple-methods exist for this instead of just  
> have "call create variation A" in the service definition is to make  
> it easy to customize and enhance. As functionality around certain  
> entities grows these methods do tend to grow beyond the base 2-4  
> operations that the typical minimal methods include.
> 
> So, yeah, it was intentional to have separate operations for things  
> like (all of these are just for creates, different combinations for  
> different things):
> 
> 1. make a value object
> 2. put a sequenced id in a single pk field for the object
> 3. move all primary key fields from the parameters or other Map into  
> the value
> 4. move non-pk fields from a Map into the value
> 5. set individual fields on the value
> 6. and so on...
> 
> We could identify a few variations and have single operations, or  
> avoid writing simple-methods altogether with the service def thing I  
> mentioned above, but that would just reduce consistency between  
> different simple-methods and make customization and extension more  
> difficult.
> 
> It seems like some recent comments stem from a disagreement that  
> consistency and ease of customization are important... that might be  
> an interesting thing to talk about explicitly. Much of the OFBiz  
> framework is meant for help just those things, where necessary  
> sacrificing other priorities, all part of optimizing the development  
> experience at the XML file level.
> 
> The driving factor behind that priority is that in most large  
> software it is complexity that kills projects and causes budgets to  
> spiral out of control. As complexity increases the time and cost  
> tends to increase in a non-linear way, ie something like  
> exponentially or logarithmically instead of linearly. When I say  
> complexity I mean general solution complexity across hundreds of  
> entities and services and screens, and not the complexity of a single  
> service. The point of defining the scope and purpose of a service is  
> to limit the complexity of that one piece to make it possible to  
> write and maintain it with a reasonable volume of requirements.
> 
> For OFBiz (both the framework and the applications) it is critical  
> that we all keep this in mind. It does us no good to create something  
> that supports super fast development if it makes ongoing maintenance  
> and extension/customization more difficult (including other people's  
> code or years later when you've forgotten and it might as well be  
> something someone else wrote). The point is to be as clear and  
> consistent as possible across a variety of data structures and  
> business processes.
> 
> When talking about framework improvements that should be the first  
> thing considered and written about when presenting ideas. Ideas that  
> don't help with that will be fought pretty hard by various people, me  
> being the most vocal, but rest assured that if I shut up others will  
> fill in because lots of people in the ofbiz community have experience  
> with this and know what kind of a difference it makes.
> 
> -David
> 
> 

Re: refactoring of similar simple-method

[David E Jones <jo...@hotwaxmedia.com>]

On Oct 16, 2007, at 12:51 PM, Jacques Le Roux wrote:

> De : "Adam Heath" <do...@brainfood.com>
>
>> Another point; in lots of simple method definitions, there are blocks
>> for doing CRUD to entities; in the vast majority of cases, these  
>> method
>> definitions are *identical*, except for the entity name and  
>> property to
>> pull error messages from.  This points to a need to refactor.
>
> IMHO, this point is very interesting, but of course need some work...

These were designed VERY specifically to be this way. It is true  
there are only a few common variations for different data structures  
and corresponding create/updated/delete operations.

The point of having simple-methods exist for this instead of just  
have "call create variation A" in the service definition is to make  
it easy to customize and enhance. As functionality around certain  
entities grows these methods do tend to grow beyond the base 2-4  
operations that the typical minimal methods include.

So, yeah, it was intentional to have separate operations for things  
like (all of these are just for creates, different combinations for  
different things):

1. make a value object
2. put a sequenced id in a single pk field for the object
3. move all primary key fields from the parameters or other Map into  
the value
4. move non-pk fields from a Map into the value
5. set individual fields on the value
6. and so on...

We could identify a few variations and have single operations, or  
avoid writing simple-methods altogether with the service def thing I  
mentioned above, but that would just reduce consistency between  
different simple-methods and make customization and extension more  
difficult.

It seems like some recent comments stem from a disagreement that  
consistency and ease of customization are important... that might be  
an interesting thing to talk about explicitly. Much of the OFBiz  
framework is meant for help just those things, where necessary  
sacrificing other priorities, all part of optimizing the development  
experience at the XML file level.

The driving factor behind that priority is that in most large  
software it is complexity that kills projects and causes budgets to  
spiral out of control. As complexity increases the time and cost  
tends to increase in a non-linear way, ie something like  
exponentially or logarithmically instead of linearly. When I say  
complexity I mean general solution complexity across hundreds of  
entities and services and screens, and not the complexity of a single  
service. The point of defining the scope and purpose of a service is  
to limit the complexity of that one piece to make it possible to  
write and maintain it with a reasonable volume of requirements.

For OFBiz (both the framework and the applications) it is critical  
that we all keep this in mind. It does us no good to create something  
that supports super fast development if it makes ongoing maintenance  
and extension/customization more difficult (including other people's  
code or years later when you've forgotten and it might as well be  
something someone else wrote). The point is to be as clear and  
consistent as possible across a variety of data structures and  
business processes.

When talking about framework improvements that should be the first  
thing considered and written about when presenting ideas. Ideas that  
don't help with that will be fought pretty hard by various people, me  
being the most vocal, but rest assured that if I shut up others will  
fill in because lots of people in the ofbiz community have experience  
with this and know what kind of a difference it makes.

-David