OOP Design Question

[Scott Slater]

I am in the process of completely rewriting a fairly large application to take advantage of some newer things such as using SQL and coding with a more "object oriented" approach. I have recoded some of the data structures in the old code as objects where the elements become properties and methods are added for loading / saving / searching etc the individual records. So in essance I have converted some of my older TYPEs to smarter versions by using objects.

My problem is this; I have a structure (TYPE) in the older code that used DWORD elements as bit arrays for options toggles. I have updated this to a more readable form using the AS BIT identifiers and making each option its own element in the structure. This data is used throughout the program during run time as read-only data to determine how it should perform certain tasks. My question is this;

* Should this new TYPE BLOCK of BIT elements be placed inside of an object with similar properties for each element (there are a lot of them) or should the object simply return the entire type? Which way is the best practice in the OOP world?

I am relatively new to OOP concepts so I wanted to run this by some of you guys who have more experience in this department. I know it is only a minor design concept, but which way is the best and why?

I look forward to your replies... thanks in advance!

[Brian Chirgwin]

Tell, Don't Ask Principle

* Should this new TYPE BLOCK of BIT elements be placed inside of an object with similar properties for each element (there are a lot of them) or should the object simply return the entire type? Which way is the best practice in the OOP world?

I am not an expert either, but here is some info that might help.

I think the tell, don't ask principle might apply here.

http://www.pragprog.com/articles/tell-dont-ask

http://tagswap.net/articles/OOP_Principles_in_Action:_Tell,_Don%60t_Ask/

Simply put an object should perform its own actions. It should not tell its state [expose its internals] to other objects and let them perform the actions based on revealing its state. In other words, the logic of state should remain with the object that has that state.

On solution might be

Property get OptionsSet (Options() as long) as long

In the parameter set the options ON for those that you are interested in and have it return true if ALL are set. Options parameter is an array so the number is unlimited.

I am returning true or false if Options that are passed as parameters are set or not. The advantage of this is you are keeping the object internal details of how options are stored out of other objects. I would not return the complete TYPE for all Options.

Imagine in the future you want to double the number of options. This would require changing the return type (if you return the type). This would break all applications that use this object.

By returning true/false an existing application that doesn't care about the new options will still work without a change to the existing code.

Note: If there is a function OptionsSetCount, this can cause confusion in older apps when new options are added as the count of just the old options will be incorrect. Maybe this interface isn't as reusable as it should be.

While it may be a lot of work to create a property for each option, it does make it a contract that can't be broken.

Anyway, maybe this will get you on the right track. I'd like to know what you decide to do and why.

[Scott Slater]

Thanks Brian for your input.

I have been leaning toward the object containing ALL of the individual properties, due to the many other advantages. One such advantage would be updating the bit fields in real time and tracking internally the last time they were updated (changed by another workstation, this is a network ap). This would insulate the main ap from having to re-request the TYPE block at certain points in the code in order to make sure that it is fresh. The data would simply be up-to-date to the caller because the object would see to this.

Another reason I am leaning toward the object containing each property is that, this is simply a cleaner way of doing things in my opinion.

The primary reason I asked this question was to get others ideas and opinions on something of this scope.

[Brian Chirgwin]

Thanks Brian for your input.

I have been leaning toward the object containing ALL of the individual properties, due to the many other advantages. One such advantage would be updating the bit fields in real time and tracking internally the last time they were updated (changed by another workstation, this is a network ap). This would insulate the main ap from having to re-request the TYPE block at certain points in the code in order to make sure that it is fresh. The data would simply be up-to-date to the caller because the object would see to this.

A publish/subscribe type interface. Workstations could subscribe to the properties it is interested in. Using a event object, all subscribed workstations could be updated when a change occurs.

[Michael Mattias]

The scope is like lots of things, application-specific.

If the data are specific to an instance of the object, that data should be stored in an INSTANCE variable.

If the data are specific to all objects within a CLASS, the data should be kept at the class level.

If the data are not used and maintained only by objects - or any instance of an object of a particular class - it should not be stored with the object. If an object's method needs this 'other data' to 'do something' it should be passed as a parameter when the method is executed.

[Scott Slater]

I understand the scope, it was more or less which of these two methods of getting bit flags would be preferred and why? I have attached a sample code snippet showing both methods of using obtaining bit flag settings from an object.

#Compile Exe
#Dim All
 
Type BitToggles
   Item1 As Bit * 1 In Dword
   Item2 As Bit * 1
   Item3 As Bit * 1
   Item4 As Bit * 1
   Resvd As Bit * 28
End Type
 
Class Simple
 
   Instance Flags As BitToggles
   
   Class Method Create
      Flags.Item1 = 1
      Flags.Item2 = 0
      Flags.Item3 = 1
      Flags.Item4 = 0
   End Method
   
   Interface SimpleInterface
      Inherit IUnknown
      
      Method GetFlags As BitToggles
         Method = Flags
      End Method
      
   End Interface
 
End Class
 
Class Contained
 
   Instance Flags As BitToggles
 
   Class Method Create
      Flags.Item1 = 1
      Flags.Item2 = 0
      Flags.Item3 = 1
      Flags.Item4 = 0
   End Method
 
   Interface ContainedInterface
      Inherit IUnknown
      
      Property Get FlagItem1 As Dword
         Property = Flags.Item1
      End Property
 
      Property Get FlagItem2 As Dword
         Property = Flags.Item2
      End Property
 
      Property Get FlagItem3 As Dword
         Property = Flags.Item3
      End Property
 
      Property Get FlagItem4 As Dword
         Property = Flags.Item4
      End Property
 
   End Interface
 
End Class
 
Function PBMain () As Long
   
   Local Simp As SimpleInterface
   Local Flag As BitToggles
   Local Cont As ContainedInterface
   
   Simp = Class "Simple"
   Cont = Class "Contained"
   
   ' Two ways of obtaining the same data, simple method returns a whole type
   ' contained method returns individual values as properties
   
   Flag = Simp.GetFlags  ' get TypeVar from object - would be read from database by object in the real world.
   
   ? "Type Return Values:" & $Cr & $Cr & _
     "Item1 = " & Format$(Flag.Item1) & $Cr & _
     "Item2 = " & Format$(Flag.Item2) & $Cr & _
     "Item3 = " & Format$(Flag.Item3) & $Cr & _
     "Item4 = " & Format$(Flag.Item4), , "Simple"
     
   ? "Property Return Values:" & $Cr & $Cr & _
     "Item1 = " & Format$(Cont.FlagItem1) & $Cr & _
     "Item2 = " & Format$(Cont.FlagItem2) & $Cr & _
     "Item3 = " & Format$(Cont.FlagItem3) & $Cr & _
     "Item4 = " & Format$(Cont.FlagItem4), , "Contained"
   
   
   Simp = Nothing
   Cont = Nothing
 
End Function

Class Simple returns a whole UDT whereas class Contained only returns the individual elements of said type. These would be read-only in the main ap, but could be changed by a configuration ap. These are samples of what I am looking at doing as some very low-level classes. They would in turn be included in bigger classes, along with others.

I like the contained example better for my purposes, but have looked at the pros and cons of both.

[Michael Mattias]

Class Simple returns a whole UDT whereas class Contained only returns the individual elements of said type

What do you need / is most convenient in the application? That's what you should return.

For all we know, it might be best for the application to return the UDT not as a UDT, but as an OBJECT, which object has bit properties.