# Mixing Fowlers patterns

I am developing a large .NET app. The previous developer used Martin Fowlers Transaction script design pattern. Please see the code below:

Public Class TypeStudent
Private _Name As String
Public Property Name() As String
Get
Return _Name
End Get
Set(ByVal value As String)
_Name = value
End Set
End Property

Public Property Type() As String
Get
Return _Type
End Get
Set(ByVal value As String)
_Type = value
End Set
End Property
End Class

Public Class Students
Public Sub Add(ByVal typeStudent As TypeStudent)

End Sub

Public Sub Remove(ByVal typeStudent As TypeStudent)

End Sub

Public Sub Enrol(ByVal typeStudent As TypeStudent)
If typeStudent.Type = "U" Then
ElseIf typeStudent.Type = "P" Then
End If
End Sub
End Class


Notice that there is one Student class and Student.Enrol has to check the type of student before executing the appropriate logic. Now please see the refactored code below, which uses a domain model approach:

Public Class Student
Private Name As String
Private Type As String

End Sub

Public Sub Remove()

End Sub

End Class

Inherits Student

Public Sub Enrol()

End Sub

End Class

Inherits Student

Public Sub Enrol()

End Sub

End Class


Notice that Undergraduate and PostGraduate has its own implementation of Enrol. I want to refactor more code so that it is like sample B to make it more reuseable and maintainable. My question is; is it a bad idea to mix and match domain logic patterns in the same application i.e. part of the app written using Transaction Script and another part using domain model?

I don't think that there is inherently anything "wrong" with having multiple patterns like this in a single application, especially during a refactoring exercise. I would strongly suggest documenting the patterns that you are changing from and to and the reason for the modification so that future developers understand what is happening.

I would make one substantial modification to your proposed implementation, however: define Enrol at the Student level as an Overridable method.

If there is no default implementation for all students, change Overridable to MustOverride. This will in turn force Student to be declared as MustInherit, but this is ok if you can only call Enrol on instances of Undergraduate or Graduate.

• Thanks. +1 for the last paragraph. Have you mixed and matched domain layer patterns I.e. transaction script and domain model, in your own apps? Jun 3, 2013 at 21:54
• Yes, we have done this quite a bit. In some cases, we use the transaction script intentionally to make the classes easier to consume by external users (XML or json serialization, for example, where the method differences don't matter). For internal-only classes, our preferred pattern is domain, but we do have a lot of legacy code that has not been transitioned yet (if it isn't broken...). Jun 3, 2013 at 22:58
• Thanks. How does transaction script make serialisation easier? Jun 4, 2013 at 6:25