Does it make sense to have two classes related to 1: 1 power?

Question

Currently, I am engaged in computer engineering, and I remember the professor of the class "Introduction to Information Systems", which says that two classes related to the power of 1: 1 do not make sense.

For example: I have a Client class and a Telephone class. Suppose a customer can have only one telephone. The professor said that it makes no sense to create a Telephone class , and the phone should be an attribute of the Client class. I absolutely agree with him.

But now I take the Software Engineering class and professor (not the same thing) without commenting on this problem, and now I'm really confused about it.

What is the right approach?

Answer 1

I would say that your professor, Introduction to Information Systems, was right. And your SE professor too (if his lack of comments makes him the opposite). They are entitled depending on your requirements and the domain with which you work. But without any other details, it’s hard for you to model this for you, and I would lean toward what your professor in Europe said. Keep in mind all the fun principles you learned: KISS, DRY, etc., and apply them to your problem.

If the Client will never have more than one phone number, and no other object in your domain needs a phone number, then a separate Telephone class is not needed. In the real world, if your requirements are unclear, learn more from your client.

If someone along the way decides that Client can receive more than one phone number, or another object is entered into your domain that needs a phone number, this is a fairly simple refactoring to do.

So, referring to, say, your Client had a separate Address class, which instead included a phone number. Perhaps this Address class is reused by another class, perhaps Invoice or Shipment , where Address could be used or used in both cases. In this example, you may want Address ( Telephone ) to be its own class.

In your example, Telephone might be a little far-fetched. You want it to be a separate class for reuse if it had many properties ( AreaCode , InternationalPrefix , Number , etc.), but if Client just needed a string value called Telephone , which the user would enter for reference only, then it probably doesn't make sense to be his own class.

Answer 2

If you want to reuse the Telephone class, it will not be very useful to have it as part of the Client class. That would be a very good reason. If you leave it in the Client class, it means that it is an integral part of the Client , even if you use it elsewhere, which I doubt you have ever meant.

Sometimes, however, it makes sense to model 2 objects with a 1: 1 ratio as separate classes. Perhaps you have Client , and you also have ClientBilling . You do not want all your programmers to have access to ClientBilling , so you move it to your class, where it can be controlled separately.

Perhaps your structure is huge, and the delivery of all this is usually not required. By disassembling it into functional parts, you can reduce the size of the data only to those that are necessary for a particular function.

Perhaps 1: 1ness is not necessarily an integral part of the data, and a reasonable guess is that this will not always be so. For example, the Telephone example falls into this category.

Answer 3

I would say that 1: 1 relationships (always at both ends) are suspicious and must be carefully considered to ensure they are necessary. This is usually a compromise between the flexibility and simplicity of the diagram (flexibility, since in the future it will be easier to change the diagram and adapt it to new requirements if you keep two classes versus simplicity to have one class instead of two)