Beginning of Software Design

Requirement: Design an Actor class which has personal details and social media links.

A note on design:

The current design, with direct properties for each social media link and separate methods for updating/removing each, is more rigid and might lead to more boilerplate code as the number of social media platforms increases.

This design has some potential disadvantages:

1. Rigidity:
   • If you wanted to add support for another social media platform, you'd have to modify the Actor class, adding a new property and accompanying methods to update and remove the link. This breaks the Open/Closed Principle (OCP) of SOLID, which states that a class should be open for extension but closed for modification.
2. Duplication:
   • The IsValidLink method is invoked in every UpdateXXXLink method. If the validation logic changes, it will be correctly applied across all methods, but the repetitive structure is a red flag that there might be a more elegant design solution.
3. No Single Responsibility:
   • The Actor class is currently handling both the data representation of an actor and the management and validation of links. This can be seen as a violation of the Single Responsibility Principle (SRP) of SOLID. Ideally, an Actor shouldn't have to be concerned with the intricacies of URL validation.
4. Null State Ambiguity:
   • Using null to represent the absence of a link can lead to potential null reference exceptions if not handled properly elsewhere in the code. While setting the value to null does represent the absence of a value, it requires other parts of your application to consistently check for null before using a link.
5. Lack of History/Tracking:
   • In the current design, there's no way to keep track of changes to an actor's social media links. If link history or auditing is a requirement (either now or in the future), this design would need to be significantly refactored.
6. Potential for Incomplete Removals:
   • If a developer forgets to call the removal method, old data might remain in the system. In the design where links were contained in a list, you could have just cleared the list or removed specific items, ensuring all links of that type were removed.
7. Scalability Concerns:
   • As new properties or methods are added, this class will grow, making it harder to maintain. A larger class tends to be more error-prone and harder to debug.

Recommendation:

A more flexible approach would involve encapsulating the behaviour and data of social media links into their own classes (as shown in the next designs). It allows for easier additions of new link types, centralized validation logic, and a clearer separation of concerns.