CODEWITHSUNDEEP
oopdrysoftware-design
zero_yu
zero_yu

Reputation: 503

How does abstractions help in DRY?

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.

Upvotes: 1

Views: 233

Answers (1)

sbp
sbp

Reputation: 973

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.

Upvotes: 1

Related Questions