Object-Oriented Software Development

knownspace logo
KnownSpace alumni

  • Fall 2020: 8:40 PM - 9:55 PM (online)
  • 3 credit hours (grad and undergrad)
  • office hours: by appointment
  • AI: ?vidit mohaniya? - at - ? indiana.edu
Project wiki

mailing list


This course will help turn motivated students into superior contributors to any small- to mid-sized commercial or open-source software project. It takes a hands-on, learning-by-doing approach. Students are introduced to design patterns, tools, and teamwork strategies from the first assignment to the last project.

The tools of modern object-oriented software development are many, and complicated. The main ones to be treated in this course are: design-support tools (principally design patterns), programming-support tools (principally a visual editor, a code repository, unit testing and code coverage, and a logger), and teamwork-support tools (principally a mailing list, a project wiki, an issue tracker, a code integrator and release generator). Students in this course will have to master all such tools to be successful. (Here is a list of current tools: eclipse, git, confluence, junit, jira, log4j, bamboo, jacoco, eclemma, sonarqube, maven, mockito, webstart, spring, hibernate, and possibly lombok and thymeleaf.)

This course has a strong emphasis on project design and programming. Assignments are in Java and the course is intended primarily for grad students. (Although, able Java-proficient undergrads are encouraged to attend as well, however, note that it is extremely time-intensive!) It is design and programming intensive, and uses Java for presentation and analysis of design patterns and for assignments and projects. (Here is a list of current design patterns: observer, command, composite, macro-command, null object, strategy, model-view-controller, proxy, iterator, singleton, decorator, factory method, abstract factory, builder.)


This course will help motivated students:

  • master objected-oriented design,
  • develop advanced object-oriented programming insight,
  • apply modern software engineering---focussing on agile programming, unit testing, test-driven development, and refactoring,
  • familiarize themselves with the situations and motivations that call for using a range of design patterns,
  • learn how to use design patterns and modern software development tools,
  • learn how to present their work in front of an audience clearly and succinctly, and
  • (most importantly of all) learn how to work with teammates and with other teams within a large common project.


After a few weeks devoted to covering the basics of design patterns, agile programming, unit testing, and refactoring, students will apply all that to a significant software project. Students will be expected to deliver a working product. Students will work in teams all term long. Students must be committed to delivering an elegant design, robust code, well-written documentation, and be able to present their work to an audience intelligibly. For those with no prior real-world working experience it will be time-consuming and, sometimes, mentally challenging. Why take it?

NOTE: It is your responsibility to master Swing or JavaFX. Although early assignments will be dedicated partly to mastering advanced Swing or JavaFX use they are still mostly about mastering design patterns as without design patterns you can't fully understand a modern large library (like Swing) in the first place.


Students MUST know Java well to take this course. Students must be VERY COMFORTABLE with the material in this elementary Java text and the following list of style rules. If Java is alien to you, or you think style is not important, or you think Java is just perverted C, this course is not for you. On the other hand, if you are very comfortable with C# or C++ or (most especially) Smalltalk, you can still take the class, but you must still program in Java and thus must be able to master it quickly and on your own.

No auditors will be allowed. Everyone must get their hands dirty.


There will be no midterm and no final. The first 6-7 weeks will be devoted to:

  • four of five one-week design or refactoring programming assignments,
  • one two-week design and programming assignment,
  • one to two weeks of requirements analysis, design, and project planning for your project(s).

The last month (or more, depending on how it goes) will be devoted to:
  • one (or more, but in parallel) large design and programming project, including codebase integration, demoing, documentation, and project presentations. Code releases and presentation of work done will be weekly. The ideal would be to have just one class-wide project broken up into connected but mostly independent parts, but depending on class size and interest there might be as many as four separate projects.

Students will be teamed to design, program, document, and present assignments and projects. Teams are randomly assigned so as to maximize mixing, and the size of teams may increase across term. The first assignment is given on the first day and will be a four-person (or possibly five-person, depending on class size) one-week team project. The second assignment will be another four-person one-week team assignment, but with different members. The third assignment will be another four-person one-week team project, and so on. As a rule, each assignment will be cumulative---that is, no assignment will be `throw-away;' they will all build on each other.

Assignments will be evaluated by me and the AI, and, most importantly, by the class itself via anonymous peer review. Each week, each student will be required to evaluate their partners cumulatively (that is, they must anonymously rank all their partners as their number of teammates increases across term, and give reasons for their ranking). Overall assignment grades for each student will be a function of his or her performance with each of the partners worked with and with the overall quality of the work that student's various teams have accomplished.

Each week, each team must present their work in front of the class. This involves mastering presentation software and hardware, and video software (for non-live demos), and also mastering the class's wiki software (for documentation). I will be grading each presentation and giving pointers to each team on how they can improve each week live and in-person.

At midterm, I (and the AI) will do a private, face-to-face review of everyone in the class, explaining their possible shortcomings or standout achievements and giving guidance on how they can improve or what they should strive to maintain.

Course grade will be allocated as follows:

  • 25% for assignments,
  • 25% for presentations,
  • 50% for projects, allocated as follows:
    • 50% for proper use of patterns and for component correctness (that is, compliance with the team's previously approved specification);
    • 25% for clarity and completeness of the specification and documentation, as depicted in presentations and design documents;
    • 25% for the overall success of the course project (not just the team's component; you will not be working on some mickey mouse independent projects, all components must tie together).

Projects will vary from term to term depending on how many outside clients we have in any particular term and what their needs are. In case of no clients, the class's default project will likely be extensions of an interface builder, Fluency (other, but much lower probability, possibilities: KnownSpace Symphony, a peer-to-peer distributed programming environment, and its mailer, Helium. All 3 subprojects are part of the KnownSpace Project).

It is hopeless to learn design patterns and modern programming tools without a lot of practice on something large. The project will require initiative, motivation, and energy. Each team will eventually be asked to work in a different technical area on its own (no special background in these areas is required; students will learn on the job). Moreover, the course project as a whole depends on the timely completion, interoperability, and correctness of each team's component project.

Students are STRONGLY ENCOURAGED to steal ideas from the web, books, each other, a magic 8-ball, or any other source to get the job done---as long as they give PROMINENT credit to the original source of any significant contribution in their team's design document (that is, not buried deep in some method or class).

NOTE in your previous classes you may not have had to care about software licenses. In this class you WILL have to care. 'Free' software (even in a book) is almost never 'free' in the legal sense. Across term you will discover the differences and dangers among several open-source licenses, particularly BSD, MIT, Apache, Mozilla, and GPL.

Head First Design Patterns Eric Freeman, Elisabeth Freeman