oop大作業(yè)報告8篇

本文格式為Word版，下載可任意編輯——oop大作業(yè)報告8篇oop大作業(yè)報告范文第一篇

自我感覺在有好好把握面向?qū)ο缶幊痰乃季S后，在這一階段每周完成PTA和試驗的時間確實沒有以往花費的多了（哈哈哈哈當然有老師放了一定水的原因，在這里再次感謝老師）。題目迭代的設計，我一直很喜歡，可以在接受新思想的同時回想往期的知識。而且現(xiàn)在做ATM級也需要自己思考并設計類圖，這個形式也很不錯，很好的鍛煉并考察了我對面向?qū)ο缶幊痰母鱾€原則的踐行效果。

2.理論課程

在這里我想先表達一下這門課程的愛好，我很喜歡段老師，在他的課堂上，能收獲的往往不是一段段收納并整理好的知識點，更多的是交給了我們一份學習知識的目錄，我可以在課外通過他所給的目錄進行學習，獨立思考，這能更好的穩(wěn)定剛學的知識，對我的幫助真的很大。而且現(xiàn)在課程個作業(yè)終止后老師會給發(fā)送一份源碼，我可以有個參考代碼，可以學習老師的思路的同時比較自己的代碼，并從中學到一些新的知識。

oop大作業(yè)報告范文其次篇

作業(yè)簡介：修改github上的一個snake游戲項目，添加一些特性和功能，需要滿足下面的需求。

貪食蛇的控制

源代碼只支持4個方向的運行，增加可以通過鼠標控制貪食蛇的運動。當按下鼠標鍵時，設置一個方向向量，該方向向量為鼠標所在位置(MousePosition)與蛇頭所在位置(SnakePosition)的差值。下一時刻，貪食蛇依照該向量的方向運動；運動的距離為1個標準單位。

水果的控制

源代碼只支持1種水果，顏色隨機且貪食蛇增加的長度固定。現(xiàn)增加黑色、棕色、紅、藍色、綠色、共5種水果，且貪食蛇吃了黑色、棕色水果不增加其長度，紅色、藍色、綠色水果增加的長度分別為3、2、1；增加的長度在貪食蛇的尾部—假設初始是疊加在一起的。系統(tǒng)隨機生成上述5種水果，保持黑色和褐色水果所占比例為25%，其他的占75%。

繪制精靈版本的貪食蛇

源代碼中的貪食蛇繪制過于簡單—僅僅使用了矩形繪制。要求更改貪食蛇的繪制方法，頭部使用圖片，通過sprite進行繪制。

整體界面的修改

5）理清代碼

原作的源碼：

oop大作業(yè)報告范文第三篇

題目設計與分析：

難度不大，僅僅需要做的是改變輸出的格式，具體修改代碼如下圖。

踩坑心得：

無，由于是在前一次圖形排序游戲的基礎上迭代的題目且功能都已經(jīng)完善和實現(xiàn)，僅僅需要做的是改變輸出格式，完成該題并不困難。

改進建議：

無，該題一次性通過。

oop大作業(yè)報告范文第四篇

題目設計與分析：

題目要求編寫一個銀行ATM機的模擬程序，能夠完成用戶的存款、取款以及查詢余額功能。由于此次指導書未給出類圖，所以需要獨立完成對每個類的設計，難度挑戰(zhàn)不小。首先根據(jù)指導書中所言，將銀聯(lián)、銀行、賬戶、用戶、銀行卡以及ATM設計為實體類，其中僅有一些必需的成員變量和set和get方法。可如何設計這些類的關系成為了頭號難題。

1、設計實體類：在細心閱讀指導書中的相關概念背景后，決定用銀聯(lián)-銀行-用戶-賬戶-銀行卡和銀聯(lián)-銀行-ATM兩條路線通過ArrayList連接各個業(yè)務類之間的關系（經(jīng)下周的課后講解發(fā)現(xiàn)，這么做是存在一定問題的不合規(guī)律，我將會在改進建議里作詳細解釋），隨后在實體類定義相關的成員變量和方法。以Bank類為例，成員變量有name、用戶鏈表和ATM鏈表，類中僅有get與set（實體類），如下圖。

2、設計業(yè)務類：定義一個名為Control的類，其中有的方法主要可以分為四類，信息獲取方法、檢驗方法、數(shù)據(jù)處理方法和輸出結果方法。

信息獲取方法包括Information和getInput兩個方法，Information功能是初始化信息，getInput功能是獲取輸入的信息，詳細代碼如下圖。

檢驗方法有四個，其功能分別是檢驗卡號合法性、檢驗密碼合法性、銀行和ATM編號匹協(xié)同法性和余額合法性。四個類大同小異，這里以檢查卡號合法性為例作詳細解釋。該方法會在銀聯(lián)中通過多個for循環(huán)遍歷以匹配卡號，假使找到了匹配的卡號則返回銀行名稱，否則返回“NotFound〞表面為找到。

