Object Orientation Pt 3

Pt 2

Which sort of brings me back to the point of the whole discussion. Software is written by programmers using a language, or languages to implement a given business goal. There are techniques that exist in order to help the programmer provide software in an accurate and timely fashion. OO is purported to one of them

But what I want to suggest is that you ditch the IDE of your chosen language and try to develop using notepad and the file-system. This is not because it’s some sort of purist ‘hark back to the mainframe’ days blurb; it’s because this is how you are going to learn about how good or bad the language really is. How difficult is it really going to be to manage hierarchies of classes without an IDE’s help? How difficult is going to be to maintain zillions of lines of code with just notepad and Explorer? How many more typo mistakes do you make without Intellisense, and AutoComplete? Is that the languages fault, or do you think you should learn to look at the screen whilst you’re typing instead of the keyboard?

When I first started to do this I realised a very fundamental point about programming languages. Programming languages are designed to implement a philosophy of development. I have no idea why I didn’t realise it before; perhaps it’s because I’ve never gone through the exercise before, or perhaps ostrich, my head, and sand came more into it.

On an evaluation of a language most people, of whom I am also guilty, assess syntax, and some semantics; I didn’t bother with the philosophy of the language, but its there for all too see. It’s there for all to assess.

The philosophy of the language seems firmly based on the development methodology. Some languages are procedural, some are OO, and some are something different. Yet most people pick the language, not the development methodology. I can choose C#, but really I’m choosing OO. I can choose C, but really I’m choosing procedural.

How many managers, or practitioners are actually aware of this strong, but subtle distinction? Do we know exactly what we are buying into? After all, you are buying into a technology, and methodology. You are choosing to follow a given path. You are setting your IT department down a road that, as long as enough time has passed, will be an irreversible choice.

OO, I believe, is the worst of the lot. It needs an IDE to help the human being manage its complexity. The consequence is that whether or not you are a complete OO expert, the chances are that you will have to learn a specific IDE in order to integrate with your new job.

With the IDE, of course, the complexity is hidden – which is, I’m afraid, just like VB6 and it’s COM underworld.. Am I being backward in this view? Probably, but hey, I still think it’s a valid opinion.

This aside, I think that there is a class of application that really benefits from the OO approach. I think that all things GUI-like benefit hugely from an OO approach. A textbox, for instance, will always be a textbox; will always be a vessel for some poor soul to type stuff into. It’s unlikely to change much.

Examples flood the OO textbooks. Examples that are ridden with hierarchical examples from the ‘real-world.’ Species taxonomy is one such example. Proponents claim that this models the real world – but really it models a human created model of the real world. There is a difference, and once again, it’s quite subtle. The real world does not classify its species quite like we, as humans, do. And fortunately, God does not like to shake things up in this arena too much, so one doesn’t need to worry about change too much.

I think that a lot of OO proponents are intelligent and articulate. Most of the ones I’ve met and worked with certainly are: to be an effective OO practitioner you need to be! It’s a shame that the vast majority of them do not stick around to suffer the consequences of change after the 2nd and 3rd development cycle. Anyone who’s been in the industry for more than five minutes will know that after change cycle 3, it’s time for a re-write with OO code. The code has become unmaintainable, and there’s no one left who really understood what the original design has become. The 3rd cycle normally comes in around year 5, which harks back to that wonderful marketing cycle the big companies adhere too.

I’m sure that there are marvellous counter examples that will ultimately trump what I’m saying. I am a consultant in London, and I would say that what I am saying is about 80% true for all of the companies I’ve worked for. It’s a sad state of affairs.

Do I have an answer to this? No, I do not.

In the vast majority of cases programming models are misused, or abused, because of a moment of necessity. Junior programmers are told to inherit this, override this, and general ‘get up to speed’ or ‘hit the ground running’ with no formal education in what it is that OO software is all about.

If you have a significantly complete specification then OO software can be a marvellous tool to distribute work across the development effort. But in the real world, it’s never the case. And when customers sign off on specifications that are incomplete or plainly wrong we fiscally punish them for being stupid.

Are they being stupid? We fine our customers for not telling us how to create our own objects. Is that right? I don’t think so. Would a functional language be the same? Probably, but there is case to presume changing libraries of functions is a lot less risky than changing interfaces, or object definitions. So much so, that I don’t think the process of invoicing, and arguing that the specification is a little short would be worth the effort.

That is, of course, if you have a design.

As with all programming methodologies if you have a design, you can apply your favourite technology or fad. If you don’t have a design, then OO is certainly not the way to go.

OO, and change? These two things don’t go together.

I thought you wanted to mention GUIs ...

Anyway, that's why I love multi-paradigm languages such as C++. You can pretty much use whatever is best for your specific problem domain.

Quote:

---

Originally Posted by CornedBee

I thought you wanted to mention GUIs ...

Anyway, that's why I love multi-paradigm languages such as C++. You can pretty much use whatever is best for your specific problem domain.

---

I think I did somewhere, didn't I?

Nope, I think you forgot.

It's a short, sweet, two liner. But it's certainly there :)

Whoa, indeed! Well hidden.

I don't understand why you think that OO prevents change (and what kinds of change you mean) and what advantages other paradigms have in this area.

