D286 Java Fundamentals is banner number ITSW 3172 and three competency units in the School of Technology. The catalog describes it as introducing object-oriented programming in Java through methods, class design and other object-oriented constructs, which makes this the course where students stop writing instructions and start designing types. What it builds toward is the mental model everything later in the Java sequence depends on: that a program is a set of objects with responsibilities, and that where you put a piece of data decides most of what your code will look like.
Designing types instead of writing steps
Students who have written procedural code arrive able to solve the problem and unable to structure the solution the way the course wants. The shift is from asking what steps happen to asking what things exist, what each one knows, and what each one can do. A class is a decision about responsibility, and the graded quality of a design is mostly whether responsibilities landed in sensible places.
Encapsulation is the first construct and the one that is easy to fake. Making every field private and generating a getter and a setter for each is the pattern most students produce, and it is encapsulation in form only, because a field with a public setter is a public field with extra steps. Real encapsulation means the class protects an invariant: a balance that cannot go negative, a date range whose end cannot precede its start, a collection nobody outside can modify. Being able to name one invariant your class enforces is worth more than twenty accessor methods.
Constructors are the second. An object should be valid the moment it exists, which means the constructor takes what the object needs and rejects what it cannot accept. Objects created empty and filled in afterwards spend part of their life in an invalid state, and every method has to defend against it.
Inheritance and polymorphism arrive next and get overused immediately. Inheritance says one type is a specialized kind of another, and it is the right tool far less often than students apply it. When a shared capability is what you need rather than a shared identity, an interface expresses it better. Overriding, and the difference between overriding and overloading, is a definition students confuse under exam conditions and in writing.
From scored aspects to a class list and a word budget
WGU scores each aspect independently and requires a 2 in each to pass a task. In an object-oriented course the useful conversion is aspect to class or aspect to method, and the discipline is being able to say which file and which member satisfies each row before writing the document.
Run the arithmetic. Suppose seven scored aspects and a design write-up of about 1,200 words. Seven into 1,200 is 171 each. Sort them. Four aspects are implementation demonstrations, satisfied by the code, so 80 words each of pointer text naming the class and method, which is 320 and releases about 360. One aspect asks you to justify your class decomposition, the central argument of an object-oriented submission, so give it 380. One asks about encapsulation and how the class protects its data, 300. One asks about testing or validation, 200. Adding those, 320 plus 380 plus 300 plus 200 is 1,200, on target, with the two design arguments taking well over half the prose.
Sketch the classes on paper before opening the editor: name, the data it holds, the operations it offers, and the invariant it protects. Three or four classes described that way is a design, and it is the artifact that makes the justification aspect answerable.
Working through Java Fundamentals?
Send the aspects together with the specification. You get a class breakdown with responsibilities and invariants, plus a model design write-up.
The worksheet that produces a defensible class design
| Question | Weak answer | Answer that scores |
|---|---|---|
| What does this class represent? | A manager or a handler | A single concept from the problem domain |
| What does it know? | Every field the program needs | Only the data it is responsible for |
| What can it do? | Getters and setters | Operations expressed in the language of the domain |
| What must always be true of it? | Nothing stated | A named invariant the constructor and methods enforce |
| Who creates it, and with what? | An empty constructor, fields set later | A constructor taking what validity requires |
| What does it refuse? | Accepts anything, fails later | Rejects invalid input where it enters the object |
| Why not merge it with its neighbor? | No reason considered | A stated reason the responsibilities are separate |
Fill the right column for each of your classes and the justification section writes itself, because every row is a decision with a reason already attached.
Documentation, tests and honest sourcing
Java has a documentation convention and using it properly reads as professional practice. Comments on each public class and method stating purpose, parameters, return value and any exception thrown are the standard, and they are read by evaluators as evidence of design intent. Inline comments then carry the reasoning that the code cannot show, such as why a bound is inclusive or why a case is treated specially.
Testing evidence belongs in the document even when no aspect demands automation. A table of inputs, expected results and observed results, with rows for invalid input and boundary values, demonstrates that the class enforces what you claimed it enforces. Where you assert that a constructor rejects a bad value, show the rejection.
On sourcing, the platform API documentation is the authority for library behavior and cites as an organizational web source in APA where your program requires it. Any code adapted from a published example or tutorial gets a comment naming its origin, and you should be able to explain every line of it, because the justification aspects ask about decisions and borrowed code contains somebody else's.
What passes the first time here
Work is recorded as Competent or Not Competent at WGU, with no letter grades and no ordinary grade point average, and performance assessment work returns for free revision if an aspect is missed. In a six month flat rate term the cost is days, so the aim is a submission where every claim about the design points at code.
Submissions that clear compile from a clean folder, run without a development environment attached, and produce the exact output format the specification named. Their classes have responsibilities you could state in a sentence each. Their write-ups argue for the decomposition rather than listing the classes.
Returns are predictable. One class holding the whole program, which makes every aspect about object-oriented design hard to answer. Getters and setters for every field with no invariant anywhere, which is encapsulation in appearance only. Inheritance used where the relationship is not a specialization. And a justification aspect answered with a description of what each class contains rather than a reason it exists.
Five mistakes that slow D286 students
- Writing procedural code inside a class. A single class with a long main method is a script wearing a class declaration.
- Generating accessors reflexively. Ask what the class protects before exposing a field. A setter for every field gives away the protection you just built.
- Comparing objects with the wrong operator. Reference comparison where value comparison was meant produces a bug that reads as impossible until you know the rule.
- Reaching for inheritance first. Shared behavior is not the same as shared identity. An interface is often the honest expression of what you need.
- Leaving validation to the caller. If the object can be created in an invalid state, every method has to defend against it and one of them will forget.
How we work on this course
D286 support is design work you keep. Send the scored aspects and the specification and you get a class breakdown with responsibilities and invariants, a decomposition argument you can defend in your own words, a test matrix covering the invalid cases, and a model write-up in the register WGU evaluators expect. Reviews of your own code explain the defect and the principle behind it rather than replacing your file. Where a section of the course uses an objective assessment, support is preparation only, and objective assessments are proctored: we never sit or assist during one and never ask for or use portal credentials.
This course is the base layer for the Java sequence, so time invested here returns in the frameworks and advanced courses rather than being spent once. In a six month flat rate term that compounding is what lets a plan close on schedule.
Three questions D286 students ask
Is D286 the same course as ITSW 3172?
Do I need programming experience before D286?
How many classes should my program have?
Where D286 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.