Tworząc programy często ma się wrażenie robienia ponownie tego samego. Wymyślono wiele narzędzi i technik pozwalających ponownie wykorzystywać zamiast ponownie tworzyć fragmenty programów (procedury, moduły, biblioteki). Jednak ten sam problem dotyczy nie tylko kodowania, lecz także projektowania. Do takiego wniosku na początku lat 90-tych doszło 4 panów: Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides. Wyniki swoich przemysleń opublikowali w 1995-tym roku w książce "Wzorce projektowe", która stała się jedną z najpopularniejszych i najczęściej wznawianych książek informatycznych. Na jej podstawie powstało wiele książek "Wzorce projektowe w *", dla praktycznie wszystkich popularnych języków obiektowych (Smalltalk, Java, ....).
Literatura:
Chyba najważniejszą zaletą Javy jest jest niemal pełna przenaszalność. Osiągnięto ją dzięki drobiazgowej specyfikacji wszystkich elementów języka oraz dzięki zastosowaniu (znanego oczywiście już znacznie wcześniej) pojęcia maszyny wirtualnej (VM). Każde środowisko chcące wykonywac programy w Javie musi dostarczyć własną maszynę wirtualną, zgodną oczywiście z opublikowaną specyfikacją. Budowa takiej maszyny jest ciekawym zagadnieniem, zwłaszcza ze względu na to, że VM powinna zapewnić efektywną realizację programów oraz wspierać wbudowaną w Javę wielowątkowość.
Literatura:
Programowanie obiektowe sprawdza się najlepiej tam, gdzie należy budować złożone systemy informatyczne. Nic dziwnego, że powstało wiele opartych o technologie obiektowe metodologii budowania systemów obiektowych (np. OMT, czy OOSE). Dość szybko zauważono, że poszczególne metodologie są do siebie dość podobne i że warto by było je ujednolicić. Odpowiedzią na to zapotrzebowanie było powstanie UMLa - zunifikowanego języka modelowania (obiektowego). Prace nad UMLem zaczęły się w roku 1994-tym, pierwsza wersja robocza powstała w roku 1995-tym, zaś standard UMLa został przyjęty w 1997-mym roku. UML pozwala modelować klasy, obiekty, związki pomiędzy nimi, interakcje z czasu wykonywania systemu a nawet samo wdrażanie systemu.
Literatura:
Nauczenie się programowania w C++ nie jest łatwe, potrzeba trochę czasu żeby zrozumieć jak działają metody wirtualne, obsługa wyjątków, destruktury czy szablony. Ale nagrodą za włożony wysiłek jest nie tylko możność pisania obiektowo programów o efektywności zbliżonej do języka C, lecz także możność stosowania (ze zrozumieniem) tak wyrafinowanych narzędzi programistycznych jak biblioteka STL (Standard Template Library). Włączona do standardowej biblioteki C++, biblioteka STL pozwala m.in. na korzystanie z różnorodnych kolekcji, pozwala operaować na jeszcze wyższym poziomie abstrakcji stosując takie pojęcia jak iteratory czy obiekty funkcyjne. Warto choć z grubsza poznać zawartość STL.
Literatura:
Rotor to inna nazwa wersji 1.0 Microsoft Shared Source CLI (Common Language Infrastructure). Rotor dostarcza kod źródłowy istotnej części .NETu. Zawiera wiele narzędzi (kompilatory, debuggery assembler i deassembler) pozwalających eksperymentować z nowym środowiskiem dostarczonym przez Microsoft. Poznanie wewnętrznej budowy wirtualnej maszyny .NETu pozwala nie tylko efektywniej programować w tym środowisku, ale także jest samo w sobie ciekawym zagadnieniem.
Literatura:
Java w bardzo krótkim czasie zdobyła sobie wielką popularność. Co nie oznacza, że stosujący ją na codzień programiści poznali ten język do końca. Na seminarium postaramy się zgłębić rzadziej stosowane elementy Javy.
Literatura:
Literatura:
Nowy język firmy Microsoft jest bardzo podobny do Javy (fakt niezauważany jedynie w firmie z Redmont). Jest to język obiektowy, z silną kontrolą typów, polimorfizmem, dziedziczeniem, interfejsami itd., co czyni go ciekawym obiektem badań. Na przykład konstrukcja new pozwalająca przerwać łańcuch metod wirtualnych (choć potrzeba jej wprowadzenia wydaje się delikatnie mówiąc wątpliwa) powoduje ciekawe problemy semantyczne.
Literatura:
Szablony są niezwykle potężnym (a jednocześnie niezwykle prosto realizowanym) mechanizmem z C++. Dzięki nim można w C++ projektować ATD. Czemu zatem nie ma ich w Javie czy C#, co skazuje użytkowników tamtych (rzekomo bezpiecznych ze względu na typy) języków na stałe stosowanie rzutowań typów. Jakie są pomysły zaradzenia tym problemom?
Literatura:
Plasterkowanie (ang. slicing) polega na takim okrojeniu analizowanego programu, żeby w zadanym miejscu programu oryginalnego i okrojonego, zadane zmienne miały te same wartości. Podział na plasterki może ułatwić analizę programu, jego debuggowanie czy dokumentowanie. Choć jest to pomysł dotyczący wszystkich imperatywnych języków programowania, często był analizowany w kontekście języków obiektowych, które ze względu na swoją strukturę mogą lepiej poddawać się takiej analizie. W przypadku tego tematu chodziłoby o przeanalizowanie i przedstawienie współczesnych wyników w tej dziedzinie dotyczących programów obiektowych.
Literatura: