Bir qayda olaraq, antipatternlər aşağıdakı növlərə bölünür:
- Memarlıq antipatternləri - sistemin strukturunun layihələndirilməsi zamanı yaranan memarlıq antipatternləri (adətən memar tərəfindən).
- İdarəetmə Anti Pattern - adətən müxtəlif menecerlər (və ya menecerlər qrupları) tərəfindən rast gəlinən idarəetmə sahəsində antipatternlər.
- İnkişaf Anti Pattern - antipatternlər adi proqramçılar bir sistem yazarkən yaranan inkişaf problemləridir.
1. Analitik iflic
Analiz iflici klassik təşkilati anti-naxış hesab olunur. Bu, planlaşdırma zamanı vəziyyəti həddindən artıq təhlil etməyi əhatə edir ki, heç bir qərar və ya tədbir görülməsin, mahiyyətcə inkişafı iflic etsin. Bu, çox vaxt məqsəd mükəmməlliyə nail olmaq və təhlil dövrünün tam başa çatması olduqda baş verir. Bu anti-naxış dairələrdə gəzmək (bir növ qapalı döngə), təfərrüatlı modelləri nəzərdən keçirmək və yaratmaqla xarakterizə olunur ki, bu da öz növbəsində iş axınına mane olur. Məsələn, siz belə şeyləri proqnozlaşdırmağa çalışırsınız: əgər istifadəçi birdən öz adının dördüncü və beşinci hərfləri əsasında işçilərin siyahısını yaratmaq istəsə, o cümlədən Yeni il ilə ən çox iş vaxtını ayırdığı layihələr əvvəlki dörd ildə səkkizinci mart? Əslində, bu, təhlilin həddindən artıq çoxluğudur. Yaxşı real həyat nümunəsi analiz iflicinin Kodak-ı necə iflasa aparmasıdır . Analiz iflici ilə mübarizə aparmaq üçün bir neçə sürətli ipucu:- Uzunmüddətli hədəfi qərar qəbul etmək üçün mayak kimi müəyyənləşdirməlisiniz ki, verdiyiniz hər bir qərar sizi hədəfinizə yaxınlaşdırsın və sizi vaxtı qeyd etməyə məcbur etməsin.
- Diqqətinizi xırda şeylərə cəmləməyin (niyə həyatınızdakı sonuncu nüans kimi kiçik bir nüansa qərar verin?)
- Qərar qəbul etmək üçün son tarix təyin edin.
- Bir işi mükəmməl yerinə yetirməyə çalışmayın: bunu çox yaxşı etmək daha yaxşıdır.
2.Allah etiraz edir
İlahi obyekt çoxlu sayda müxtəlif verilənləri (tətbiqin ətrafında fırlanan obyekt) saxlayaraq çoxlu müxtəlif funksiyaların həddindən artıq konsentrasiyasını təsvir edən anti-naxışdır. Kiçik bir misal götürək:public class SomeUserGodObject {
private static final String FIND_ALL_USERS_EN = "SELECT id, email, phone, first_name_en, access_counter, middle_name_en, last_name_en, created_date FROM users;
private static final String FIND_BY_ID = "SELECT id, email, phone, first_name_en, access_counter, middle_name_en, last_name_en, created_date FROM users WHERE id = ?";
private static final String FIND_ALL_CUSTOMERS = "SELECT id, u.email, u.phone, u.first_name_en, u.middle_name_en, u.last_name_en, u.created_date" +
" WHERE u.id IN (SELECT up.user_id FROM user_permissions up WHERE up.permission_id = ?)";
private static final String FIND_BY_EMAIL = "SELECT id, email, phone, first_name_en, access_counter, middle_name_en, last_name_en, created_dateFROM users WHERE email = ?";
private static final String LIMIT_OFFSET = " LIMIT ? OFFSET ?";
private static final String ORDER = " ORDER BY ISNULL(last_name_en), last_name_en, ISNULL(first_name_en), first_name_en, ISNULL(last_name_ru), " +
"last_name_ru, ISNULL(first_name_ru), first_name_ru";
private static final String CREATE_USER_EN = "INSERT INTO users(id, phone, email, first_name_en, middle_name_en, last_name_en, created_date) " +
"VALUES (?, ?, ?, ?, ?, ?, ?)";
private static final String FIND_ID_BY_LANG_CODE = "SELECT id FROM languages WHERE lang_code = ?";
........
private final JdbcTemplate jdbcTemplate;
private Map<String, String> firstName;
private Map<String, String> middleName;
private Map<String, String> lastName;
private List<Long> permission;
........
@Override
public List<User> findAllEnCustomers(Long permissionId) {
return jdbcTemplate.query( FIND_ALL_CUSTOMERS + ORDER, userRowMapper(), permissionId);
}
@Override
public List<User> findAllEn() {
return jdbcTemplate.query(FIND_ALL_USERS_EN + ORDER, userRowMapper());
}
@Override
public Optional<List<User>> findAllEnByEmail(String email) {
var query = FIND_ALL_USERS_EN + FIND_BY_EMAIL + ORDER;
return Optional.ofNullable(jdbcTemplate.query(query, userRowMapper(), email));
}
.............
private List<User> findAllWithoutPageEn(Long permissionId, Type type) {
switch (type) {
case USERS:
return findAllEnUsers(permissionId);
case CUSTOMERS:
return findAllEnCustomers(permissionId);
default:
return findAllEn();
}
}
..............…
private RowMapper<User> userRowMapperEn() {
return (rs, rowNum) ->
User.builder()
.id(rs.getLong("id"))
.email(rs.getString("email"))
.accessFailed(rs.getInt("access_counter"))
.createdDate(rs.getObject("created_date", LocalDateTime.class))
.firstName(rs.getString("first_name_en"))
.middleName(rs.getString("middle_name_en"))
.lastName(rs.getString("last_name_en"))
.phone(rs.getString("phone"))
.build();
}
}
findAllWithoutPageEnbiznes məntiqi ilə fasad metodunu görürük. Belə bir ilahi obyekt nəhəng olur və adekvat şəkildə dəstəklənməsi çətin olur. Biz hər bir kod parçasında bununla məşğul olmalıyıq: sistemdəki bir çox qovşaq ona güvənir və ona möhkəm bağlıdır. Belə kodu saxlamaq getdikcə çətinləşir. Belə hallarda onu ayrı-ayrı siniflərə bölmək lazımdır ki, onların hər biri yalnız bir məqsəd (məqsəd) olacaq. Bu nümunədə onu dao sinfinə ayıra bilərik:
public class UserDaoImpl {
private static final String FIND_ALL_USERS_EN = "SELECT id, email, phone, first_name_en, access_counter, middle_name_en, last_name_en, created_date FROM users;
private static final String FIND_BY_ID = "SELECT id, email, phone, first_name_en, access_counter, middle_name_en, last_name_en, created_date FROM users WHERE id = ?";
........
private final JdbcTemplate jdbcTemplate;
........
@Override
public List<User> findAllEnCustomers(Long permissionId) {
return jdbcTemplate.query(FIND_ALL_CUSTOMERS + ORDER, userRowMapper(), permissionId);
}
@Override
public List<User> findAllEn() {
return jdbcTemplate.query(FIND_ALL_USERS_EN + ORDER, userRowMapper());
}
........
}public class UserInfo {
private Map<String, String> firstName;
…..
public Map<String, String> getFirstName() {
return firstName;
}
public void setFirstName(Map<String, String> firstName) {
this.firstName = firstName;
}
....private List<User> findAllWithoutPageEn(Long permissionId, Type type) {
switch (type) {
case USERS:
return findAllEnUsers(permissionId);
case CUSTOMERS:
return findAllEnCustomers(permissionId);
default:
return findAllEn();
}
}3.Singleton
Singleton, tək yivli proqramda hansısa sinifin tək nümunəsinin olacağına zəmanət verən və həmin obyektə qlobal giriş nöqtəsini təmin edən ən sadə nümunədir. Bu barədə daha ətraflı burada oxuya bilərsiniz . Ancaq bu bir nümunədir, yoxsa antipattern?
Bu şablonun çatışmazlıqlarına baxaq:
-
Qlobal dövlət. Bir sinfin nümunəsinə daxil olduqda, biz həmin sinfin cari vəziyyətini və ya onu kimin və ya nə vaxt dəyişdirdiyini bilmirik və bu vəziyyət gözlədiyimiz kimi olmaya bilər. Başqa sözlə, singletonla işləməyin düzgünlüyü ona edilən çağırışların ardıcıllığından asılıdır ki, bu da alt sistemlərin bir-birindən asılı olmasına səbəb olur və nəticədə inkişafın mürəkkəbliyini ciddi şəkildə artırır.
-
Singleton SOLID prinsiplərindən birini - Vahid Məsuliyyət Prinsipini pozur - Singleton sinfi öz bilavasitə öhdəliklərini yerinə yetirməklə yanaşı, nümunələrinin sayına da nəzarət edir.
-
Normal sinfin singletondan asılılığı sinif interfeysində görünmür. Bir qayda olaraq, bir singleton nümunəsi metodun parametrlərində ötürülmür, lakin birbaşa vasitəsilə əldə edilir,
getInstance()bir sinfin singletondan asılılığını müəyyən etmək üçün, hər bir metodun həyata keçirilməsini araşdırmaq lazımdır - sadəcə olaraq ictimaiyyətə baxmaq obyektin müqaviləsi kifayət deyil.Singiltonun mövcudluğu ümumiyyətlə tətbiqin və xüsusilə singletondan istifadə edən siniflərin sınaqdan keçirilməsini azaldır. Birincisi, Singleton yerinə Sınaq obyekti qoya bilməzsiniz, ikincisi, əgər singletonun vəziyyətini dəyişdirmək üçün interfeysi varsa, testlər bir-birindən asılı olacaq.
Başqa sözlə, singleton əlaqəni artırır və yuxarıda göstərilənlərin hamısı artan əlaqənin nəticəsidir.
Və bu barədə düşünsəniz, singletonun istifadəsindən qaçınmaq olar. Məsələn, bir obyektin nümunələrinin sayını idarə etmək üçün müxtəlif növ fabriklərdən istifadə etmək olduqca mümkündür (və zəruridir).
Ən böyük təhlükə, bütün tətbiq arxitekturasını singletonlar əsasında qurmaq cəhdindədir. Bu yanaşmanın bir çox əla alternativləri var. Ən vacib nümunə Bahardır, yəni onun IoC konteynerləri: orada xidmətlərin yaradılmasına nəzarət problemi təbii şəkildə həll olunur, çünki onlar əslində "steroidlər üzrə zavodlardır".
İndi bu mövzuda çoxlu holivar var, buna görə də təktonun naxış və ya antipattern olub-olmamasına qərar vermək sizin ixtiyarınızdadır.
Və biz bunun üzərində dayanmayacağıq və bu gün üçün son dizayn nümunəsinə keçməyəcəyik - poltergeist.
4. Poltergeist
Poltergeist başqa sinfin metodlarını çağırmaq üçün istifadə olunan və ya sadəcə olaraq lazımsız abstraksiya qatını əlavə edən qeyri-faydalı sinif antipatterndir. Antipattern dövlətdən məhrum olan qısamüddətli obyektlər şəklində özünü göstərir. Bu obyektlər tez-tez digər, daha davamlı obyektləri işə salmaq üçün istifadə olunur.public class UserManager {
private UserService service;
public UserManager(UserService userService) {
service = userService;
}
User createUser(User user) {
return service.create(user);
}
Long findAllUsers(){
return service.findAll().size();
}
String findEmailById(Long id) {
return service.findById(id).getEmail();}
User findUserByEmail(String email) {
return service.findByEmail(email);
}
User deleteUserById(Long id) {
return service.delete(id);
}
}5. Sərt kod
Beləliklə, biz bu dəhşətli sözə gəldik - hardcode. Bu antipatternin mahiyyəti kodun xüsusi aparat konfiqurasiyasına və/və ya sistem mühitinə güclü şəkildə bağlı olmasıdır ki, bu da onu digər konfiqurasiyalara köçürməyi çox çətinləşdirir. Bu antipattern sehrli nömrələrlə sıx bağlıdır (onlar tez-tez bir-birinə bağlıdır). Misal:public Connection buildConnection() throws Exception {
Class.forName("com.mysql.cj.jdbc.Driver");
connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/someDb?characterEncoding=UTF-8&characterSetResults=UTF-8&serverTimezone=UTC", "user01", "12345qwert");
return connection;
}spring:
datasource:
jdbc-url:jdbc:mysql://localhost:3306/someDb?characterEncoding=UTF-8
driver-class-name: com.mysql.cj.jdbc.Driver
username: user01
password: 12345qwert6. Qayıq lövbəri
Antipatternlər kontekstində bir qayıq lövbəri, müəyyən optimallaşdırma və ya refaktorinqdən sonra qalan sistemin istifadə olunmamış hissələrini saxlamaq deməkdir. Həmçinin, kodun bəzi hissələri yenidən istifadə etməli olduğunuz halda “gələcək üçün” qala bilər. Bu, əslində kodu zibil qutusuna çevirir.
Misal:
public User update(Long id, User request) {
User user = mergeUser(findById(id), request);
return userDAO.update(user);
}
private User mergeUser(User findUser, User requestUser) {
return new User(
findUser.getId(),
requestUser.getEmail() != null ? requestUser.getEmail() : findUser.getEmail(),
requestUser.getFirstName() != null ? requestUser.getFirstName() : findUser.getFirstNameRu(),
requestUser.getMiddleName() != null ? requestUser.getMiddleName() : findUser.getMiddleNameRu(),
requestUser.getLastName() != null ? requestUser.getLastName() : findUser.getLastNameEn(),
requestUser.getPhone() != null ? requestUser.getPhone() : findUser.getPhone());
}public User update(Long id, User request) {
return userDAO.update(user);
}mergeUserartıq istifadə edilmir və onu silmək təəssüf doğurur: əgər o (və ya onun ideyası) hələ də faydalıdırsa? Bu cür kod yalnız sistemləri çətinləşdirir və çaşdırır, mahiyyətcə heç bir praktiki dəyər vermir. Unutmamalıyıq ki, "ölü parçalar" olan belə kodu başqa bir layihəyə getdiyiniz zaman bir həmkarınıza köçürmək çətin olacaq. Qayıq lövbərləri ilə məşğul olmağın ən yaxşı üsulu kodun refaktorinqidir, yəni kodun bu bölmələrini silməkdir (təəssüf ki,). Həmçinin, inkişafı planlaşdırarkən, bu cür lövbərlərin meydana gəlməsini nəzərə almalısınız (tullantıları təmizləmək üçün vaxt verin).
7.Obyekt tullantıları
Bu antipatterni təsvir etmək üçün əvvəlcə obyekt hovuz nümunəsi ilə tanış olmalısınız . Obyekt hovuzu (resurs hovuzu) generativ dizayn nümunəsidir , işə salınmış və istifadəyə hazır olan obyektlər dəstidir. Tətbiq obyekt tələb etdikdə, o, yenidən yaradılmır, lakin bu hovuzdan götürülür. Bir obyektə ehtiyac qalmadıqda, o, məhv edilmir, lakin hovuza qaytarılır. Adətən verilənlər bazası bağlantısı kimi hər dəfə yaratmaq üçün resurs tələb edən ağır obyektlər üçün istifadə olunur. Nümunə üçün kiçik və sadə bir nümunəyə baxaq. Beləliklə, bu nümunəni təmsil edən bir sinifimiz var:class ReusablePool {
private static ReusablePool pool;
private List<Resource> list = new LinkedList<>();
private ReusablePool() {
for (int i = 0; i < 3; i++)
list.add(new Resource());
}
public static ReusablePool getInstance() {
if (pool == null) {
pool = new ReusablePool();
}
return pool;
}
public Resource acquireResource() {
if (list.size() == 0) {
return new Resource();
} else {
Resource r = list.get(0);
list.remove(r);
return r;
}
}
public void releaseResource(Resource r) {
list.add(r);
}
}Resource, konstruktorda standart olaraq hovuz 4 nüsxə ilə doldurulur; belə bir obyekt götürüldükdə hovuzdan çıxarılır (əgər orada deyilsə, yaradılır və dərhal verilir), sonda isə obyekti geri qoymaq üsulu var. Obyektlər Resourcebelə görünür:
public class Resource {
private Map<String, String> patterns;
public Resource() {
patterns = new HashMap<>();
patterns.put("заместитель", "https://studfile.net/preview/3676297/page:3/");
patterns.put("мост", "https://studfile.net/preview/3676297/page:4/");
patterns.put("фасад", "https://studfile.net/preview/3676297/page:5/");
patterns.put("строитель", "https://studfile.net/preview/3676297/page:6/#16");
}
public Map<String, String> getPatterns() {
return patterns;
}
public void setPatterns(Map<String, String> patterns) {
this.patterns = patterns;
}
}main:
class SomeMain {
public static void main(String[] args) {
ReusablePool pool = ReusablePool.getInstance();
Resource firstResource = pool.acquireResource();
Map<String, String> firstPatterns = firstResource.getPatterns();
// ......Howим-то образом используем нашу мапу.....
pool.releaseResource(firstResource);
Resource secondResource = pool.acquireResource();
Map<String, String> secondPatterns = firstResource.getPatterns();
// ......Howим-то образом используем нашу мапу.....
pool.releaseResource(secondResource);
Resource thirdResource = pool.acquireResource();
Map<String, String> thirdPatterns = firstResource.getPatterns();
// ......Howим-то образом используем нашу мапу.....
pool.releaseResource(thirdResource);
}
}main:
Resource fourthResource = pool.acquireResource();
Map<String, String> fourthPatterns = firstResource.getPatterns();
// ......Howим-то образом используем нашу мапу.....
fourthPatterns.clear();
firstPatterns.put("first","blablabla");
firstPatterns.put("second","blablabla");
firstPatterns.put("third","blablabla");
firstPatterns.put("fourth","blablabla");
pool.releaseResource(fourthResource);public Resource() {
patterns = new HashMap<>();
patterns.put("заместитель", "https://studfile.net/preview/3676297/page:3/");
patterns.put("мост", "https://studfile.net/preview/3676297/page:4/");
patterns.put("фасад", "https://studfile.net/preview/3676297/page:5/");
patterns.put("строитель", "https://studfile.net/preview/3676297/page:6/#16");
patterns = Collections.unmodifiableMap(patterns);
}
Bununla da məqalənin birinci hissəsi başa çatdı: davam etdiriləcək .
GO TO FULL VERSION