This resource is meeting notes, but held in a public location.
I tend to interact with smaller companies. These people are generally less formally trained in software engineering, and are commercially focused. Generally they note that other organisations are discussing or using OOP, but are reluctant to invest in processes they don't need.
I wrote this document in 2011. As a pure technologist, I hope I am not being patronising. OOP was a breaking wave in the early 80s. But as people are still questioning, technologists will need to keep repeating the same answers.
A few truths
- OOP isn't a magic bullet. OOP is only cost efficient for larger coding architectures.
- OOP shouldn't be fashionable, it is an engineering approach.
- OOP has much higher upfront costs.
- The misapplication of OOP leads to failure in the same fashion as the misapplication of any other paradigms.
- The cost of owning a computerised business system, isn't the creation or deployment (no matter what these cost), it is in the maintenance. For small agile companies “just writing code” is cheap, look at utube or facebook for examples of this practice. From an accountancy perspective, maintenance is equivalent to the regular wages for your employees, and offices for them to work in.
- From a software engineering and project management perspective, heroics indicate poor understanding or control of systems.
- The process of OO design will force developers to have a written description of information flow and business process. This is a highly valuable business asset, even when no code change happens as a consequence.
Business benefits of OOP
- Better support and infrastructure for code re-use.
- Encourages a slightly larger scale thinking during design and analysis.
- Clear structuring of responsibilities encourages better architectural quality. To provide a concrete example, an address is an address, as defined by Royalmail for the UK; whether this hold details of your partners residence or the registered office for B & Q is irrelevant to the processes for that data. This kind to thinking leads to better engineering.
- Encourages localisation of responsibility. This is advantageous for “agile” businesses, as side effects of change are known with a better level of accuracy.
- Thorough testing for larger processes is easier to organise. As a unit of code has a clearly defined interface, unit testing on that interface is practical. Regression testing against known interfaces allows [business-wise] agile IT departments. Quality therefore is easier to manage.
Developer benefits of OOP
- This shouldn't be a benefit of OOP, but LOGGING! As the problems are divided into messages past round the system, traces on the boundaries and junctions are easy to automatically assemble.
- OOP provides a mechanism to force management to accept the risk in holding on to fragile “evolved” spaghetti code increases with age. Code is an ephemeral asset, and doesn't gain value with age.
- To express point3 [above] in different words, as there is a design phase, whoffle is detectable by the words used in the objects. Anything not applicable to current usage may be safely subclassed.
- Reduced coupling of data-systems. This is the technologists perspective leveraging point5, agile businesses are frequently high growth companies.
- Personally, I think it leads to cleaner namespaces and more readable code.
- Good use of OOP allows better control on upgrade processes. Piecemeal assembled systems frequently have poorly defined data interfaces, and are highly coupled. This means logically irrelevant changes will affect business functionality. This grossly complicates your activities.
- Makes non-functional requirements like supporting non-locale languages easier to factor into development. Due to a more complex design paradigm, features like this are quite cheap.
- Cannot practically be applied to an existing design.
- Benefits from clean start, in terms of problem description.
- An acceptance by all parties that there are no “sacred cows” which must be preserved.