OOSE Vs. Structured SE

Clarifications

I've done one man and team projects in both.

The advantage of OO?
Two fold.

First it's far easier to describe real world objects e.g. a customer or an order in 'english'. This gives you confidence that parts of the requirement hasn't been omitted. Equally it gives you a chance for a one to one mapping from requirement to implementation. To be quite honest in business IT this is by far the biggest boon.

The second reason is technical. OO describes the real world concepts in terms of the operations you wish to carry out on them.

An integer is something you can add, subtract, etc not four bytes of storage somewhere in memory.

OO is structured engineering, parts of the structure are explicit that's all.

Without OO, you had one routine to cope with storage , one for each operation, be it processing or presentation. All links between these routines were added through code, in OO they are added through the structure, or at least should be if you've done it properly.

PS. Be prepared for spam, it's not a good idea to stick your email right out in public like that.

Everyone always says OO is better than Procedural, for any project.

In addition to the reasons Tony mentioned, with OO code you only have a few functions in each file, at most a few hundred lines of code. much easier to debug than a Strucured / Procedural code, where you have millions of lines of code in one file.

I have not any such comment. The word "advisable" suggests that it is a caution. There are some projects that are far too simple and OO might be an overkill.

Say, you had a Sales Order screen, with the possible operations like Save, Load and Delete. If you want to separate out the UI logic code and the business logic, then OOPS offers a better and easier way to do this. So you would encapsulate the Sales Order operations in a Sales Order object, and also make the Sales Order contain its own data.