I came across a design in which there are different projects for the methods and data.
Example 1
What I meant is normally, if we have a USER class then
class user
{
int userid;
string username;
//methods
public void Adduser(int id, string Name)
{
}
public void RemoveUSer(int id)
{
}
}
We have a user object, attributes and the methods to manipulate the attributes. This is a normal design.
Example 2
what I came across are,
two projects
project 1. BusinessObjects
Project 2. Types (types for business objects)
Project 1 :
Public Class AddUser(AddUserInput input)
{
Public void Execute()
{ //logic to add the user
}
}
Public class RemoveUser (RemoveUserInput input)
{
Public void Execute()
{ //logic to remove the user
}
}
Public Class User: Basetypes
{
int id;
string name
//overridden methods
}
public class Basetype
{
//methods to override
gethashcode();
isnull();
isempty()
equals(); //etc
}
Project 2:
Public class AdduserInput : IOType
{
int id,
string Name
//overridden methods
}
public class RemoveUserInput : IOType
{
int id;
//overridden methods
}
public class IOType
{
//methods to override
gethashcode();
isnull();
isempty()
equals(); //etc
}
As you can see different projects for methods and for the Types
---------------
I stronlgy disagree with the Example 2
because
1. No proper encapsulation ( data and methods are separated and any one can act on the methods)
2. The objects will be scatterd in the user interface. ( user interface will know the inner details of the business logic)
3. Design patterns can not be followed
4. Inheritance can not be used as c# doesn't support multiple inheritance and here all the objects inherit from BASETYPES. So no relationships can be established.
5. unnecessary coding
6. Design was selected before proper analysis of the requirements.
-------------------------
I need experts opinion on this Please. I feel encapsulation and inheritance are broken here .