Always using custom data types [closed]

Closed. This quest开发者_JAVA技巧ion is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I'm wondering whether it's insane to (almost) always use custom data types in C# rather than relying on built in types such as System.Int32 and System.String.

For instance, to represent a persons First name, the idea is to use a data type called PersonFirstName rather than System.String (of course, the PersonFirstName data type would have to contain a System.String). Another example is to have a PersonID class which represents the database identifier for the person, rather than to have a System.Int32.

There would be some benefits here:

• Today, if a function takes an int as parameter, it's easy to pass in an ID of a Company object rather than the ID of an Person object, because both are of types int. If the function took a CompanyID, I would get a compilation error if I tried to pass in a PersonID.

• If I want to change the database column data type from int to uniqueidentifier for a Person, I would only have to make the change in the PersonID class. Today, I would have to make changes in all places which takes an Int and is supposed to represent a company.

• It may be easier to implement validation in the right places. " " may never be a correct first name, which PersonFirstName can take care of.

Yes, I would have to write more constructors. I could implement implicit overloading in these to make them easy to work with though.

Is this madness?

---

Yes, utter madness - to sum up your idea, and to Paraphrase Blackadder

It's mad! It's mad. It's madder than Mad Jack McMad, the winner of this year's Mr Madman competition

---

I don't think that's madness. I think using business logic objects with strongly typed objects is a very good thing

---

No, you're not getting any real benefit of that. For some things it makes sense, perhaps an Email class or maybe, maybe an ID class. However, having a "PersonID" or "ClientID" class seems to go far. You could have a "typedef" or alias or whatever but I would not go too far with this in most circumstances. You can go overboard very quickly and end up with a lot of work for no benefit.

---

Yes... It is ! You will lose more than you gain.

---

Yes, madness AND OVERKILL...

---

It sounds like a maintenance nightmare to me. what would the CompanyID constructor take? An integer? Sooner or later - you are going to have to use native types whether you like it or not.

---

So what I see here at first glance is a question within a question. Basically:

How do I mitigate complexity and change in my code base?

I would say that you need to look at the problem you are trying to solve and first see what the best solution is going to be. If you are dealing with something that is potentially going to be pervasive throughout your code base then you might want to see if you are violating SOLID design principles. Chances are that if you have one type that is being used in A LOT of different places your design is way too coupled, and you have a poor separation of concerns.

On the other hand, if you know that this type is going to be used in a lot of places, and it also happens to be very volatile (changes is certain), then the approach you mention above is probably the right way to go.

Ask yourself "What problem am I trying to solve?" and then choose a solution based on that answer. Don't start with the answer.

---

As extracted from Code Complete by Steve McConnell:

The object-oriented design would ask, "Should an ID be treated as an object?" Depending on the project's coding standards, a "Yes" answer might mean that the programming has to write a constructor, comment it all; and place it under configuration control. Most programmers would decide, "No, it isn't worth creating a whole class just for an ID. I'll just use ints.

Note what just happened. A useful design alternative, that of simply hiding the ID's data type, was not even considered...

For me, this passage is a great answer to your question. I'm all for it.