Alternatives to OOP in D
Peter C
peterc at gmail.com
Wed Nov 12 01:25:33 UTC 2025
On Tuesday, 11 November 2025 at 07:50:05 UTC, Serg Gini wrote:
> On Tuesday, 11 November 2025 at 07:12:38 UTC, Peter C wrote:
>> ...
>> Adair Dingle, in his award winning book from 2014, titled
>> 'Software Essentials Design and Construction', correctly
>> asserts that it is 'software maintenance' that dominates the
>> software life cycle.
>
> k
>
>> So patterns and paradigms are not just an arbitrary choice.
>
> Yes they are
>
No they are not!
Patterns and paradigms are fundamental engineering tools.
They both contribute significantly to creating recognizable and,
therefore (hopefully), more correct and maintainable code.
When you erode core principles (like encapsulation for example),
it can lead to unpredictable and less maintainable code.
For example, what is the paradigm used below? (a paradigm that D
enables)
module myModule;
private string globalToken;
// This may look like an OOP class,
// but it behaves like a procedural function operating on global
data.
public class User
{
private string username;
private string password;
public this(string username, string password)
{
this.username = username;
this.password = password;
}
public void Authenticate()
{
// Simulate authentication logic
if (password == "secret")
{
globalToken = "abc123"; // modifies shared global
state
}
}
public string GetUsername() => username;
}
// This function operates outside the User class but,
// due to module-level encapsulation, it can directly access
// and modify 'private' members of the userInstance.
public void OverridePassword(User userInstance, string
newPassword)
{
userInstance.password = newPassword;
}
// A function outside the User class, but inside the module,
// directly modifies shared global state.
public void LogoutGlobal()
{
if (globalToken != null)
{
globalToken = null;
System.Console.WriteLine("System-wide token
invalidated.");
}
}
More information about the Digitalmars-d-learn
mailing list