"Encapsulation": one right answer is "Hiding the details and just providing the interfaces.". E.g., when you use a private attribute in a Java class, you prevent that attribute being mentioned outside the class's code, and so you prevent code outside this class from depending on it. The result is that as the developer of this class, you can change or delete that attribute, and code outside the class won't have to change; this eases maintenance. It also means that if the value of a private attribute ends up wrong, you only have a limited amount of code you have to check to find out how it ended up wrong. This makes it easier to debug problems, again, easing both development and maintenance. Hence encapsulation is a Good Thing. Make details available only on a need to know basis. We'll have more to say about this kind of design principle later.
Advantages and disadvantages of making a subclass: I got lots of answers that made it clear that you understood what a subclass was (which is good!) but the software engineering implications didn't seem to be so well understood. The key thing is that the motivation for subclassing is not about saving effort for the subclass implementer: it's about enabling existing client code that works with the superclass to work, unaltered, with the new subclass. And that is polymorphism (I had few answers to that question and most of them were wrong: see here for a bit more on that). For that to make sense, it needs to be the case that every instance of the subclass can be regarded as an instance of the superclass: the "is a" test that many of you remembered.
I wrote some longer notes on these things in response to last year's SEOC pre-assessment, so rather than repeat myself let me link: see here.
Roughly how big was it, in lines of code (written by humans, i.e. ignore
generated code)?
Besides you, what was the largest number of people you ever knew to work on
it (in software development) simultaneously?
How long were you (or have you been so far) involved in it?
As expected, there are people with a wide variety of previous experience on this course. The most striking thing (yes, it strikes me every year :-) was that experience of working with many people was even rarer than experience of working with a large codebase, or even working with the same project over a number of years. Very few people had worked with a team of more than 15 people: this means you are likely to see the context in which agile methodologies were developed as familiar, and the context in which higher ceremony processes like the Unified Process were developed as strange. Just bear it in mind.
perdita@inf.ed.ac.uk
)
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk Please contact our webadmin with any comments or corrections. Logging and Cookies Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh |