Значи вие сте софтуерен инженер? Научихте всичко за обектно-ориентираното програмиране и красотата му и колко удивително може да се използва повторно, но не ви предупредиха колко леснотоеда злоупотребява. Има подобни проблеми, с които се сблъскваме през цялото време и те винаги идват от категоризирането на неща, като например организиране на вашия картотечен шкаф с различни сметки или данъчни документи правите ли го по година или сметка или и двете? Или какво ще кажете за нормализирането на вашата sql база данни, можете лесно да преминете през 3-та нормализирана форма и в крайна сметка да съсипете производителността и вашата база данни бързо да се превърне вбъркотия.

Сега към истинския проблем тук, злоупотреба с обектно ориентирано програмиране, нещо, което приемаме за даденост, толкова много хора го унищожават. Трябва да направите крачка назад и да погледнете какво изграждате и да попитате дали това наистина ще се използва повторно? Ако е така, как мога да улесня повторната употреба? Ако не, тогава добавям лисложност в името на едно невероятно бъдеще? Всички инженери не успяват да зададат тези прости въпроси твърде често, но не всички инженери са научени да задават тези въпроси. Толкова много колежи и университети удрят обектно-ориентираното програмиране за първия клас до последно, че никога не им отнема и секунда да помислят доколко можете да използвате функционалното програмиране, за да направите обектно-ориентираното програмиране перфектно. В почти всички случаи обектно-ориентираното програмиране с привкус на функционално програмиране има смисъл. Имате основни блокове за многократна употреба, които след това взаимодействат с други блокове за многократна употреба, но може би тези блокове взаимодействат с нещо друго по функционален начин и само те ще извършват това функционално взаимодействие. Защо бихте извличали това в друг обект за многократна употреба? Е, образованието ви вероятно ви е научило на това и има смисъл да правите това за чист обектно-ориентиран дизайн, но когато се върнете и погледнете този код след 3 месеца, вместо да знаете какво прави функцията, защото тя е точно там вградена, трябва да потърсете този споделен клас и се молете някой друг да не го е докоснал. Което ни води до друга точка на злоупотреба с обектно-ориентирани дизайнерски модели. Ако абстрахирате нещо, другите ще се почувстват склонни да го използват, дори ако е само частично това, което искат, и тогава те често решават да добавят някои условни стъпки вътре в този обект за своите случаи на употреба. Също така, може би те са влюбени в обектно-ориентирания дизайн толкова, колкото и вие и го наследяват, без да го документират, а след това отивате и променяте нещо и разбивате напълно различна част от системата. Това се случва твърде често, защото хората не са перфектни и ние не можем да бъдем. Ние като група инженери трябва да направим крачка назад и да се научим да смесваме дизайнерски модели и ако не е ясно, да го документираме.

Например, инженерите обичат добрия пример, те също обичат да спорят, така че предполагам, че тези примери ще докарат някои до ярост. Най-често срещаният, който съм виждал, е опаковане на външни повиквания за конкретна система, ако правите външни повиквания през цялото време, да, опаковайте ги, ако опаковате обект, който сам по себе си вече е обвивка около изходящите повиквания, тогава вероятно го правите погрешно . Имате клас, който трябва да получи url от API на вашия вътрешен dns сървър, можете да напишете клас, който прилага мрежови функции и регистратор и куп съоръжения за взаимодействие с основната мрежова библиотека, която използвате, след което трябва да създадете обект от този клас във вашия друг клас и му предоставите информацията, необходима за извършване на повикване, след това изпълнете повикването и след това разберете как да получите резултатите от този обект. Или какво ще кажете за просто хвърляне на функция в този клас, която просто изпълнява това извикване и връща тялото на отговора, ако е 200 или грешка, ако не, без предаване на метаданни или инстанциране на обект, просто извикайте функция и получете разумен отговор. Това все още може да бъде разширено по прости начини, за да може да се използва многократно в класа, просто добавете един вход за параметъра на заявката, който се променя. Сега имате функция, която прави това, което искате, без да се притеснявате някой друг да я използва за непредвидени цели, тя също така се самодокументира и е вътрешна за класа. Има дори средно положение, за което много от нас забравят, функция, която обгръща създаването и извикването на обекта и съответните функции, така че все още извикваме 1 метод, за да върнем точния резултат, който очакваме.

Кодът по-горе все още може да се използва многократно в смисъл, че инженер във вашата организация може да го види и след това да разбере как да направи външно повикване за одобрение или как да използва основната библиотека, така че да може да внедри своя собствена или ако внедрява същото нещо, тогава те биха могли да избухнат в собствения си клас и в този момент за него става най-добре да живее в собствения си обект. Но отново се надяваме, че сте направили тази функция за конкретна цел, която вашият клас изпълняваше, което означава, че е малко вероятно да бъде използвана от друг клас, тъй като не трябва да имате множество класове, изпълняващи едни и същи цели.

В обобщение, не създавайте клас, докато не разберете, че ще бъде използван повторно, докато не живеете със смесица от функционални и обектно-ориентирани дизайни в едно и също приложение. Това е добре и напълно приемливо, всъщност според мен е за предпочитане, в точката, в която ще използвате повторно кода, направете клас. Просто задайте 3 въпроса:

  • Това ще се използва ли повторно извън този клас?
  • Мога ли да улесня повторната употреба?
  • Добавям лисложност в името на възможна бъдеща употреба?

Тази статия напълно загърбва факта, че повечето от това може да бъде облекчено по време на етапа на диаграмиране на приложението и е по-насочена към приложения с бърза итерация.