Kakvo znachi Java

Да бе.. да им имам новите представи. Ех, че ми дойде вдъхновението (гнусливи да не четат!!!):

void shitting(Person subject, boolean diluted)

{

  // Getting WC object

  WC localWC = WC.getInstance();



  // Prepare the process

  // sending strip message

  subject.getPants().unzip();

  subject.getPants().undress(PANTS_TAKEOFF);

  subject.sit(true);



  // Doing the main work... 

  Ass myAss = subject.getAss();

  myAss.enableFarting();

  int count = 0;

  while(myAss.inNeed())

   {

      localWC.push(myAss.createShit(diluted));

      

      if (++count > SHIT_COUNTER || localWC.smellsNotGood())

      {

         localWC.flush();

         count = 0;

      }

   }

   myAss.disableFarting();



   // Request a object that implement the Paper interface

   ToiletPaper paper = localWC.getToiletPaper();

    if (paper == null)

    {

       // No paper found, send message 'new' to the Cabinet

       try

       { 

          paper = new ToiletPaper(localWC.getCabinet());

       }

       catch(NoCabinetException ex)

       {

          System.out.println("Oooops...");

           // Doing downcasting. NOT SAFE!!!

           paper = (ToiletPaper)myNewspaper;

       }

    }



    myAss.deinit(paper);



    // Deinit and exit..

    subject.standUp();

    subject.getPants().dress();

    subject.getPants().zip();



}

Тцтц, кви работи може да измисли човек докато е в кенефа, а?

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

Хе хе, туй си е типичен жабарски код.

А нас ц пляс пляс програмистите ни учат че downcast е кофти дизайн - (ToiletPaper)myNewspaper. Виж, ако правилно моделираш предметната област и наследиш вестника от тоалетната хартия няма да имаш такива фундаментални проблеми.

Обаче по големия проблем е, че кода не е exception safe - като ти възникне някое изключение по средата на процеса ще си останеш с изути гащи , а това май не е по спецификация. Някой ще кажат, че ако имаше юнит тестове, туй няма как да се случи. Само дето прилагането на TDD в случая може да доведе до по-неприятна ситуация като изпускане на крайния срок например. А това си е доста extreme, но не programming.

Да, май е време за тоалетната...

ааа никви изключения. Exceptions се ловят там където се хвърлят, пише си в лога и работата продължава. Няма да спираме за глупости я.

Признавам само изключения от вида:

HardwareNotFoundException, BlackoutException и пр.

Допуска се да бъдат наследени съответно от CPUNotFoundException, MemoryNotFoundException и PowerStationExplodedException...

Останалото не са изключения, а проблемни състояния на системата.

Мечтата е мисъл, мисълта е идея, всяка идея се реализира. Аз не мечтая, а реализирам идеите си.

Какъв хардуер, какво CPU, нали сме на виртуална машина.

А най трудно ми е да се справям с NullPointerExeception. Всички само ми се хвалят, че жабата нямала указатели и всичко било като песен. Та какви са тия поинтери, пък и нулеви, а на всичкото отгоре и ексепшъни. Онзи GC, дето му викат, да си ги събира там, да ми се махат от главата.

В отговор на:

---

Само дето прилагането на TDD в случая може да доведе до по-неприятна ситуация като изпускане на крайния срок например.

---

Опитвал ли си TDD та говориш за изпускане на крайния срок? Аз съм виждал проекти дето накрая бъговете валят като пърхут и освен изпускането на крайния срок се пуска и дефектен продукт. За мен неприлагането на TDD може да доведе до изпускане на срока.

Сега ме е яд, че като говорих за обектно мислене изобщо, ама изобщо не мислех за полуобектни езици като джава, дето им е отрязан единия крак и им е дадена патерица. Да стискаме палци Groovy да стане по-популярен, че да има един нормален динамичен език с closures за JVM-то.

--
Екстремно програмиране на български.
[линк]

Е, не го приемай толкоз лично, тази нишка беше просто малко майтап, без лоши чувства към екстремистите

Ако говорим сериозно, от юнит тестовете определено има полза и то не само (а може би и не толкова) за откриването на грешки. Определено оказват положително влияние върху дизайна (човек се замисля доста повече за свързаността и сцеплението на класовете и модулите - обратната реакция е: не пишем тестове защото това тук .... не може да се тества; защо не може?; ами не може, щото е такова). Ако са написани добре могат да играят и ролята на допълнителна _компилируема_ документация (но не съм съгласен с хората, твърдящи, че това може да е единствената документация). И естествено по-спокойното рефакториране.

Та това е от моя опит, дано сега да си по-доволен и спиш спокойно

А, и да не забравя, виждал съм и много лоши тестове, ама то е сигурно щото колегите още не са прочели книжката за TDD-то. Хем бъговете си седяха, хем сроковете се пропускаха, хем се отчиташе, че има не знам колко си автоматични тестове. Ама това си е за друга тема.

За жабата и патерицата няма да коментирам, все пак съм от сектата на Ц пляс плясаджиите.