OO Software design epiphany - it might not matter

charlieg

My version of a survey - I'm interested in actual experience. I'd post this in SO, but there are so many anal retentive ivory tower type there... I digress. FWIW, this is a little bit of soul searching, so take it as an honest question/statement/search and hell, suggest a book for me to read? I live mostly in the embedded world where things are tightly bound to hardware. It might be the problem. It might be that I'm trying to apply OOD to something that just doesn't warrant it. That said, i've been developing software (of all types) for 40 years, and at the application level, I have *yet* to see any significant code re-use other than copy/paste. I'm a (was?) big believer in OO design. I believe in Abstraction, Encapsulation, Inheritance, and (not)Polymorphism has (had) hope. But I believe that it suffers badly from being too general for what we do as developers. In no particular order: Abstraction - I like it. Hide the details. So far so good. The problem is that most make analogies to objects that don't have an elephanting to do with reality software development. It sounds good, it just doesn't work. Encapsulation - I love it. Hide the details, avoid spaghetti code, methods work with a blob of data. Inheritance - a plague, a virus, useless. Most examples are trivial. Give me one complex application example, and it all falls down. Polymorphism - meh. It's cute. Sure, I can create multiple methods to work with different parameters, but at the application level it is not that groundbreaking. ---------------------------------------------------------- So, in my project I've just spent 3 days (and some nights) trying to make some code generic and OOD and what not, and it's not going to happen. The more I try to make the class behave in a couple of different situations, it's just a boondoggle - which triggered me at 4 am - just copy the code to another function and hard code everything. Hence the question. fwiw, the code I am modifying has not changed in 10 years. So, why bother making it general? I spend a lot of time trying to make code flexible (thinking long term support, etc), and I think I'm wasting my time. Sort of rambling here, I'd like some practical, pragmatic feedback.

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.”

PIEBALDconsult

Polymorphism isn't its own thing. Polymorphism == Abstraction + Encapsulation + Inheritance

den2k88

The embedded world lives mostly in C, and the most versatile environment I know of has deep reusability achieved through an insane amount of defines, to the point that finding references to specific symbols require often 4-5 indirections. I'm talking about AutoSAR specifically. It really depends on where you sit: are you developing a platform or a product? If you work on the final product, keeping things flexible may actually hinder the developement, as either you spend a lot of time trying to perfectly model the product you're developing in order to have flexibility where needed or you end up applying a flexible model which is not adequate to the specific product and end up breaking the model to make it work. If you're working on a platform, that's different. The final product will be, hopefully, shared between hundreds of completely different systems so the expense in finding the perfect model and maintaining it pays off.

GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X

OriginalGriff

Inheritance is very useful: create a "base class" (abstract by preference) and derive the classes you actually use from that. I have base forms, usercontrols, and general classes and it can really save you from some mistakes - like forgetting to update one out of five classes to fix a bug. If it's part of the base class, you fix it in one place and it updates all the others. Admittedly, it's been a long while since I did any embedded work (sob!) but if you can cope with the performance hit that the higher level language brings with it then the improvement in reliability and maintenance effort is well worth it. I generally couldn't - I had low frequency processors and restricted RAM, plus I had to run 24/365 so heap allocation at run time was pretty much a no-no.

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

den2k88

I did use it in a sortofembedded system that had to control several types of hardware, which could be of different makes and models with different communication systems. So the code would instance x generators, x sensors and use them through the generic interface, while the derived classes managed the gritty details of every model.

GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X

charlieg

Product, and you just hammered my nail.

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

charlieg

heap allocation at run-time is something brutally beat into me. :) actually beat out of me.

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

charlieg

well yes, I understand. Are you from Stack Overflow ;)

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

charlieg

Very similar to my situation, but in my case I have to produce a visual representation of said data (that varies wildly) and must be pushed to different display formats. I found the time to produce a class that could be inherited as not worth the effort. If the code never changes (note my comment - 10 years), why bother with the investment? I like the idea of just being able to inherit from a base class, but it happens to rarely.....

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

Greg Utas

My initial reaction is to agree, but the term is nonetheless useful.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

Rage

charlieg wrote:

Are you from Stack Overflow

Since he did not ask you if you to first go get a CS degree before posting questions, he is probably not.

Do not escape reality : improve reality !

Rage

den2k88 wrote:

AutoSAR

:omg: Someone else on CP who knows Autosar !

Do not escape reality : improve reality !

raddevus