Quote:

---

Originally Posted by CornedBee

Whoa, indeed! Well hidden.

I don't understand why you think that OO prevents change (and what kinds of change you mean) and what advantages other paradigms have in this area.

---

Well, I meant this as a prelude to other discussions. But to be fair it's turned out ot be a vastly simplified overview. I can publish an analysis if you'd like but it'd be terse and essentially unreadable. Treat this as an introduction to what will eventually become the longest unpublished book in history :lol:

I'm having trouble envisioning the "solution"....

I think OO has it's place... mostly in design.... and it has it's use in development.... but it's not the Holy Grail. That would be what ever design/technique fits the situation. In some cases OO makes sense, in some cases it doesn't.

In practice, I've adopted a 50% OO level. Mostly when it comes to my data sinks. But one thing my objects DON'T do is access the datastore (database). They are actionless. It's all properties, and maybe one or two methods (like a Clear). All of my Loads, Saves, Deletes are done in a data access class else where.

One thing I haven't decided on, and usualy changes on a case-by-case issue is if a Contact object has multiple Addresses, if it Addresses should be a collection of Address in the Contact object (Contact.Addresses("Home").Address1), or if it should be it's own separate entity (Addresses("Home").Address1). Since I'm only ever dealing with one contact at any given time, it seems almost a no brainer to make them (addresses) their own collection outside of the Contact object. -shrug-

-tg

Quote:

---

Originally Posted by techgnome

One thing I haven't decided on, and usualy changes on a case-by-case issue is if a Contact object has multiple Addresses, if it Addresses should be a collection of Address in the Contact object (Contact.Addresses("Home").Address1), or if it should be it's own separate entity (Addresses("Home").Address1). Since I'm only ever dealing with one contact at any given time, it seems almost a no brainer to make them (addresses) their own collection outside of the Contact object. -shrug-
-tg

---

Why can't it be both? :confused:


To yrwyddfa. Well put! This is a very common problem if the original architect does not know what he is doing or the app is written based on a constantly changing busisness model.

Quote:

---

I think that a lot of OO proponents are intelligent and articulate. Most of the ones I’ve met and worked with certainly are: to be an effective OO practitioner you need to be! It’s a shame that the vast majority of them do not stick around to suffer the consequences of change after the 2nd and 3rd development cycle. Anyone who’s been in the industry for more than five minutes will know that after change cycle 3, it’s time for a re-write with OO code. The code has become unmaintainable, and there’s no one left who really understood what the original design has become. The 3rd cycle normally comes in around year 5, which harks back to that wonderful marketing cycle the big companies adhere too.

---

I don't care which paradigm is used, if it gets to a certain size it is unreadable.

Some of my responses to Pt2 could have been left out in light of pt3. Species is not a great biological model, but it IS a great biological modeling model.

Unmaintainablity is a good point but my simple answer to that would be that you should have designed it better in the first place. then you would be able to accomodate changes. Although, sometimes it is a bit of a stretch.

As for your point about Notepad, I can spew out PHP without any IDEs (I don't like IDEs) but for things like .NET class libraries I haven't got the time or patience to learn where everything is. I can't do it without the Object Browser or the little autocomplete menus.

Quote:

---

Originally Posted by penagate

Unmaintainablity is a good point but my simple answer to that would be that you should have designed it better in the first place.

---

A situation that will only be verified when change requests come in after you've already released the software

My point was that this will still be spaghetti unless you have documented the program. Perhaps it is different for all of you, but if I don't have notes on the logic of something, it doesn't really matter whether it is OO or procedural, after some length of time, I have forgotten how it works. Any change is as painful as any other at that point.

On the other hand, I have never made an object tree, and I, too, don't like that design style. I have almost never inherited one class from a different class (except for one biological model where it made sense, and one Excel App wrapper where I was lazy). That avoids brittle base classes and other pitfalls. I suppose it also avoids much of OO philosophy, but even MS uses only what they term a 'rational subset'.

i posted this in OO too, then i realized that it hadn't been posted on forlike..ever..so i am quoting what i said here

Quote:

---

Originally Posted by doyer

all problems can be solved by my ideology/religion/awsomenesss....


- i believe in DOS.

Now all i have left is to force that particular belief/religion/ideology/awsomeness onto every1 else thru some amish terrorist group.

*this is where i get afraid that somebody thinks im serious and gets the FBI to come to my house*

---

Talk about digging in the dirt!!

Talk about the arrogance of spamming one ancient thread and then acting as if it was a worthwhile contribution that needs to be in the equally ancient follow-up thread.

Quote:

---

Originally Posted by CornedBee

Talk about the arrogance of spamming one ancient thread and then acting as if it was a worthwhile contribution that needs to be in the equally ancient follow-up thread.

---

How quaint and amusing

it was a worthwhile idea. it can solve all the world's problems as long as it doesn't run into a stack overflow.

This thread is over a year old. Unless you have something constructive and non chit-chatty to post, please let it die (again).

Thank you.

Quote:

---

Originally Posted by penagate

This thread is over a year old. Unless you have something constructive and non chit-chatty to post, please let it die (again).

Thank you.

---

Since when did you become an over-bearing moderator? And my code is still faster than yours ;)