طراحی توسط قرارداد: چگونه می توان قابلیت اطمینان کد خود را افزایش داد

اگر ردیابی یا سیستم هایی که به نظر می رسد بدون دلیل ظاهری شکسته شده اند ، با اشکالات دشوار روبرو شده اید ، می دانید چگونه قابلیت اطمینان کد بسیار مهم است چه می شود اگر من به شما بگویم که تکنیکی وجود دارد که می تواند به جلوگیری از بسیاری از این مشکلات کمک کند؟ من در مورد صحبت می کنم طراحی با قرارداد (DBC) ، رویکردی که می تواند نحوه توسعه نرم افزار را تغییر دهد.

در این پست ، ما بررسی خواهیم کرد که طراحی با قرارداد ، نحوه کار آن و چرا باید آن را در پروژه بعدی خود در نظر بگیرید. بیا بریم؟ 👨‍💻👩‍💻

طراحی با قرارداد چیست؟ 🤔

ای طراحی با قرارداد این یک روش توسعه نرم افزار است که مسئولیت های بین قسمت های مختلف کد را به وضوح تعریف می کند. ایده اصلی این است که هر روش یا عملکرد دارای “قرارداد” است که مشخص می کند:

• پیش شرط: آنچه باید قبل از اجرای روش صادق باشد.
• پس از اختراع: پس از انجام روش باید صادق باشد.
• متغیر طبقاتی: شرایطی که باید در طول چرخه زندگی یک شیء صادق باشد.

این رویکرد توسط محبوبیت پیدا شد Bertrand Meyer، نویسنده کتاب “ساخت نرم افزار شی گرا”، و به طور گسترده ای برای افزایش استحکام و وضوح کد استفاده می شود.

چرا از طراحی با قرارداد استفاده می کنیم؟ 💡

تصور کنید که شما در حال ساخت یک سیستم پرداخت هستید. روشی که پرداخت ها را پردازش می کند باید اطمینان حاصل کند که:

1. قبل از دویدن: مبلغ پرداخت مثبت است (پیش شرط).
2. پس از اعدام: مانده حساب به درستی به روز می شود (پس از شرط).
3. همیشه: تعادل هرگز منفی نیست (کلاس ثابت).

اگر این شرایط به وضوح تعریف و تأیید شده باشد ، شما به شدت احتمال خطا را کاهش داده و نگهداری کد را تسهیل می کنید. باحال ، درست است؟ 😎

پیش شرط ها: نقطه شروع

به عنوان پیش شرط آنها چک هایی هستند که قبل از اجرای یک روش انجام شده اند. آنها اطمینان می دهند که پارامترهای ورودی انتظارات را برآورده می کنند. به عنوان مثال:

public void adicionarPagamento(Pagamento pagamento) {
    if (pagamento == null || pagamento.getValor() <= 0) {
        throw new IllegalArgumentException("Pagamento inválido!");
    }
    // Lógica para adicionar o pagamento
}

در اینجا ، ما اطمینان می دهیم که پرداخت باطل نیست و مبلغ مثبت است. اگر این شرایط برآورده نشود ، این روش حتی سعی در اجرای آن ندارد ، و از مشکلات آینده جلوگیری می کند.

پس از شرط: اطمینان از نتیجه

به عنوان پس از اختراع تأیید کنید که آیا وضعیت سیستم یا بازگشت روش پس از اجرای صحیح است. به عنوان مثال:

public void aceitarConvite(Convite convite) {
    if (convite.getDataAceite() != null) {
        throw new IllegalStateException("Convite já aceito!");
    }
    // Lógica para aceitar o convite
    if (convite.getDataAceite() == null) {
        throw new IllegalStateException("Data de aceite não foi definida!");
    }
}

در اینجا ما تضمین می کنیم که دعوت فقط یک بار قابل قبول است و تاریخ پذیرش به درستی تعریف می شود.

متغیر کلاس: قوام شی

به عنوان متغیر طبقاتی اینها شرایطی است که باید در طول چرخه زندگی یک شیء صادق باشد. به عنوان مثال:

public class Usuario {
    private String nome;
    private List<Agenda> agendas;

    public Usuario(String nome) {
        this.nome = nome;
        this.agendas = new ArrayList<>();
        this.agendas.add(new Agenda(nome)); // Invariante: Todo usuário tem uma agenda
    }

    public void adicionarAgenda(Agenda agenda) {
        if (agenda == null) {
            throw new IllegalArgumentException("Agenda inválida!");
        }
        this.agendas.add(agenda);
    }
}

