Is that a good design?

[Robert Scheer]

Hi.

I could not find an specific group on patterns, so I am posting
here...

We are trying to develop some patterns to be used on .NET development.
An independent consultant recommend us that we start by using the
Class Factory pattern to help in isolate our code. Our team though, is
complaining that the design is complicated to develop with. I would
like your opinion about this design. Following is a sample of the
recommendation:

Public Interface IUser
Function ReadDetail(ByVal user As String) As String
End Interface

Public Class UserFactory

Private Sub New()
End Sub

Public Shared Function GetInstance() As IUser
Return User.GetUserInstance
End Function

End Class

Friend Class User
Implements IUser

Private Shared _user As User

Public Shared Function GetUserInstance() As User
Try
If _user Is Nothing Then
_user = New User
End If
End Try

Return _user
End Function

Public Function ReadDetail(ByVal user As String) As String
Implements IUser.ReadDetail
'Code goes here
End Function
End Class


On the client side, we have to call the User implementation through
its interface always:

Dim u As IUser = UserFactory.GetInstance
Dim s As String = u.ReadDetail('Robert')

Is it the recommended way to work? Does it allow for inheritance?
Utilities classes should also go this way?

Your opinion is really appreciated!!

Regards,
Robert Scheer

 

[Cowboy \(Gregory A. Beamer\)]

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!
|
*************************************************

 

[sloan]

I don't like objects that populate themselves either.

I prefer a Controller or Manager

The way I would state it would be
"Seperate the objects...from the code that creates them".

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!139.entry

I have a 2.0 version of that entry as well.

 

[Cowboy \(Gregory A. Beamer\)]

We got some code back from a vendor at one time that had each object aware
of its data context. There were two issues with this:

1. The object was coupled to a particular schema (could have been abstracted
with sprocs, I guess, but it was not)
2. When you filled a large report, you slammed the database with dozens of
connections. Ouch!

By separating out the in memory representation of data (state) from its
creator (behavior), you can avoid both of these problems (coupling and
hammering the DB).

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

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

 

[sloan]

Since I"ve never mixed them....I've never run into the issues.

I would have been able to reason the first gotcha.

The second one would have been only by experience I think.

But "well put"..this goes into the concrete list of reasons not to do it.

......

That's why I like the multiple resultsets in one datareader method .....
The db connections stay slim and trim.

 

[Robert Scheer]

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