| 37 | | 1. Add a new select command e.g. FdoIJoinSelect derived from FdoISelect, add a new command type and caller needs to ensure that command exist in the provider command capabilities before calling this interface. A small improvement here we can add two classes FdoIJoinSelect (the interface having only pure methods) and !FdoJoinSelect (having a default implementation of those methods). All providers can use the class with a base implementation and in the future in case we want to add a new method we just add a default implementation in !FdoJoinSelect, however this adds more complexity to the API since developer would be confused which class should use as base class in his implementation. |
| 38 | | |
| 39 | | |
| 40 | | |
| 41 | | 2. Enhance FdoISelect, then create a !FdoSelect base class and add default implementers for !GetFeatureClassNames () and !GetJoinCriteria(). Then each provider would be changed to base their select command implementation on !FdoSelect instead of FdoISelect. Two new capability functions will be added so that applications can determine: if a provider supports the join criteria and supported join types, !SupportsJoins() & !GetJoinTypes(). Again, if future enhancements are ever made to FdoISelect, the need to change each provider would be eliminated. |
| 42 | | |
| 43 | | |
| 44 | | |
| 45 | | 3. Enhance FdoISelect, add two new methods ‘!GetFeatureClassNames()’ and ‘!GetJoinCriteria()’ with a default implementation throwing an exception. Providers which want to implement these new methods just can override then and provide a detailed implementation. Even FdoISelect is declared as ‘interface’ we do not have interfaces in C++ and we can have all other abstract methods and only the new one with a default implementation. A good example here would be locking methods from select command: most of the provider do not support locking and have to provide an empty implementation (usually to throw an exception), so more code on provider side when we could just provide a default implementation in the base class. Following this path we just modify the base class and all other providers will not be changed since will inherit the default implementation. Looking at FdoISelect there are already two methods which provide default implementation: !AddRef() and Release(), so adding default implementation for the new methods will not be something totally new. |
| 46 | | |
| 47 | | |
| | 37 | * Add a new select command e.g. FdoIJoinSelect derived from FdoISelect, add a new command type and caller needs to ensure that command exist in the provider command capabilities before calling this interface. A small improvement here we can add two classes FdoIJoinSelect (the interface having only pure methods) and !FdoJoinSelect (having a default implementation of those methods). All providers can use the class with a base implementation and in the future in case we want to add a new method we just add a default implementation in !FdoJoinSelect, however this adds more complexity to the API since developer would be confused which class should use as base class in his implementation. |
| | 38 | * '''Pro''': will not change the FdoISelect command, all other providers do not have to change anything on their side, and only in case a provider wants to support this command it has to implement it and expose it as supported.[[BR]] |
| | 39 | * '''Cons''': We add a new command and a new type command, we already have a FdoIExtendedSelect for scrollable readers and users can be confused by those two commands. This will add more complexity in the API. |
| | 40 | |
| | 41 | * Enhance FdoISelect, then create a !FdoSelect base class and add default implementers for !GetFeatureClassNames () and !GetJoinCriteria(). Then each provider would be changed to base their select command implementation on !FdoSelect instead of FdoISelect. Two new capability functions will be added so that applications can determine: if a provider supports the join criteria and supported join types, !SupportsJoins() & !GetJoinTypes(). Again, if future enhancements are ever made to FdoISelect, the need to change each provider would be eliminated. |
| | 42 | * '''Pro''': this solution will not add more complexity to the API.[[BR]] |
| | 43 | * '''Cons''': We need to change all the providers leading to a big effort from everyone. |
| | 44 | |
| | 45 | * Enhance FdoISelect, add two new methods ‘!GetFeatureClassNames()’ and ‘!GetJoinCriteria()’ with a default implementation throwing an exception. Providers which want to implement these new methods just can override then and provide a detailed implementation. Even FdoISelect is declared as ‘interface’ we do not have interfaces in C++ and we can have all other abstract methods and only the new one with a default implementation. A good example here would be locking methods from select command: most of the provider do not support locking and have to provide an empty implementation (usually to throw an exception), so more code on provider side when we could just provide a default implementation in the base class. Following this path we just modify the base class and all other providers will not be changed since will inherit the default implementation. Looking at FdoISelect there are already two methods which provide default implementation: !AddRef() and Release(), so adding default implementation for the new methods will not be something totally new. |
| | 46 | * '''Pro''': this solution will not add more complexity to the API, we do not need to change any provider.[[BR]] |
| | 47 | * '''Cons''': None. |
