Software Applications Designs

Question

Is strict OOD/Interface-based design/Aspect oriented design is desirable in case of a software application development?

Or, is it desirable to mix all of them for the ease of coding?

Are all successful and highly maintainable software applications strictly Object oriented, or, strictly Interface oriented, or, strictly Aspect Oriented, or a mix of them?

If they are so strict, which methodology should I follow to avoid analysis paralysis while achieving an extremely powerful design in case of these three?

If you think that, Interface-based programming and AOP are just only the extensions of OOP then think this way, how were the softwares designed before the concepts of Interface-based Programming and AOP arrived?

And also AOP may need an AOP container.

Answer 1

A mix, and perhaps none at all.

Anything based on a non-OO language (e.g. C) will have difficultly fulfilling the criteria imposed by an OO definition.

Projects in functional languages won't adhere to any of the above.

All of these 'oriented' design methodologies are just that. Orientations. You should be able to recognise the pros and cons of each approach, and learn to mix and match where desirable, based on appropriateness, complexity, budget, timescales, maintainability etc.

Answer 2

Your question confuses the goals of a software project with the means to achieve them. Things/buzzwords like Interface-based design or AOP can be highly beneficial (don't get me wrong: I really like them), but they can also lead to catastrophic results, if they are used where they're not appropriate.

If you have a nail, then use a hammer. If you have a screw, then use a screwdriver. If there is none of them, then neither of the two tools will be useful...

Answer 3

Are all successful and highly maintainable software applications strictly Object oriented, or, strictly Interface oriented, or, strictly Aspect Oriented, or a mix of them?

Some applications are successful, some are highly maintainable. One example I can think of is Artisan Studio, an early-adopter SysML tool, but came across as as having very low maintainability when I went for an interview. It's design is component style OO C++ - a distributed OO database and using COM to allow features to be added as components; but they admitted to having a lot of trouble working on a large legacy codebase. I suspect that now the much cheaper and more agile Enterprise Architect UML tool has an SysML offering that success will erode. I haven't talked to EA's designers, but EA is built on a SQL database back-end, and the automation API is very obviously not a pure OO solution - for example, you have to update different parts of the same property of a UML object using different APIs ( a UML package is represented by both a Package object and an Element element, and if you change the name of the package in one API you have to remember to change it in the other or it'll have a different name in the package tree and on any diagram ). Given the rate that features are added to EA, and the general quality of the feel of the application, I suspect it to be more agile than the "better OO" model Artisan adopted, but can't easily refactor.

I don't find a strong connection between maintainability and success, or strict OO and success. Doing what is needed and the ability to refactor software is probably more important to success. That and a good marketing department.

( refactoring something is the opposite of maintaining something - in refactoring you're changing the architecture but the feature set is static; maintenance involves adding new features or removing bugs from an existing architecture )