How does abstractions help in DRY?

Question

When we search "Don't repeat yourself" on Wikipedia, the first sentence is:

In software engineering, don't repeat yourself (DRY) is a principle of software development aimed at reducing repetition of software patterns, replacing them with abstractions...

I know that abstractions in software engineering mean hiding implementation complexity of how the behaviors of an API are realized, but it seems that "abstractions" in this sentence is not what I know before. Could someone explain to me what abstraction means here? It would be better if you could give me an example.

Hiding implementation details is encapsulation not abstraction — apokryfos, Feb 17 '18 at 16:10
@apokryfos Ok I change implementation details to implementation complexity — zero_yu, Feb 17 '18 at 16:27
That's still not what abstraction is. There's no hiding in abstracting. There's just simplifying. — apokryfos, Feb 17 '18 at 16:27
@apokryfos https://stackoverflow.com/questions/11965929/abstraction-vs-encapsulation-in-java So is the highest-voted answer wrong in this post? — zero_yu, Feb 17 '18 at 16:31
Hiding is definitely a bad choice of wording. There is no hiding involved. It's more simplifying. It's composition of a complex system from simple atoms. — apokryfos, Feb 17 '18 at 16:33
No idea why it was downvoted it's a reasonable questions for those tags albeit it may just be a misunderstanding of the terms. — apokryfos, Feb 17 '18 at 16:43
DRY should be maintained in the context of concept should not duplicated. I think its okay to duplicate code for the valid intention. — Eldho, Feb 19 '18 at 08:10

sbp · Accepted Answer · 2018-02-19T06:23:52.077

I know that abstractions in software engineering mean hiding implementation complexity of how the behaviors of an API are realized

Yes it means that (absstraction@wikipedia) and very same concept can also be leveraged to reduce repetitions! Or in other words, it can be used to practice DRY.

Let me try to explain that with an example. First I'll show non DRY code (without abstraction), then with use of abstraction I'd try to reduce repetitions.

Let's assume that you wanted to build an email view model based on application form details filled out by applicant and there is an email view class which consumes this emailViewModel to show all non-null details from application form. You could write it like in below example (first attempt)

public class ApplicationForm
{
        public AddressDetail AddressDetail { get; set; }
        public CustomerDetail CustomerDetail { get; set; }
        public ProductDetail ProductDetail { get; set; }
}

public class EmailViewModel
{
    public EmailViewModel(ApplicationForm applicationForm)
    {
        Address = GetAddressDetail(applicationForm.AddressDetail);
        Customer = GetCustomerDetail(applicationForm.CustomerDetail);
        Product = GetProductDetail(applicationForm.ProductDetail);
    }

    public string Address { get; set; }
    public string Customer { get; set; }
    public string Product { get; set; }
}

//view code assume razor view
@if(Model.Address!=null)
{
    // method for showing address
}
@if(Model.Customer!=null)
{
    // method for showing customer
}
//and other properties

I've kept above code quite simple; only three properties and haven't showed declaration for conversion methods. What if there were 50 properties! In this first approach it would be cumbersome changes that you'd be making in three places. Now I'll show you second example code of how you could create an interface (a way of abstraction) implement DRY.

    interface IFormDetail
{
    IFormDetailView GetDetail();
}
interface IFormDetailView
{
    string ShowView();
}

public class ApplicationForm
{
        public List<IFormDetail> FormDetails {get;set;}
}

public class EmailViewModel
{
    public EmailViewModel(ApplicationForm applicationForm)
    {
        if(applicationForm.FormDetails!=null)
        {
            FormDetails = new List<IFormDetailView>();
            foreach(var detail in applicationForm.FormDetails)
            {
                FormDetails.Add(detail.GetDetail());
            }
        }
    }

    public List<IFormDetailView> FormDetails { get; set; }

}

//view code assume razor view
@f(Model.FormDetails!=null)
{
    foreach(var detail in Model.FormDetails){
        detail.ShowView();
    }
}

In this second code example , when you've a new property, you'll only make one change when a new application form property is created.

So while we are hiding complexity of how detail is presented etc., we are also leveraging it to reduce repetition.

How does abstractions help in DRY?

1 Answers1