2011-06-21 41 views
4

在處理項目時,我經常會遇到首先使用UI或首先使用邏輯的困境。第一次使用UI可以很好地概述最終產品的外觀,同時首先揭示邏輯中的任何可能的障礙。用戶界面首先還是邏輯優先?

然而,它並不總是那麼晶瑩剔透......有時UI可能需要填充數據才能真正顯示它的含義,並且模擬數據可能比實現邏輯更困難..您首選的方法是什麼發展和爲什麼?哪個更有效率和更有效? (我看到這個問題越來越多的iphone項目)

回答

1

都沒有。

無論如何,您必須在項目開始時進行一些思考,決定您將採取的一般方法以及您將支持的操作。

這樣做合理,你會定義視圖和底層邏輯之間的接口。看看Model-View-Controller方法的一些啓發。

你想早點想到什麼是你的邏輯代碼需要做的基本操作,以達到目的。通常這將是一個簡單的函數調用,但有時它可能涉及更多。先清楚一點。

接下來,一個複雜的系統工作基於一個簡單的系統工作。

這意味着您將需要一個基本的用戶界面,您將首先使用它來測試基本的邏輯實現。 帶按鈕的簡單窗體顯示消息是非常基本的。然後,它可以增長,你實現了一個功能,然後你添加一個簡單的UI,你可以測試它。

由於邏輯和邏輯的一小塊邏輯在概念上是相似的,因此在執行和測試時很容易跟蹤兩者。

最重要的部分是保持UI和邏輯解耦,使他們通過通用接口進行通話。這將允許您在需要時進行快速編輯,並最終改進GUI的外觀。

如果你不喜歡它,你將會更好地去掉UI。你所需要做的就是使用相同的接口,你知道該怎麼做,因爲你寫了它,並且你已經實現了它。

如果在某個時候你意識到你犯了一個很大的錯誤,你仍然可以挽救部分代碼,因爲UI和邏輯是分離的,並且希望邏輯部分也是模塊化的。

簡而言之:首先想一想,以較小的增量進行UI和邏輯處理,並保持模塊化。

0

如果可能,並行。

但個人而言,我首先提倡邏輯。

0

我首先從基礎知識開始,這意味着獲得邏輯編碼並首先工作。有兩個原因:

  1. 如果我不能得到的邏輯正常工作有一個漂亮的UI是無用的,我的時間
  2. 浪費,當你在工作,你很可能會改變UI邏輯方面使UI過程更長,更昂貴
0

我通常首先得到我的用戶界面。原因?當我對不同的設計進行原型設計時,有時候我對應用程序的想法會改變如果是這樣,那麼這不是重要的 - 沒有代碼可以重寫。

但是,有時先確定基礎是否有助於確定應用程序是否工作。如果它不起作用,那麼爲什麼浪費時間來製作接口?

1

迭代。來來回回。隨着您瞭解如何以及如何使用邏輯以及可能出現的任何約束,用戶界面可能會發生變化。邏輯可能會隨着您更改體面的UI的功能,行爲或性能要求而發生變化。

我儘可能地做到了每一個,直到我有一些勉強工作的模型。然後,我使用每個模型來測試關於正確UI和/或邏輯的假設可能是對還是錯。選擇最有缺陷的,並開始迭代。

蘋果建議首先在紙上嘲諷UI。 (有橡皮擦,方便...)

0

我喜歡從我的項目的不同部分開始,像Vizio一樣。

我爲我期望擁有的不同視圖製作盒子,並且填充了我期望它們包含的信息。

我爲我的預期模型對象(邏輯)做了另一套框。我向他們填充我期望他們將與之合作的信息,並且在我認爲有必要的模型和視圖之間畫線。

對於對象圖(如果我計劃使用CoreData),對於數據庫表,如果我打算使用外部數據庫,我會做同樣的事情。

將所有東西都放在視覺上幫助我決定是否缺少項目組件之間的任何重要功能或交互。如果我後來失去了我在做的事情,它也給了我一些快速提及的內容。 從那一刻起,我傾向於在模型上工作,直到它完成了足夠的工作來填充視圖的一部分爲止,然後我開始處理視圖,直到它可以與模型進行交互。

我也嘗試識別可以重複使用以實現多種目的的視圖或模型,以便減少我必須完成的工作量。

0

採取敏捷方法,並在迭代中處理少量兩者。慢慢地構建程序的每個功能部分,以便不一次構建任何單片。