Көп мақсатты ортада әңгімелесу

Біздің фирма негізінен Java-да дамиды және ортақ анықтамалық деректерге және нөмірленулерге тәуелді бірқатар «тірі» жүйелерді (негізінен, ұзақ жұмыс істейтін сервер процестерін) қолдайды. Кейде енім анықтамасы жаңа мәнді қамту үшін кеңейтіледі және бұл жағдайда, егер бұл біздің қосымшаларымыздың әрқайсысында барлық кітапханалық банкаларды қамтитын жеке «lib» қалтасына ие болса, бізде барлық қосымшаларды оның ішінде «enum entity» кітапханасы). Әлбетте, бұл жағымсыз нәрсе, сондықтан мен басқа адамдардың ұсыныстары мен тәсілдерін тыңдау қызықтырады.

Мен ойлаған ойлар:

  1. Ең соңғы «enum entity» кітапханалық нұсқасын алу үшін әрбір бағдарламаның бастапқы сценарийін өзгерту және jar файлын сынып жолына қосыңыз.
  2. Динамикалық сыныпқа арналған механизмнің кейбір түрі іске қосу уақытында жаңа кескін анықтамасын жүктейді.

Осы әдістермен проблема мынада, әдетте бағдарламаларда форматта код бар:

switch(enumVal) {
  case A:
   //Do something.
    break;
  case B:
   //Do something.
    break;
  default:
    throw new IllegalArgumentException("Invalid enum value: " + enumVal);
}

... және әдеттегі жағдайға тап болғанда сәтсіздікке ұшырайды. Мүмкін, бұл субъектілердің мүлдем болмауы керек деп ойлайды; бұл шын мәнінде біздің қолымыздағы ыңғайлы сауда. Немесе, бәлкім, біздің қосымшаларымыз өте сынғыш және әдетті әшекейді нәзікше өңдеуі мүмкін.

3
Менің ойымша, сіз өзіңіздің бағдарлама дизайнын қайта ойластыруыңыз керек. Есіңізде болсын: инкапсулировать не өзгереді.
қосылды автор Mister Smith, көзі
Enums - уақытты құрастыратын компиляция. Сондықтан қайта бастау жеткіліксіз. Егер сіз кез келген нәрсені өзгерткен болсаңыз, оларды қолданатын барлық сыныптарды қайтадан толтыруыңыз керек.
қосылды автор ssedano, көзі
@Udo Fholl: Java дұрыс емес, себебі Java (тек кешіктірмей) орындау уақытында және тек атымен байланыстырады. Егер тек жаңа элементтер кез-келген сынып файлына (көрінетін интерфейске) қосылса, қолданыстағы кодты қайта құрастыру қажет емес.
қосылды автор JimmyB, көзі
Enum анықтамасы кеңейтілсе, барлық бағдарламаларыңыз жаңа мәнді бірден пайдалана бастайды ма? Бұл амалдарды не үшін пайдаланасыз? Егер сіз жаңа мәнді enum-ға қоссаңыз, бірақ оны бағдарлама кодынан кез-келген жерде сілтемесеңіз, ол әлі де қолданба арқылы пайдаланылады (мысалы, valueOf() арқылы)?
қосылды автор socha23, көзі

2 жауаптар

Нысаналық бағдарлау осы мәселені шешу үшін арнайы ойлап тапты: сіздің коммутаторыңыз шын мәнінде айқын виртуалды үстел болғанда, ол өте жақсы еді. Сіз өзіңіздің қосымшаңызды интерфейстер/базалық класстардың орнына пайдалануды қайта қарауды қарастырыңыз.

Бұл проблеманы объектілерді құру уақытына жылжытады, бұл әрбір ену үшін бір өзгеріс нүктесінің дереу артықшылығын береді. Сондай-ақ, плагинге негізделген архитектураны енгізудің жолын ашады, ол ешқандай рекомпиляцияны қажет етпейді және тіпті оны қолданбаны қайта іске қоспай кеңейту мүмкіндігін тудыруы мүмкін. Ұзақ іске қосылған сервер процестері туралы сөйлескеніңізді ескере отырып, үзілістің төмендеуі шағымданады.

Коммутацияны болдырмаудың ең оңай жолы, Тәуелділік инъекциясын қабылдау керек болуы мүмкін. Көктемді сияқты шеңберлермен бірге бір немесе одан да көп конфигурация файлдарын жасаңыз, онда сіз жасайтын объектілерді көрсетіңіз, содан кейін оларды атаумен жүктей аласыз.

1
қосылды
Мен жауапты бірнеше қосымша ақпаратпен жаңартамын
қосылды автор Nicola Musatti, көзі
Ия, сынып файлын қалтаға немесе банкке қосуға болады, дегенмен, ол «ыстық» қосымшаларға жол бермейді. Мен конфигурацияны автоматты түрде жаңарту туралы мәліметтермен таныс емеспін, себебі мен мұны ешқашан қажет етпеймін.
қосылды автор Nicola Musatti, көзі
Ол қызықты. Оған сәйкес дизайнның дизайны болғанын елестетіп көрейік. Бір күні жаңа талаптар енгізіледі және жаңа сынып (кем дегенде) қосылуы керек. Жүйеге рекомбинациясыз қандай баламалар қою керек?
қосылды автор Mister Smith, көзі
Жақсы, кодталған фабриканың орнына қазір бізде xml бар. Дегенмен, қайтадан жаңа сыныпты ДИ құрылымы үшін жүйеде енгізу керек, солай емес пе? Қайталауды қалайсыз? Кейбір қалтаға сынып файлын қосу керек пе? Және тағы бір мәселе: DI құрылымы xml өзгергенін анықтайды ма немесе қайта іске қосу керек пе?
қосылды автор Mister Smith, көзі

Мистер Смит дұрыс: бұл мәселе бойынша кеңейтілу немесе ескі мектептегі «санақ» ішкі константасы екіталай жасалуы мүмкін және әдетте дұрыс көзқарас емес. Сіз айтып кеткендей, жаңа есепке алу мәндері оларды пайдаланатын клиенттердің арнайы мінез-құлқын/өңдеуін қажет етеді. Есептеуді өзгерткеннен кейін, сіз де керек клиенттерді де өзгерте аласыз. Бұл шын мәнінде нашар және оны басқа жолмен қайта жасауға тырысыңыз.

1
қосылды
Ия, бірақ тіпті амумдарда да әдістер болуы мүмкін. Сіз бір деңгейлі мұра иерархиясымен ұштасқансыз, бірақ олар қалыпты класс сияқты мінез-құлыққа ие болады. Сіз сондай-ақ әрбір тұрақты әдістер үшін әр түрлі артықшылықтарға ие бола аласыз. Сондықтан, бұл қосқышты немесе if-else-ні кодтаудың орнына, әрбір enum/class әдісінде жасалатын нәрсені жылжытыңыз және оны клиенттің кодынан шақырыңыз.
қосылды автор Mister Smith, көзі
Тұрақтылар жиынтығы - «сыныптың» кіші сыныптары. Тұрақты контингент константасы үшін enum-да анықталған әдісті елемеу үшін нақты тұрақты сыныпты болуы мүмкін. Мен таза дизайн деп атайтын нәрсе емес, бірақ ол жұмыс істейді.
қосылды автор Mister Smith, көзі
Мен қайтадан келісемін және қосуға болады: Егер барлық клиенттері үшін бірдей болса, арнайы iс-қимыл/өңдеу мүмкін бір орында, , бірінші кезекте клиенттерге емес енгізілуі керек.
қосылды автор JimmyB, көзі
Охумиялар мен мұраттарға қолдау көрсетпейді, демек, полиморфизм жоқ.
қосылды автор JimmyB, көзі
Дұрыс, бірақ клиенттер мінез-құлқын өзгерту үшін берілген enum түрінің өздерінің іске асыруларын ала алмайды.
қосылды автор JimmyB, көзі