Алтернативи на суфикса на име на клас -Info

Четох Чист код от Робърт К. Мартин и попаднах на скандалното изявление:

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

Така че, естествено, се опитах да отделя -Info от едно от имената на моите класове. Виждал съм всякакви въпроси на StackOverflow, питащи какво да направя в случай на -Manager или -Processor. Виждал съм коментари, в които се предполага, че не могат да измислят време, когато -Data би било добро име на клас. Е, според мен -Data и -Info изглеждат по-трудни за разпределяне. Особено, например в класа по-долу.

Имам клас Server като следния:

public class Server {
    //What I would call ServerInfo
    private int id;
    private String name;
    private String address;
    private int port;
    private int connections;
    private int maxConnections;
    private int status;

    //Bunch of members that aren't ServerInfo, for example:
    private ConcurrentHashMap<String, File> files = new ConcurrentHashMap<String, File>();
    private List<String> filePaths = new List<String>();
    /* ... */

    public void start() { /* ... */ }
    public void stop()  { /* ... */ }
}

На друг отдалечен сървър има HashMap съхранена информация на този сървър като следното:

public class ServerMap {
    ConcurrentHashMap<Integer, Server> serverMap = /* ... */;
}

Но този HashMap трябва да знае само това, което казах ServerInfo по-горе. Не е нужно да губи памет чрез съхраняване на куп променливи, които никога няма да използва. И така, клас данни е необходим за съхраняване на тези променливи.

public class ServerInfo {
    private int id;
    private String name;
    private String address;
    private int port;
    private int connections;
    private int maxConnections;
    private int status;
}

И ServerMap сега става ConcurrentHashMap<Integer, ServerInfo>.

Проблемът е, че това очевидно нарушава правилото от Чист код. Бих могъл да променя -Info с някакъв синоним, но тогава не е ли това наистина да реши проблема? Например, бих могъл да го нарека ServerDetails, но не виждам как това е различно от ServerData или ServerInfo.

Бих могъл да предефинирам Server в различно пространство от имена и да му дам само тези членове, но това изглежда още по-объркващо.

Какво е най-доброто практическо решение за това?


person crush    schedule 30.07.2013    source източник
comment
Ако групата от членове, които не са ServerInfo, не са непременно използвани, тогава защо ги поставяте в Server? Можете ли да дадете повече примери за тях?   -  person Genzer    schedule 30.07.2013
comment
@Genzer Те се използват от Server. Те не се използват от картата, която съдържа информация за всяко Server. Само променливите в ServerInfo трябва да бъдат известни/съхранени от ServerMap.   -  person crush    schedule 30.07.2013


Отговори (2)


Мисля, че смисълът на изявлението е да се избягва използването на такива претоварени термини като -Data и -Info, когато става въпрос за именуване на класове. Не мисля, че е неподходящо да използвате нещо като ServerDetails за обекта, който наименувате. В края на краищата, това са те, нали?

Ако ServerDetails е твърде общ, запитайте се какъв вид информация/подробности са... В този случай всички изглеждат свързани с мрежа или връзка. Какво ще кажете за ServerConnectionProperties или нещо подобно?

Използвайте насоките, които авторът излага точно като това; насоки. Само имайте предвид, че има много хора с тонове мнения и много малко от тях се прилагат 100% от времето. Ще полудеете, опитвайки се да приложите всяка „най-добра практика“ към писмото.

person Nizzo    schedule 30.07.2013
comment
Това ми се струва много разумно. Авторът го заяви с такава абсолютност, че почувствах, че това е някакво правило, което трябва да се следва 100% от времето - сякаш имаше някакъв присъщ дефект в дизайна на моя код, тъй като не можах да намеря начин да го следвам. - person crush; 30.07.2013
comment
Не мога да те обвинявам. Всеки път, когато се захвана с нещо ново, винаги ровя за насоките за „най-добри практики“, които да ме държат на пътя и това води до много блъскане на главата. Опитвам се да направя проучване, да избера път и да тръгна от там. Въпреки че трябва да призная, че понякога се спускам в заешката дупка. - person Nizzo; 30.07.2013
comment

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

var canvas = document.getElementById(<canvas element id>)// get canvas element
var dataURL = canvas.toDataURL("image/png");// convert to img, specify extension
document.getElementById(<new image id>).src = dataURL; // write as an image

Във втория ред посочих png. там можете да промените разширението на изображението. Дано помогне

- person crush; 30.07.2013
comment
Ако това е, което улавя, те ми звучат добре. - person Nizzo; 30.07.2013

Мисля, че гледате на рефакторинга по грешен начин. Те коригират името (по мое мнение) за ServerInfo ще бъде Server, защото това всъщност е сървърът. Когато имаме работа с ООП, "базовият" обект е обектът с данните. Например, не бихме нарекли клас с потребителско име, имейл и парола UserInfo или UserData, защото данните се подразбират от факта, че това е клас с членове. Очевидно има някои изключения от това правило. Обичайна практика е да има ProfileData обект, който да съдържа определена по-малко важна информация за потребителите.

Има два начина, по които мога да се сетя как аз лично бих преразгледал този проблем със сървъра. Единият е, че бих преименувал базата (serverInfo) на Server и обекта от по-високо ниво на нещо друго като ServerCommands (трудно ми е да намеря подходящо име, защото не знам какво прави класът)

Следващото ми предложение се основава на идеята за „генерализация“. Най-голямата причина, поради която не искаме да наименуваме класове по този начин, е, че обобщава подразбиращите се аспекти на програмирането. Почти всички класове обикновено имат свързани "информация" и "данни". Каква е тази информация или данни? Бих искал да цитирам от темата SO, обсъждаща рефакторите "помощник" и "мениджър".

Причина: Име на клас като "ThreadHelper" кара хората да се чудят защо е необходимо и защо не може просто да бъде част от класа "Thread". Всъщност адаптер ли е или декоратор? Ако е така, наречете го така. Дали класът "Нишка" вече поема твърде много отговорност? Ако е така, преработете и дайте на новия клас смислено име. „Помощник“ не казва нищо за това какво прави или как помага.

Всичко зависи от действителното предназначение на класовете. Ако видя клас, наречен serverInfo, може или може да не разбера каква е информацията. Аз лично бих го кръстил ServerProperties. Може да звучи като синоним на информация, но всъщност е по-конкретно. Когато мислим за имоти, мислим за „еднократно настроени“ детайли, които не се променят. (или ако се променят, това е защото ние променяме настройките). Можете също да го наречете ServerSettings, но аз лично харесвам имотите повече.

person Nick Humrich    schedule 30.07.2013
comment
Те обаче не са еднократни детайли за настройка, които не се променят. Например, connections ще се промени, когато влизат повече връзки. Едно свойство, което изключих (по случайност), беше status, което ще каже дали сървърът е онлайн, офлайн, заключен, зарежда се и т.н. Това също ще се промени. Тази информация е само малка част от цялостния Server обект и само тази информация трябва да се съхранява в ServerMap, вместо да се съхранява целият Server обект. Settings и Propeties предават контекст, различен от това, което би било намерението. Може би сега можете да предложите други? - person crush; 30.07.2013
comment
Докато разглеждам тези подробности, това, което бих направил в тази ситуация (сега, когато виждам повече подробности), е да направя serverInfo нещо като BasicServer и след това класа на сървъра нещо като ServerWithFiles или FileServer или подобни неща. (или нещо, което отразява допълнителните данни, които съдържа) Можете дори да направите FileServer extend BasicServer, така че по-късно да можете да създадете различен сървърен клас с различни разширени членове - person Nick Humrich; 30.07.2013
comment
И след това да съхранявате екземпляри на BasicServer в ServerMap? ServerMap живее в различна кутия, така че екземплярите на BasicServer, които биха били активни там, няма да имат препратки към екземпляра, който живее другаде. Ето защо е важно този клас, който се съдържа в ServerMap, да съдържа само уместните данни, които са необходими. Вече клоня към това да го кръстя ServerState. Благодаря за отговора! - person crush; 30.07.2013