Announcement

Collapse
No announcement yet.

OOP Design Question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OOP Design Question

    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!
    Scott Slater
    Summit Computer Networks, Inc.
    www.summitcn.com

  • #2
    Tell, Don't Ask Principle

    Originally posted by Scott Slater View Post

    * 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_Prin...,_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

    Code:
    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.

    Comment


    • #3
      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.
      Scott Slater
      Summit Computer Networks, Inc.
      www.summitcn.com

      Comment


      • #4
        Originally posted by Scott Slater View Post
        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.

        Comment


        • #5
          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.
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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.

            Code:
            #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.
            Scott Slater
            Summit Computer Networks, Inc.
            www.summitcn.com

            Comment


            • #7
              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.
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment

              Working...
              X