數(shù)據(jù)處理方法，通過在銀聯(lián)中遍歷找到對應的卡號，再用set方法修改賬戶的余額。

輸出結果方法有兩個，toString和showResult。toString方法較為簡單，即用卡號ATM編號和存取款金額返回一個固定格式的字符串；showResult會先判斷輸入信息的合法性，若信息正確輸出對應的存取款成功信息，否則輸出對應的報錯信息，如下圖。

踩坑心得：

1.無法正確的找到甚至無法返回對應的銀行名稱或賬戶名。起初在各個檢查合法性的方法中所用的是迭代器進行遍歷的，可一直顯示報錯動態(tài)數(shù)組為null。我錯誤的認為是所學知識不足，沒有正確使用迭代器，便將遍歷的方法改為了用多個嵌套的for循環(huán)。但修改過后問題仍存在，經(jīng)debug檢驗后，發(fā)現(xiàn)錯誤原因是沒有正確的存儲信息，錯將本屬于工商銀行的信息存入的建設銀行。這個小錯誤讓我花費了近半個小時進行處理，但是也給了漲了不少的教訓，編程的時候一定要看清題目。

2.將初始化信息錯誤的存入了其他賬戶導致存取款后輸出的金額與賬戶不匹配。

改進建議：

1.遍歷的方法可以由改為foreach循環(huán)或者iterator，需要循環(huán)鏈表結構的數(shù)據(jù)時，盡可能不使用普通for循環(huán)，這種做法很糟糕，數(shù)據(jù)量大的時候有可能會導致系統(tǒng)崩潰。

2.錯誤的選擇實體類之間的關系，應當是用戶和銀行都擁有多個賬戶，而不是銀行-用戶-賬戶的關系。而且可以在類與類之間寫成雙向的，這樣有助于遍歷時便利正確的找到需要的信息，這一點在下一次迭代題目中有表達。

oop大作業(yè)報告范文第五篇

歷經(jīng)三個階段的學習,我認為面向?qū)ο缶幊趟枷胧浅橄蟮?可以將特定的對象和問題抽象成具有一致特性和行為的對象的抽象的類,增加代碼的通用性、可維護性和可擴展性等等。與上學期學習C語言不同的是，面向?qū)ο蟮乃枷敕椒ê芎玫靥岣吡舜a的可讀性和可維護性?？墒蔷唧w到實際問題，類的設計又是一個十分繁雜的問題，要想編寫出一個優(yōu)秀的代碼是很不簡單的，在這次ATM的兩次設計中，不能完完全全編寫出符合的封裝性、復用性、多態(tài)、繼承、抽象類、接口、單一職責原則、“開-閉〞原則等的代碼，難度較大。這也是我接下來學習的方向和努力的地方。簡單的語法可以快速的學會，但一個語言的思維卻是需要長時間的積累與實踐。

2.編程能力的提升

設計特別特別特別重要性（說三遍強調(diào)），設計是整個工程代碼是否成功的關鍵，這么屢屢作業(yè)讓我明顯地感受到，在繁雜的要求面前，錯誤的設計會帶來巨大的工程量、丑陋不堪的代碼以及各種莫名其妙的bug，而且在后面不斷實現(xiàn)方法的過程中卻發(fā)現(xiàn)，這個方法十分累贅，特別是循環(huán)查找時使用多層遍歷的方法將使得時間繁雜度相當高。

類的設計好壞決定了代碼擁有的功能，假使對進行類設計的時候沒有太多思考的，那么在后來的修改上需要花大量的時間和代碼來修改，表達了類的設計和代碼的質(zhì)量不高。而正確的設計則會使程序更加簡單和明了，不僅復用性更好，寫起來也更加得心應手。

當然，在編程過程中對于嚴謹性讓我學到了不少，好多錯誤就是由于不嚴謹而導致錯誤，特別是這次ATM設計各個實體類中，往往出現(xiàn)數(shù)據(jù)存儲錯誤的地方，最終導致debug檢查錯誤，再反復進行修改。這完完全全是由于自己的不嚴謹導致花了好多不該花的時間，但是也給我漲了不少的教訓，編程的時候一定要看清題目要求，要考慮到指導書中的細節(jié)，反復琢磨，這樣才能更好的編程設計。

3、測試的理解與實踐

三個階段的大作業(yè)將代碼測試的重要性顯示出來了，通過代碼測試你可以優(yōu)化你的代碼以及對代碼的質(zhì)量有個很好的檢測，你可以通過測試你的代碼對你的代碼進行相應的改動，以及減少你查找你的代碼中出現(xiàn)的問題，同時測試可以比較兩個都可以實現(xiàn)一致功能的代碼的質(zhì)量，可以測試出那個代碼的運行時間長短，可以看出那個代碼的存在的一些bug，我感覺測試可以讓代碼更加完美，質(zhì)量更高。我們在完成單方面的設計并不會有很大的困難，但是假使我們將我們編寫的代碼運用廣泛或者是運用生活，會出現(xiàn)好多問題，有些是超額運算的數(shù)據(jù)不確鑿而還會有些是我們時間繁雜程度上會出現(xiàn)超時運行的現(xiàn)象（這在上一階段的計算日期的題目中就有所表達）。

