Czy graficzne przedstawienie graficznego interfejsu użytkownika należy uznać za „oszustwo”?

Mam przyjaciela, który ma trochę większe doświadczenie w programowaniu. Rozmawialiśmy o różnych technologiach programowania, których używamy, i Konstruktor interfejsów pojawił się w rozmowie.

Ponieważ nie mam doświadczenia w programowaniu, z wyjątkiem tego, czego sam się nauczyłem, osobiście uważam, że IB i wszystkie jego funkcje ( IBOutlets, IBActions) pomagają programistom mojego poziomu umiejętności (i wszystkich poziomów umiejętności, jeśli o to chodzi) w realizacji ich projektów w krótszym czasie.

Jego pogląd na IB jest trochę entuzjastyczny. Uważa, że ​​kodery korzystające z Konstruktora interfejsów „oszukują”, ponieważ nie muszą ręcznie układać interfejsów.

Pytanie:

Czy użycie konstruktora GUI do rozłożenia elementów interfejsu należy uznać za „oszukiwanie” (ponieważ większość programów początkowo wymagała ręcznego układania interfejsów w kodzie)? Dlaczego?

To nie oszustwo. Programy takie jak IB są narzędziami. Użyj właściwego do pracy. Nie ma potrzeby zajmować się dogmatami.

Jeśli jesteś bardziej skuteczny przy użyciu takiego narzędzia, użyj go. Jedynym zastrzeżeniem jest to, że powinieneś uczyć się kompromisów przy podejmowaniu decyzji. Ręczne tworzenie układów zapewnia precyzyjną kontrolę kosztem łatwości przeciągania i upuszczania. Narzędzia „przeciągnij i upuść” umożliwiają szybkie i łatwe wykonywanie wielu czynności, ale z czasem mogą utrudniać utrzymanie kodu.

Osobiście nigdy nie miałem sukcesu ani czerpania przyjemności z używania narzędzia do projektowania interfejsu użytkownika typu „przeciągnij i upuść”, ale to tylko ja. Uważam, że ręczne tworzenie GUI jest dla mnie najbardziej skuteczne i daje bazę kodu, która jest łatwiejsza do utrzymania z czasem. Inni mają przeciwne doświadczenie.

Programowanie jako praca nie jest sportem ani grą. Argument oszukiwania jest więc bardzo słaby. Jeśli narzędzia wizualne zwiększą produktywność, głupotą byłoby ich nie używać. Z mojego doświadczenia wynika, że ​​dzięki temu spędzam więcej czasu na rzeczywistym rozwiązywaniu problemów z kodem bez robienia prostych czynności związanych z interfejsem.

Uważaj jednak, ustawienia i dane łatwo wkradają się do interfejsu. Zachowaj radykalność w kwestii oddzielenia prezentacji i logiki.

To tylko oszustwo, jeśli poświęcasz coś, aby się tam dostać. Większość układów GUI po prostu generuje kod, który i tak tworzysz (i często trzeba go edytować ręcznie, ponieważ układ nie jest wystarczający).

Więc w zasadzie nie.

Wszystko inne jest równe, każde narzędzie, które pozwala ci szybciej zrobić to samo, jest dobre.

Oszukiwanie to nazwa gry. Przy podejmowaniu jakiejkolwiek decyzji rozwojowej zawsze powinieneś wybrać najłatwiejszą możliwą drogę. Nazwij to oszustwem, nazwij to „produktywnością”; to nie robi różnicy. Powinieneś wybrać narzędzie, które pomoże ci wykonać zadanie przy jak najmniejszym wysiłku (oczywiście nie zapomnij o konserwacji i skalowalności).

Teraz, szczególnie w przypadku IB, powinieneś porównać czas zaoszczędzony przez IB i koszty utrzymania niechlujnego kodu, z którym się mniej znasz. Jest to tak naprawdę przypadek indywidualny i indywidualny. W wielu przypadkach narzędzia i kreatory pozwalają wykonać znacznie więcej pracy przy niskim koszcie konserwacji ... a czasami wprowadzają kod rozbieżności i bardziej nieszczelną abstrakcję, niż wiesz, co zrobić. Wygląda na to, że sam zdecydowałeś, że IB jest wart wszelkich kosztów, które przyczynia się do rozwoju, jednak twój przyjaciel może równie łatwo stwierdzić, że narzędzie przeszkadza mu bardziej niż pomaga.

Piekło nie Robienie tego całkowicie ręcznie jest jednak wyraźnym przypadkiem samodzielnej pracy.

(Ogólnie rzecz biorąc, rozłożyłem go za pomocą konstruktora i jeśli potrzebne byłoby jakiekolwiek dostrojenie, zwykle - ale nie zawsze - odbywa się ręcznie).

Z pewnością nie jest to oszustwo, chociaż miałbym trochę mniej szacunku dla programisty, który nie mógłby stworzyć GUI bez niego. IMO, użycie jednego nie różni się od korzystania z typu danych dostarczonego przez system - po co wdrażać własną listę połączoną lub mapę skrótu, jeśli można użyć jednej z biblioteki systemowej?

FWIW Kilka miesięcy temu musiałem zaimplementować interfejs użytkownika w Java Swing. Nigdy go nie użyłem, więc napisałem to wszystko ręcznie, aby lepiej zrozumieć, jak to działa. Teraz, gdy znam podstawowy interfejs API, nigdy więcej go nie napiszę, jeśli mogę pomóc!

Jak twierdzi @Bryan Oakley , jest to tylko narzędzie, a nie „oszustwo”. Wszystko zależy od tego, co dokładnie układasz. Jeśli ręcznie sprawiasz, że jest to niezwykle pracochłonne ćwiczenie, powinieneś naprawdę poszukać innych alternatyw, które zwiększą produktywność.

Kiedyś byłem w obozie ręcznego kodowania interfejsu, ale później po serii układania interfejsów, rzuciłem strzałę w kolano i miałem inne zdanie. Jeśli mogę, a to sprawia, że ​​jestem bardziej produktywny, użyłbym narzędzia graficznego do opracowania GUI.

Ostatnio przy użyciu wzorca MVVM, z rozróżnieniem View i ViewModel, jest nieco bardziej jasne, kiedy będziesz używać narzędzi graficznych. Phil Haack omawia to krótko w odcinku podcastu Herding Code na Github for Windows, gdy zapytano go o przejście z tworzenia aplikacji internetowych. Bardziej sensowne jest wykonanie ViewModel z kodowaniem „ręcznie” i pozwolenie projektantowi zbudować widok graficznie (i odpowiednio połączyć ViewModels).

Jedną z wielkich zalet narzędzi, takich jak Interface Builder, jest to, że pozwalają one oddzielić pracę związaną z projektowaniem interfejsu użytkownika od wdrożenia programu. Ktoś z minimalną umiejętnością kodowania może łatwo zmienić układ interfejsu, zmienić podpisy przycisków i menu, przetłumaczyć interfejs na inny język itp.