Re: Is that a good design?



On Feb 29, 2:40 pm, "Cowboy \(Gregory A. Beamer\)"
<NoSpamMgbwo...@xxxxxxxxxxxxxxxxxx> wrote:
The factory pattern is very useful whenever you think you might end up with
a change in implementation. This can be due to different clients, different
projects, etc. That part is fine.

I do not see the sense in the User object as it is, however. If you are
creating an object that gets a user, okay, but I would call it something
other than User, lest it be confused with the actual user object. If what I
am seeing here is the actual User object, I am against the implementation,
as the User object should be a data object, with little or no behavior.

public class User
{
    public string UserName;
    public string FirstName;
    public string LastName;

}

etc.

I would then create some form of collection. Perhaps something like:

public class UserCollection : List<User>
{

}

You can then create a class that creates Users or UserCollections. That
class may be a factory, if there are different types of users, or you might
use a factory to instantiate that class. Both are acceptable patterns. I
would not name this class User, however, as it leads to potential name
clashes.

In general, I do not like objects that fill themselves. While this can be
very useful for lazy loading, you generally end up hammering the database to
fill thousands of objects, which counteracts the one of the primary reasons
for lazy loading (reducing database hits).

Hope this helps.

BTW, while I am not completely sold on their architecture, dofactory.com has
a reference architecture that shows the use of patterns. It does show how to
use the patterns, which is nice, although I would have to code gen the
boilerplate code in their implementation if I were heading that route (to
not do so means you have a more complex architecture for no reason, IMO).

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************


Hi Gregory!

I see your point and I agree with you. The only thing I am failing to
see is how can I use inheritance on this design. Since my clients can
access my implementation only through my factory, what people do when
it comes to inheritance? Suppose my client needs to specialize some
feature of my User class. How do I allow this when using the Factory
pattern?

TIA,
Robert Scheer
.



Relevant Pages

  • Re: login script
    ... Set objNetwork = CreateObject ... On Error GoTo 0 ... If your clients are older, the method you select depends on the client OS. ... binding to the user object in Active Directory or NT and retrieving values ...
    (microsoft.public.scripting.vbscript)
  • Re: MAC OS X Integration
    ... Why do you believe that editing a user object is problematic in Ad if you ... I am unfamiliar with the Apple products you mention but initial issue you ... > I have a very unique problem here in attempting to integrate MAC OS X ... clients with our existing AD. ...
    (microsoft.public.windows.server.active_directory)
  • Re: MAC OS X Integration
    ... Why do you believe that editing a user object is problematic in Ad if you ... I am unfamiliar with the Apple products you mention but initial issue you ... > I have a very unique problem here in attempting to integrate MAC OS X ... clients with our existing AD. ...
    (microsoft.public.windows.server.active_directory)