Announcement

Collapse
No announcement yet.

OOP Design Question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    Michael Mattias
    Member

  • Michael Mattias
    replied
    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.

    Leave a comment:

  • Scott Slater
    Member

  • Scott Slater
    replied
    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.

    Leave a comment:

  • Michael Mattias
    Member

  • Michael Mattias
    replied
    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.

    Leave a comment:

  • Brian Chirgwin
    Member

  • Brian Chirgwin
    replied
    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.

    Leave a comment:

  • Scott Slater
    Member

  • Scott Slater
    replied
    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.

    Leave a comment:

  • Brian Chirgwin
    Member

  • Brian Chirgwin
    replied
    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.

    Leave a comment:

  • Scott Slater
    Member

  • Scott Slater
    started a topic OOP Design Question

    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!
Working...
X