oop大作業(yè)報告范文第六篇

移動方式：

?增加了鼠標控制蛇移動的功能：用鼠標右鍵單擊游戲界面中的某個位置，蛇會朝著這個方向移動。假使轉(zhuǎn)彎角度過大，可能導致死亡判定。

相關核心代碼（只給出修改部分）：

水果顏色、分數(shù)、數(shù)量和初始化方式：

?給水果添加了顏色、分數(shù)的屬性。通過隨機數(shù)，保證有3/4概率生成“紅、綠、藍〞類別的水果，也就是說這三種顏色各占1/4，紅色3分，藍色2分，綠色1分。有1/8概率生成棕色果實，有1/8概率生成黑色果實。這兩種果實都是0分。分數(shù)表示吃掉一個果實后蛇增加的長度。

?蛇的繪制大致結構和原來一致，只不過使用了sprite。

?蛇節(jié)點初始化的代碼如下：

設計貪吃蛇皮膚時的靈感來源:星之卡比（粉色），吃豆人（黃色），微信群上某頭像（藍色）（逃）

（這部分的素材（像素畫）全部是自己設計的）

oop大作業(yè)報告范文第七篇

（很道歉這個類圖有點混亂..）

題目設計與分析：

本次題目是基于老師給的代碼進行的修改，所需要修改的部分并不算多，需要添加的功能分為兩大塊：借記賬戶和貸記賬戶、跨行取款。

跨行取款難度不大，只需要在Bank類中添加成員變量interest，其作用為定義該銀行跨行取款收取的利息。

首先將Account類中修改為抽象類，除了保存一個返回賬戶的方法外，其他方法均修改為抽象方法。再額外定義兩個類名為DebitAccount和CreditAccount（CreditAccount類中需要定義額外的成員interest和creditBalance，作用分別是存儲貸記賬戶的利息和超支額度），并使其繼承自Account類，同時這兩個類實現(xiàn)父類中的抽象方法。具體的代碼編寫難度不大，都可以基本依照老師版本中Account類中的代碼進行修改，如下圖。

（Account類）

（CreditAccount類）

最終是在取款時處理兩大塊功能產(chǎn)生的利息部分（自我感覺我這一塊代碼編寫的還是不錯的，哈哈哈哈自夸一下）。這里通過ATM和Account找到相對應的銀行并匹配其名稱是否相等來更新利息1，再判斷取款金額是否大于存款金額來更新利息2，最終在取款時更新減去的金額。功能實現(xiàn)的代碼如下。

踩坑心得：

基于上一次編寫ATM設計代碼的經(jīng)驗，說實話在處理指導書中要求額外添加的兩個大功能的代碼編寫方面我并沒有遇上什么困難。主要的問題出在好多類被設計成了雙向的……這確實讓我有一點暈乎乎的了。導致我在處理數(shù)據(jù)時又碰見了定義的變量為空的狀況。最終經(jīng)過長達2小時不懈的debug才發(fā)現(xiàn)其原因是父類和子類同時定義了一致的成員變量時，會出現(xiàn)兩個一致名稱的量，其中有一個為null，刪去多余的成員變量后，這才解決了這個問題(真的煎熬了我就很久)。

改進建議：

我想需要改進的部分主要是繼承自Account類的DebitAccount類和CreditAccount類，這兩個類其中的方法代碼編寫都不夠簡單，重復性還很高，Account類中的抽象方法也可以有修改的空間，我會在老師發(fā)這次的源碼后進行細心的閱讀后再進行回想再修改。

oop大作業(yè)報告范文第八篇

題目設計與分析：

題目中有四種形狀的卡牌：圓形、矩形、三角形及梯形并給出各種卡片的相應參，要求求出各卡片的面積大小然后將卡片依照其面積值從大到小進行排序，同時求出所有卡片的面積之和。由于指導書中已給類圖，先根據(jù)類圖創(chuàng)立圖形類并編寫實現(xiàn)對應功能的方法。這些方法主要分為兩類，分別是返回面積的方法和檢測合法性的方法。

首先介紹檢測合法性的方法，通過儲存圖形的DealCardList類中的validat方法調(diào)用各個圖形類中的validat方法，難度不大，如下圖。

其次是返回面積的方法。每個圖形類中的getArea方法中儲存的求面積的數(shù)學公式，再通過父類Card中的toString以字符串形式返回面積數(shù)據(jù)中，如下圖。

最終是要求實現(xiàn)Comparable接口中的compareTo方法，難度不大，通過