O klasie Convert

2009-06-17 18:49

Stawiając pierwsze kroki w programowaniu w C#/.NET, można odkryć kilka ciekawych właściwości, które nie zawsze występują w innych językach. Jednym z nich jest całkiem dobre rozwiązanie odwiecznego problemu w kodowaniu, czyli zamiany między różnymi typami danych: zwłaszcza do i z łańcucha znaków.
Przykładem jest chociażby metoda ToString, która zrobi nam napis z dowolnego obiektu. Są też metody w stylu int.Parse, które potrafią odczytać liczbę zapisaną jako tekst i w zgrabny sposób rozwiązują jeden z najpowszechniejszych kłopotów wszystkich początkujących programistów :) (O ile oczywiście pomyślą oni o tym, że typ bądź co bądź, podstawowy, może mieć metody tak, jak klasa). W końcu, jest też rzutowanie; może ono służyć do “przywrócenia” właściwego typu obiektu, o którym z jakichś powodów “zapomnieliśmy”, ale również do konwersji między typami podstawowymi.

W sumie więc mechanizmów tego rodzaju jest dość dużo. Co więcej, nietrudno też – zwłaszcza w rzeczywistych, a nie przykładowych kodach – natrafić na jeszcze jeden. Jest to mianowicie użycie statycznej klasy Convert, zawierającej kilka metod typu ToDouble lub ToBoolean. I wydaje się, że korzystanie właśnie z niej najbardziej się opłaca. Dlaczego?
Ano głównie ze względu na jej uniwersalność – można z niej korzystać właściwie do wszystkich konwersji wyliczonych wyżej, i nie tylko. Daje to kod czytelniejszy, w którym od razu widać, co chcieliśmy zrobić – zwłaszcza jeśli alternatywą jest pokrętne obejście w rodzaju pośredniej konwersji do stringa. Ponadto klasa ta bywa sprytniejsza niż podane wcześniej sposoby, radząc sobie chociażby z typami danych używanymi przez API dostępu do baz danych (np. SqlInt32) i przerabiając je na bardziej użyteczne wartości.

W końcu, nie da się też ukryć, że korzystanie z mniej znanej, ale za to jakże wyspecjalizowanej klasy do prostych czynności jest niewątpliwą oznaką dużego profesjonalizmu… czyż nie? ;] I to pewnie jest najważniejszy argument ‘za’ ;P

Tags:
Author: Xion, posted under Programming »


17 comments for post “O klasie Convert”.
  1. polymorph:
    June 18th, 2009 o 3:15

    Heh, też mi się swego czasu spodobała ta klasa, do tego stopnia że sobie nawet napisałem nakładkę na boost::lexical_cast żeby mieć tak samo w c++

    1. #ifndef CONVERT_H
    2. #define CONVERT_H
    3.  
    4. #include <string>
    5. #include <boost/lexical_cast.hpp>
    6.  
    7. class __Convert
    8. {
    9.     private:
    10.         __Convert() {}
    11.         __Convert(const __Convert&amp;) {}
    12.         friend __Convert&amp; ConvertInstance();
    13.     public:
    14.  
    15.     template <typename T>
    16.     std::string ToString(const T t)
    17.     {
    18.         return boost::lexical_cast<std::string>(t);
    19.     }
    20.  
    21.     template <typename T>
    22.     uint16_t ToUInt16(const T t)
    23.     {
    24.         return boost::lexical_cast<uint16_t>(t);
    25.     }
    26.    
    27.     //itd...
    28. };
    29.  
    30. __Convert& ConvertInstance();
    31. static __Convert& Convert = ConvertInstance();
    32.  
    33. #endif // CONVERT_H
  2. nilphilus:
    June 18th, 2009 o 13:35

    Zdaje się że Java też coś takiego ma :-)
    Ale fakt, fajna sprawa :-)

  3. groshu:
    June 18th, 2009 o 22:33

    masz błąd w znacznikach w tym artykule i w reszcie strony idzie czcionka bloku code, bo w jednym miejscu masz “” zamiast “"

  4. groshu:
    June 18th, 2009 o 22:34

    </a> zamiast </code>

  5. SirMike:
    June 18th, 2009 o 22:38

    W calym Convert najbardziej podoba mi sie jednak mozliwosc automatycznej konwersji obiektow na proste typy danych dzieki interfejsowi IConvertible.

  6. Xion:
    June 19th, 2009 o 0:44

    groshu: Poprawione.

  7. polymorph:
    June 19th, 2009 o 1:34

    Tak sobie myślę, że jeżeli by połączyć c++ i c# to mieli byśmy przed sobą język idealny. No i może jeszcze dodać plastyczność ruby.

    Właściwie to jest dobry temat na dyskusję: Jak byście mogli stworzyć język idealny(i nie musieli byście poświęcać parunastu lat z życia na projektowanie, implementowanie, testowanie i tworzenie community) to jak by on wyglądał? Jakie cechy jakich języków byście wybrali?

  8. Aithne:
    June 19th, 2009 o 1:41

    Czytelność Perla, szybkość PHP, biblioteka standardowa z C, “wysokopoziomowość” i przenośność języka asemblera, poziom trudności brainfucka.

  9. Good advice uncle:
    June 19th, 2009 o 9:44

    Oczywiście że Java to ma.
    Jak dla mnie C#, a właściwie cały ‘dot net’ to materia w dużej mierze oparta na filozofii Javy, żeby nie powiedzieć że skopiowana od niej.

    Oczywiście C# oferuje wiele prostych i przydatnych rozwiązań, jednak sam fundament i szkielet znamy doskonale z Javy.

  10. sharp dude:
    June 19th, 2009 o 21:07

    Składniowo C# bardzo przypomina C++, Java zresztą też, więc trudno powiedzieć żeby pod tym względem twórcy C# zrzynali z Javy. A takie mechanizmy jak np. garbage collector istniały już w językach funkcyjnych.

  11. Aithne:
    June 20th, 2009 o 1:48

    99% tych wszystkich ficzerów C# czy Javy LISP miał bardzo dawno temu. Pozostałego 1% nie potrzebował.

  12. Xion:
    June 20th, 2009 o 2:32

    Jaka szkoda, że składnia LISP-a została opracowana przy pomocy rzucania kotem o klawiaturę… gdyby nie to, może jego udział w ilości powstałego oprogramowania przekroczyłby 0,00045%? ;]

    polymorph: Bardzo interesujące pytanie. Kto wie, może kiedyś ten temat podejmę :)

  13. moriturius:
    June 20th, 2009 o 7:39

    Noo widzę, że ja poszedłem w Javę, a Xion uciekł w C# ^^

    Też chetnie pobawiłbym się C# gdyby nie fakt, że w Linuxie dostępne jest tylko Mono i to działajace tak-se ;)

  14. Aithne:
    June 21st, 2009 o 2:03

    LISPa? A komuś się tu coś z Perlem nie pomyliło? Jakbyś pokodził w np. Common Lispie przez chwilę to byś widział, że jeżeli LISP jest nieczytelny to C++ to chyba Malbolge.

  15. polymorph:
    June 21st, 2009 o 4:56

    Aithne: Apropo tych 99% to natrafiłem niedawno na taki post o Smalltalk’u: Your Language Features Are My Libraries Szczególnie ten fragment: “but I cannot help but feel that this isn’t an issue of reinventing the wheel, as much as forgetting that we can provide programmers the tools to make their own types of locomotion.”, i chyba o to mi właśnie chodziło mówiąc o plastyczności ruby, że jeżeli czegoś ci będzie jednak brakować w “języku idealnym” to zawsze z łatwością możesz sobie to sam dopisać.

    A co do składni LISPa to ona wygląda tak jakby chcieli zrobić język w oparciu o odwrotną notacje polską, ale zapomnieli że cały sens ONP leży w pozbyciu się nawiasów ^^

  16. Xion:
    June 22nd, 2009 o 0:55

    Rzeczywiście, pomyliło mi się z Perlem. Charakterystyka składni LISP-a podana przez polymorpha jest o wiele lepsza :)

  17. Aithne:
    June 22nd, 2009 o 22:05

    Ale to nie zmienia faktu, że LISP jest na tyle funkcjonalny (w sensie paradygmatu, chociaż ten drugi też pasuje), że żaden imperatywny język wygodniejszy nie będzie :)

Comments are disabled.
 


© 2018 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.