Fortunately Faux OOP is easy to spot as it is actually just procedural code organized into objects. Tell tale signs of Faux OOP are a separation of data and behaviour with anemic data 'objects' manipulated by stateless methods (or procedures) in other classes. Faux OOP is often littered with classes named with agent nouns (*Manager, *Helper etc.) or *Service which tend to be stateless (and often singletons or static classes) which hold common variables (better known as global variables). The rest of the code is built from data classes which consist mainly of getters and setters and no, or rudimentary, behaviour which are poked and prodded by their *Manager counterparts. The end result is a program consisting of tasks which act upon data structures and use basic program flow (ifs, switches, loops) to execute the tasks in order.
Faux OOP is an anti-pattern promoted by some of the biggest players in the industry: Microsoft's N-Tier architecture, popular with VB and early .NET promotes Faux OOP by prescribing a Data layer, Business Layer and Presentation layer. The presentation layer binds to data objects provided by the data layer which are then validated and actioned via the business layer. The SOA craze has also helped promote the procedural style where people have reduced their systems to procedural service calls.
Though be careful, you may think you have Faux OOP but really you've got Faux Procedural.
Faux Procedural
It may look like procedural because the program has methods and data structures but if you look closer it may be sequential code organized into methods.
Faux Procedural
It may look like procedural because the program has methods and data structures but if you look closer it may be sequential code organized into methods.
Tell tale signs of Faux Procedural are long methods with no distinct separation into common tasks. These long methods often contain significant repetition and the heavy use of temporary variables. Common tasks are not abstracted into smaller, reusable methods and common groups of variables have not been abstracted into data structures.
Fortunately, with heavy refactoring, Faux Procedural can be refactored into Faux OOP and Faux OOP can be refactored into Real OOP(tm).
1 comment:
I think that a lot of 'FOOP' is due to the fact that in most classical 3-tiered applications, the outside layers on the middle tier are essentially interacting with non-OO entities and are designed to reflect this. These design decisions for the outer layers then push inwards, resulting in what you described.
Although, I must confess that I think Faux OOP is not always Faux by itself, if you know what you are dealing with. I kind of like the idea of having a no-nonsense stateless DTO-spewing Service layer interacted upon by a stateful Application layer. The Service layer represents (predefined) domain logic in the most straightforward way as possible, only as a thin wrapper really, leaking backend abstractions almost on purpose. Since the Application layer is written from scratch, encapsulated by other layers, you can more or less do with it what you want, and here I would keep state and behavior together.
Just as you can do OOP in a non-OO language, you can do non-OOP in an OO language as you stated, but the difference can be purpose, or the lack thereof. Some people indeed think that everything they write in, say, Java is OO by definition. As for me, I'd like to think that I knowingly break the OO rules and regulations when it suits my needs. Yes, I am known to use DTOs. Yes, I sometimes use inheritance as import. And so on. Still, in this way I have written and contributed to several applications that are simple to understand, flexible, extensible and maintainable. And that have an air of FOOP nevertheless.
Post a Comment