D
designconcepts
bo'jour, bo'jour,
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on
some comments by the chief designer of C#. Those of you who are junkies for
design principle might be interested in contributing to this thread.
I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use
objects as representations, and the path you choose in this respect has a
big impact on the way you write code. For instance, does your user object
represent a copy of data about a user or does it represent the user
him/herself?
This made me think about how we represent users in web applications.
Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save'
button that does the obvious.
The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)
Each possibility represents a different way of looking at the user object
(as an avatar for the real user vs. a representation of user information).
If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price
of efficiency and maintainability (you'll be making more calls to the data
store, and the entity itself will be interacting with data directly rather
than having a workflow object pass the entity through various stages of
processing).
I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out
in a follow-up if this post is successful in starting a thread.
Thanks for your input, and I hope to hear more from you all.
So I have question to present to the forum about OOD. This is a Csharp
forum, but C# is the lang of choice and the question is an exercise based on
some comments by the chief designer of C#. Those of you who are junkies for
design principle might be interested in contributing to this thread.
I was recently reading some interviews with the chief engineer for C#
(formerly Mr. Delphi), and he made an interesting comment about how you use
objects as representations, and the path you choose in this respect has a
big impact on the way you write code. For instance, does your user object
represent a copy of data about a user or does it represent the user
him/herself?
This made me think about how we represent users in web applications.
Scenario: web application lets users change information about themselves
(address, billing info, etc), information about each is in persistent
storage somewhere. Web form has fields for address information and a 'save'
button that does the obvious.
The question is this:
Do you:
1) instantiate a user object, set appropriate fields and call a user.save()
method
2) instantiate a user object, and each time you set a property, the set
handler updates the persistent storage immediately
2) instantiate a user object, usrMyUser, set appropriate fields, instantiate
a workflow object for a UserManager (for instance) and call
UserManager.SaveUser(usrMyUser)
Each possibility represents a different way of looking at the user object
(as an avatar for the real user vs. a representation of user information).
If the user object is a representation of user information, in theory it
wouldn't have any methods, simply properties and be nothing more than a
custom data type. If the user object is an avatar, it will come at the price
of efficiency and maintainability (you'll be making more calls to the data
store, and the entity itself will be interacting with data directly rather
than having a workflow object pass the entity through various stages of
processing).
I think this is a legitimate question about design technique, but if you
think I'm missing something obvious, please let me know. I'd like to see a
conversation develop about the pros and cons to each approach or new
approaches I haven't mentioned here. I've got definite critical opinions
about each of the options mentioned above, but I'll wait to point them out
in a follow-up if this post is successful in starting a thread.
Thanks for your input, and I hope to hear more from you all.