Ochiq/Yopiqlik tamoyili
Prinsiplar +2 06.08.2023 269

Ochiq yopiqlik tamoyili Wikipedia

Ob'ektlar uzaytirish uchun ochiq va o'zgartirish uchun yopiq bo'lishi kerak.

"SOLID" tamoyillarining ikkinchisi. Ushbu tamoyil ob'ektlar (sinflar, modullar, funktsiyalar va boshqalar bo'lishi mumkin) o'zlarining xatti-harakatlarini kengaytirish imkoniyatiga ega bo'lishlari kerakligini, lekin ularning mavjud xatti-harakatlarini o'zgartirib bo'lmasligini bildiradi.

Gipotetik misol sifatida Markdown hujjatini HTMLga aylantira oladigan modulni tasavvur qiling. Endi tasavvur qiling-a, Markdown spetsifikatsiyasiga matematik tenglamalarni qo'llab-quvvatlaydigan yangi sintaksis qo'shildi. Yangi matematik sintaksisni amalga oshirish uchun modul kengaytmalarga ochiq bo'lishi kerak. Biroq, mavjud sintaksis ilovalari (masalan, paragraflar, o'qlar va boshqalar) o'zgartirish uchun yopilishi kerak. Ular allaqachon ishlaydi, biz odamlar ularni o'zgartirishini xohlamaymiz.

Ushbu printsip ob'ektga yo'naltirilgan dasturlash uchun alohida ahamiyatga ega, bunda biz osongina kengaytiriladigan ob'ektlarni loyihalashimiz mumkin, lekin ularning mavjud xatti-harakatlari kutilmagan tarzda o'zgarishi mumkin bo'lgan ob'ektlarni loyihalashdan qochamiz.

Shuningdek qarang:

The Open/Closed Principle
Prinsiplar +2 06.08.2023 269

The Open/Closed Principle on Wikipedia

Entities should be open for extension and closed for modification.

The second of the 'SOLID' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour extended, but that their existing behaviour should not be able to be modified.

As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. Now imagine there is a new syntax added to the Markdown specification, which adds support for mathematical equations. The module should be open to extension to implement the new mathematics syntax. However, existing syntax implementations (like paragraphs, bullets, etc) should be closed for modification. They already work, we don't want people to change them.

This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways.

See also: