How to stay current on OO programming?

[Resilient]

I am starting a job where I will be programming almost exclusively in C. I want to keep my options open so that if in a couple years I decide I would rather work at a shop where they code in a higher level OO language I will still be relevant.

I find that my motivation to code outside of work is somewhat limited so working on little toy projects probably wont cut it.

Does anyone know of any good contests that focus on good OO design, or at least contests where good OO design is an asset? I have looked at some of the top coder problems and they are much more algorithm driven instead of problems that are driven by needing good higher level design.

Failing that, I am thinking if I could start some sort of side business or do other contract work on the side that might cut it. Something I can spend just a couple hours a week on. How bout websites that have small contract jobs? I know I have seen a few of these in the past.

What else do you guys do to stay current on languages that are not your main focus?

[sourmìlk]

Out of curiosity, why C?

[Ben-oni]

The best way to keep your OO skills sharp is to... learn functional programming.

Although it sounds peculiar, it's true. Once you've learned functional programming, that knowledge will shape how you go about solving problems in every language, including C. One of the immediately useful consequences to the OO programmer is an intrinsic understanding of when and why to use polymorphism (after all, what is an abstract class but a way to refer to functions without knowing what they are?). You'll never think about it the same way again.

To that end, I recommend the annual ICFP Contest. It's been running since 1998, so there are plenty of problems to work through. All languages are valid (someone in 2008 got an honorable mention for a TeX implementation that controlled a "martian rover" in real time: look up the Lone TeXnician for more details), and C++ has done fairly well. The only real qualification for success is the ability to rapidly conceptualize and implement algorithms, so it's a good way to test any programmer's skills.

[Resilient]

Out of curiosity, why C?

Its embedded software, it started in C and I guess they never saw a need to migrate to C++

The best way to keep your OO skills sharp is to... learn functional programming.

It has been my experience that this is not how employers have seen it. For awhile I was very excited by Haskell and when I would talk about it at interviews I would get a raised eyebrow. But I do agree that it helped me thing about things.

As an example of the type of question I want to still be able to answer: I had an interview where I was asked to design a kiosk for customers to view and customize cars. What sort of classes and the hierarchy I would have. I said I would have a vehicle that would have things like HP and wheelbase that were common to all 4 wheeled vehicles, then subclass that into cars, vans and trucks. I got hung up on how I would them implement adding options that could be restricted to only certain types of vehicles. Like if I were to have an option that was only available on cars and trucks, and another that was only available on trucks and vans. Still not sure how I would answer it if I were asked again.

I have found that these sort of design decisions are ones that I make once, start working, decide were a bad idea, come up with a better plan... maybe do this a few more times. But compared to the implementation of the project this portion is fairly small. And it is hard to get feedback because people usually have to really understand the project and look at a lot of code to decide if the system was a good one.

Not really sure where I am going with this other than to give some more context. It would be nice if I could find a 'genre' of program that involves making a lot of these kind of design decisions...

[Ben-oni]

It has been my experience that this is not how employers have seen it. For awhile I was very excited by Haskell and when I would talk about it at interviews I would get a raised eyebrow. But I do agree that it helped me thing about things.

There's been a lot of momentum for the last 30 years in the direction of OO programming. But if you look at this forum as a generic coding forum, it seems half the people here know and value both Lisp and Haskell, not to mention the plethora of other functional languages. I would take that as a serious indication that the momentum is shifting very rapidly.

--

As for the particular question, hierarchical structure does not imply that the hierarchy should be hard coded into the system. This is one of the pitfalls of OO design. The "car" problem is actually one of the premier examples used for teaching OO design; strangely, it's one of the worst possible uses.

It is better to let the specifics of the hierarchy be stored in a data file that can be altered after compilation. So, for instance, if it was later decided to include motorbikes into the selection process, you can just put it into the data file. The kiosk then needs only 1) read the file (trivial), 2) give the customer valid options based on that data structure, 3) handle customer state interactions (say, saving and retrieving previous sessions, handling transactions, etc). Since (3) is where you want your main logic to be anyways, you can focus on that instead of getting lost in OO design decisions.

We can now learn a lesson from functional programming: only add to, never change or delete. For instance, if a customer pulls up an old order, a change to the datafile shouldn't be able to ruin it. Rather, every revision is logged, and the proper datafile can be used. This implies that the hierarchical data structure musn't be a Singleton. Moreover, the data file should include instructions for migration from previous versions.

The MVC design should be fairly obvious, and implies only three classes. None of which represents a "4 door car". As design progresses, utility classes may be found to be useful, but they won't really be part of the main program architecture.

[Resilient]

As for the particular question, hierarchical structure does not imply that the hierarchy should be hard coded into the system. This is one of the pitfalls of OO design. The "car" problem is actually one of the premier examples used for teaching OO design; strangely, it's one of the worst possible uses.

It is better to let the specifics of the hierarchy be stored in a data file that can be altered after compilation. ... 3) handle customer state interactions (say, saving and retrieving previous sessions, handling transactions, etc). Since (3) is where you want your main logic to be anyways, you can focus on that instead of getting lost in OO design decisions.

...

The MVC design should be fairly obvious, and implies only three classes. None of which represents a "4 door car". As design progresses, utility classes may be found to be useful, but they won't really be part of the main program architecture.

I find what you are getting at to be interesting... but I am not sure I believe it.

What kind of structure would you have for your data file in this case? You can't just go all willy-nilly and list wheelbase for some cars and not for others and expect the view to be able to display that in a consistent manner.

My first thought would be to have a couple of different views, one for cars, one for truck etc. but the problem obviously, is what do you do with the Subaru Baja? It's a car and a truck! Or what about when you want to add motorcycles as you pointed out?

From your description it sounds like for the Baja I might just list both car and truck data. But the view still needs to know how to display that. And that is where I don't quite follow your design. How do I go about rending things when the data file may be inconsistent? I can make a view for a car or a view for a truck. How can I design a view that is flexible to display a car/truck when I may not have been planning on it via using this data file? Does the data file need to contain data about how to render the data?

I like your idea, and this question has been bugging me ever sense they asked it so I am genuinely curious to know more about it as it sounds like it is something you have thought about more than me.

[Ben-oni]

What kind of structure would you have for your data file in this case? You can't just go all willy-nilly and list wheelbase for some cars and not for others and expect the view to be able to display that in a consistent manner.

This is the right starting point. And the answer is very much dependent upon the project specifications. Most of your time might be spent working on the file to get it right. Even the question of file type is non-trivial. XML will always work, but it could get ugly fast. If you do, make sure to define the DTD, or you'll be in for a world of headaches. If you're using an interpreted language, you might use the language itself as the format, though it could be a security risk if the files can be altered (as in, traveling through a non-secure network). Personally, I'd probably use either LISP s-expressions or JavaScript's JSON and call it a day (depending on whether it needs to run standalone, or in a browser). The idea, though, is to get it to "look like" the specifications.

For data organization, the original plan was a Tree. "Vehicles" at the root, then Cars, Trucks, Vans, etc. But that didn't work because of the Baja, both a Car and a Truck. So build a lattice instead; multiple inheritance is one way to get that behavior, but this is data, not code. Regardless, defining a finite lattice is trivially easy, once you've chosen that structure. But this was just a way of specifying what vehicles had what things in common. We can do better.

The best plan is to keep it simple, and refactor when complexity appears: for instance, you can list each vehicle and every option available for it, and call it a day. This is the simplest way to accomplish the goal, and should be the de facto solution. As you go, abstract the common elements: anything that is common to all trucks, specify once that is should be included in each of the trucks. When you have a second attribute common to trucks, you'll find you want to have a list of trucks, so go ahead and define one. Then you can use the shorthand. What if you find something that's exceptional? It's common to most trucks, or most vans, but not all, so you want to be able to use the defined list of trucks and remove elements. Perhaps now you see why I would want to use LISP to store this data?

My first thought would be to have a couple of different views, one for cars, one for truck etc. but the problem obviously, is what do you do with the Subaru Baja? It's a car and a truck! Or what about when you want to add motorcycles as you pointed out?

Worse, the Terrafugia is both a car and a plane. But you're worrying about how to deal with corner cases. We'll get back to that.

From your description it sounds like for the Baja I might just list both car and truck data. But the view still needs to know how to display that. And that is where I don't quite follow your design. How do I go about rending things when the data file may be inconsistent? I can make a view for a car or a view for a truck. How can I design a view that is flexible to display a car/truck when I may not have been planning on it via using this data file? Does the data file need to contain data about how to render the data?

Emphatically yes. Views shouldn't be hard-coded. It's messy, and most design programs today end up writing that code for you, which is even messier. Personally, I find it terrible. Individual components, fine: they need code explaining how to render anyways. But an aggregation of components? No way.

Have you ever worked with Cocoa? UI data is stored in a data file loaded and bound dynamically at runtime. That's what you want. Define views (possible in a separate data file that gets referenced), and let any given object specify what view it uses. This may sound like OO, but this isn't happening in code.

When doing HTML design, something similar happens. The server sees a piece of data, needs to render it, and places a chunk of HTML into the output. For AJAX, it's even better: the JavaScript asks for the view from the server, and can then drop it right into the page.

--

The takeaway is this: logic and data are separate, and should be kept separate. Project metadata is just another kind of data, and needs to be kept separate from program logic. It might be tempting to just put them into different files/classes/modules, but this is a bad idea: most programming languages provide very few tools for building data at compile time (LISP being an obvious exception), so don't use the programming language (which is tailored, after all, for specifying program logic) to represent the metadata.