در اینجا ، ما تضمین می کنیم که هر کاربر بدون در نظر گرفتن روشی که نامیده می شود حداقل یک برنامه مرتبط داشته باشد.

طراحی توسط قرارداد در مقابل برنامه نویسی دفاعی 🛡

بوها برنامه نویسی دفاعی شامل تأیید بیش از حد شرایط (مانند چند برابر است ifS) ، که می تواند به کد اضافی و پیچیده منجر شود. در حال حاضر طراحی با قرارداد این یک رویکرد واضح تر و مستقیم تر پیشنهاد می کند ، از چک های غیر ضروری و تمرکز بر محدودیت های تعریف شده خوب استفاده می کند.

به عنوان مثال ، به جای انجام:

if (lista != null && !lista.isEmpty()) {
    // Lógica
}

شما به سادگی می توانید تعریف کنید که لیست به عنوان پیش شرط نمی تواند صفر یا خالی باشد:

public void processarLista(List<String> lista) {
    if (lista == null || lista.isEmpty()) {
        throw new IllegalArgumentException("Lista inválida!");
    }
    // Lógica
}

ادغام با تست های خودکار

تست های خودکار می توانند تأیید کنند پس از اختراعاما نیاز به آن را جایگزین نکنید پیش شرط در کد ترکیبی از پیش شرط و تست های خودکار باعث افزایش قابلیت اطمینان سیستم می شود.

به عنوان مثال ، در یک تست خودکار:

@Test
public void testAdicionarPagamento() {
    SistemaPagamento sistema = new SistemaPagamento();
    sistema.adicionarPagamento(new Pagamento(100.0));
    assertEquals(100.0, sistema.getSaldo());
}

در اینجا ، ما بررسی می کنیم که آیا مانده پس از افزودن پرداخت به درستی به روز شده است یا خیر.

چه موقع از استثنائات استفاده کنیم؟ 🚨

استثنائات باید برای موقعیت ها استفاده شود استثنایی و غیر منتظره، مانند پارامترهای نامعتبر یا خطاهای سیستم. موقعیت های مورد انتظار (مانند سهام کافی) باید با بازده روشن رفتار شود ، نه با استثنائات.

به عنوان مثال:

public Resultado abaterEstoque(int quantidade) {
    if (quantidade > estoqueDisponivel) {
        return new Resultado("Estoque insuficiente");
    }
    // Lógica para abater o estoque
    return new Resultado("Estoque abatido com sucesso");
}

نتیجه گیری: چرا طرح را با قرارداد اتخاذ می کنید؟ 🎯

ای طراحی با قرارداد این یک روش قدرتمند برای افزایش قابلیت اطمینان و کیفیت کد است. با تعریف واضح پیشگیری ، پس از شرط و متغیر کلاس ، می توانید:

• خطاها را پیش بینی کنید: قبل از وقوع اشکالات خودداری کنید.
• تعمیر و نگهداری را تسهیل کنید: درک کد را واضح تر و آسان تر کنید.
• استحکام را بهبود بخشید: اطمینان حاصل کنید که سیستم به درستی در سناریوهای مختلف کار می کند.

بنابراین در مورد شروع به کاربرد این تکنیک ها در پروژه بعدی خود چطور؟ کد شما (و عقل شما) متشکرم! 😉

یادگیری کلیدی و بینش

1. قابلیت اطمینان اساسی است: کیفیت کد مستقیماً با قابلیت اطمینان آن مرتبط است.
2. پیش شرط ها ضروری هستند: تأیید شرایط ورودی روشها مؤثرترین روش برای جلوگیری از خطا است.
3. متغیرها قوام را تضمین می کنند: شرایطی که همیشه باید واقعی باشد ، به حفظ وضعیت شیء سازگار کمک می کند.
4. استثنائات برای موقعیت های استثنایی: از استثنائات فقط برای خطاهای غیر منتظره استفاده کنید ، نه برای جریان عادی تجارت.
5. DBC را با تست های خودکار ترکیب کنید: ادغام آزمایش های پیش از شرط و خودکار ، قابلیت اطمینان سیستم را به حداکثر می رساند.

بنابراین ، آیا پست را دوست داشتید؟ آیا قبلاً از طراحی با قرارداد در پروژه های خود استفاده می کنید؟ تجربیات خود را در نظرات به اشتراک بگذارید! 👇