My theory is that there are very few examples around that bring OOP all together. OOPs main purpose should be reuse and making the code that you write smaller (less code to deal with when adding enhancements or fixing bugs). I believe that with one very focused example you would see all of PIE-A (Polymorphism, Inheritance, Encapsulation and Abstraction) come together. But most of the time you don't need this type of architecture until things get large. And, most projects don't get large -- especially samples you see. Here's My Attempt This should be an article but I'll do that later. The Entire Premise Imagine you want to save data to three different data stores: 1) file 2) database 3) web location Save instantly becomes our main verb(functionality). Requirements: We Want Four Things 1. Any dev must be able to include the Save() functionality on their class in the future. (interface) 2. Any dev must be able to call the Save() functionality on any class in the future and easily know that it is named Save() -- this is self-documenting code 3. There must be an easy way for dev to configure where the data will be stored (file, db, url) 4. A dev must be able to create a list of various types (classes in the architecture) and iterate through them, calling Save() and knowing that they will save to their appropriate destination. This is Polymorphism -- all objects implement the Interface which provides Save(). Here is the smallest sample I can come up with and it really works. Get LINQPad - The .NET Programmer's Playground[^] and run the code below. You will see the following output:

I'm saving into a FILE : super.txt
I'm saving into a FILE : extra.txt
I'm saving into a DATABASE : connection=superdb;integrated security=true
I'm saving into a WEB LOCATION : http://test.com/saveData?
I'm saving into a FILE : super.txt
I'm saving into a FILE : extra.txt
I'm saving into a DATABASE : connection=superdb;integrated security=true
I'm saving into a WEB LOCATION : http://test.com/saveData?

Now a dev can 1. create an IPersistable object. 2. pass in an IConfigurable object (which determines which data store the Save() will write to 3. call Save() on the object Dev Only Needs To Know Two Things: Abstraction 1. create a configurable object -- select which data store 2. call Save()

void Main()
{

Greg Utas

I also worked in what you could call the embedded world, though not so close to the hardware, and soft rather than hard real-time. An OO rewrite saved the product I was working on, and it's still seeing development over 20 years later. We used all three (encapsulation, inheritance, and polymorphism) extensively.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

den2k88

Got thrown into it about a year and a half ago. It was bound to happen, working in a company that has 80% automotive contracts.

GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X

den2k88

Firmware developement follow different rules than software, there's no circling around it. Software should not depend on the underlying implementation details, firmware is the underlying implementation and it's all about details. Some things should be kept as agnostic as possible, e.g. the main state machine should not depend on the exact make of the various hardware components so interfaces to control hardware should be generic (i.e. peripheral_On, peripheral_Off, peripheral_Sleep, peripheral_Send...) but all the rest can not. One component may be turned on/off via the combination of two pins while another, identical on every aspect, may require timed pulses on a single pin and follow a protocol based on several outputs.

GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X

den2k88

The farther you get from the hardware the more generalized approach are useful / a necessity. I worked in a product with similar specifications ("not so close to the hardware, and soft rather than hard real-time.") and OOP was a huge benefit, when we started adopting it there has been a significant improvement in quality, developement time, customization time and stability.

GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X

Marc Clifton

You are quite correct, IMO. First, forget about the promise of re-use when it comes to objects. Nobody ever does anything in the real world twice exactly the same way to merit any re-use benefit. In order of importance, to me: 1. Encapsulation - keeps stuff organized 2. Interfaces - defines what the class is expected to implement. I also use empty interfaces simply to indicate that the class supports some other behavior. Could use attributes for that as well, but interfaces are sometimes more convenient when dealing with a collection of classes that all support the same thing and there are methods that operate on that, hence I can pass in "IAuditable", for example. 3. Inheritance/Abstraction - mostly useless, but there are times when I want to pull out common properties among a set of logical classes. Note that I don't consider this to be true abstraction, it's using inheritance to defined common properties and behaviors. 4. Polymorphism - useful, but less so now with optional default parameters that do the work of what one often used polymorphic methods for. IMO, the reality of "how useful is OO" falls quite short of the promise of OO.

Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions

Nelek

I was almost thrown in a project where AutoSar was involved. Luckily for me, another project started to burn down and I was sent there to extiguish the fire in the last moment and I could remain in my blessed ignorance.

M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

charlieg

lol, true. I'm an EE, written lots of code but I've always wanted to take an algorithms class. Don't know why, well, at least my analyst asks me.

Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759