The following are a small sample of frequently asked questions:
Do you follow the common practice of identifying anti-patterns and
then refactoring the project to remove them
You need to understand anti-patterns and preferably avoid their use,
rather than apply them and then removing them by re-factoring,
which makes no sense unless you are trying to improve an existing
project. If you understand good object
oriented principles then you would avoid most anti-patterns
implicitly.
Numerous books and tutorials state the you should have a limited
number of use cases e.g. 30 to 50, can you explain
No, it's a bizarre statement, and makes absolutely no sense in the
real world. The number of use cases depends on the projects size.
I know of projects that have hundreds.
If I learn Java (or C++) will I implicitly know object orientation
No, you will only understand the basics of OO,
which only gives you a small benefit.
There is a lot of Java (and C++) code in use that is not
very object oriented, apart from the libraries and frameworks
they are using. As a consequence the code is likely to be less
amenable to change and often far more complex than it should be.
Is UML just for documentation
UML and other OO modelling artefacts give you far more than
just documentation.
Most projects model in text, code or thoughts,
but these are not easy to share with other stakeholders.
Modeling in text or code is often a costly option,
as they are more expensive to create and frequently discarded (code)
or partly ignored (text requirments).
UML when used correctly and judiciously is cheap to create models
which are easy to share with other stakeholders. This enables
correctness and other issues to be addressed at an earlier stage
which can be a cheaper option.
Most other non software development processes use models
(e.g. Vehicle design, Building design). They use models to
good effect and UML allows the software business to emulate the
reduced failure rates, and reduction in costly errors.
I have been told to have a few large (fat) use cases and rarely use
extends and includes, is this correct
This depends, which is why I find it is essential to describe
both, 1) a few fat use cases with little use of extends &
includes; 2) the many thin (cohesive) use cases with some
additional use of includes and extends where appropriate.
I do hear of more project failures with the former due to the
complexity (and less cohesive nature) of each use case.
My personal preference is the latter (2) especially for
iterative/incremental projects, however it also needs an
understanding of how to manage project complexity which
is rarely described or taught, so I understand why many people
suggest the former (1).
