Printable View
First, is object oriented programming when you use objects in your program or if you created your own custom objects in your program?
I've read how it's good practice to do object oriented programming, but is it possible to make every program object oriented? If I decided to make a calculator program, do I need to do it as object oriented? When do you use object oriented programming?
I'm a bit confused on this topic.
It is up to you. Not every program has to be OOP (object oriented programming).
OOP Normally does well when modeling real world situations.
Say you have a virtual car. You could create a generic engine class with methods, properties and events then inherit that class as a new class for custom engines that have extended methods, properties, etc...
When complexity grows OOP is usually a better option IMHO.
A calculator on the other hand is not terribly complex and not need an OOP approach.
Regarding existing objects: Yes Controls are objects and are generated from classes just like your custom classes; however just using controls alone is not considered OOP programming.
OOP means different things to differnt people.
At the lowest level it means writing classes that encapsulate data and behavior. But from there people can get drunk on the basics and then go overboard too. How far is too far is very subjective though, and fundamentalism at both extremes is a mistake.
Inheritance is hardly a requirement for object oriented programming. VB6 for example uses COM's interface implementation approach for similar purposes, which can generate far more efficient object code and be more maintainable over time than inheritance models.
However the more slovenly inheritance approach is easier for beginners and can be more powerful, so .Net offers both options.
Only because people don't understand what it is, because people who don't understand what it is, or get so deep into it, try to explain it.Quote:
Originally Posted by dilettante
Case in point:
Descriptions of what object oriented programming is usually devolve into language-specific implementations, which muddies any understanding of it.Quote:
Originally Posted by dilettante
I think that's because that's how most of us "understand" it. And it's not until youve done it in a number of languages and environments that you can really get a good feel for it in a language-agnostic manner.
A Cup is a Cup is a Cup ... doesn't matter what the implementation is - plastic, ceramic, bone china, C++, VB, Java - all cups will have similar properties: Does it have a handle or not; what is its capacity; Shape; Color; etc.
So now we can treat "Cup" as an object that has properties:
Cup.HasHandle = Yes
Cup.Material = Plastic
Cup.IsInsulated = Yes
Cup.Color = Grey and Black
Cup.Capacity = 16
Cup.CapacityUnit = Ounces
And I can add actions to it too...
Cup.Fill
Cup.Empty
That's really the basics of OOD/OOP (OOD = Object-Oriented Design, which in my opinion is where it starts)
from there you can define either an interface, or a full class, that other classes then implement/inherit and further refine it's inner workings. Sometimes those decisions are language-specific -- VB6 for instance didn't have a good means to inherit... but it did have interfaces ... VB.NET though could go either way.
At the same time, recognize there is a time and place for it, and it doesn't always fit, and it's possible to take it too far. Especially when it's developers doing the objctifying.
Case in point - we had a financial system where everything was an object... which means that we had a table for every object in finances... what we ended up with is close to 20 table, each with about 12-18 fields each... the fact that ALL of the tables had the SAME 10 fields to start with, and only varied in the 2-8 fields specific to that transaction type didn't seem to bother anyone... Fortunately we got it redesigned and re-built, this time with some one who has an accounting degree and everything has been normalized and those 20+ tables are now gone, and re-arranged into something that is much more manageable, not only from a programming perspective, but also from reporting.
OOP can be effective, but there is a point of diminishing return.
-tg
OOP fanatics tend to go nuts creating custom Data Access Layers consisting of a ton of little custom classes, making what should be simple into a nightmare. Worse yet you almost always have the more flexible native data access classes (ADO, ADO.Net, etc.) underneath those, so they just add overhead.
As pointed out this can also lead to nasty database design issues unless everything is done carefully. As soon as requirements change you can have a ton of rearchitecting to do.
Object oriented programming is a given in most modern languages. However the religion of Object Oriented Programming (all caps) has done a great deal of harm.
Indeed it has...
I think part of that problem with DAL is that people think DAL equates to the domain language (there's another paradigm that can be taken to extremes) when it in fact doesn't.
what I do is build my objects... then I figure out how to store them. Then I have my DAL, lean and mean and the .GetCup method returns a DataRow... I pass in the ID of the Cup I want and I get a datarow with that cup's data... I then pass that DR to the Cup's constructor (or to a CupFactory) and that's what is responsible for setting the properties and behaviors of the cup. Too often I see people think that their DAL has to be responsible for creating the cup and setting everything... and then they switch from Access to SQLServer or Oracle, which has different DB needs (but all will return a DataRow) and find themselves in a hot mess when it doesn't go as smoothly anymore.
I find that having that logical separation as well as physical separation (I put the DAL stuff in it's own assembly) allows me to create a DAL for SQLServer... or XML, or Binary, or text or Access... meanwhile my business layer and even the domain language doesn't care where the data came from. All it knows is that there is a cup, and this is what it looks like.
And honestly, it took me a LOOOOONG time to get to that point. It really wasn't until I started working full time with .NET and I had real constructors I could pass data to that it all made sense.
-tg
The strict OO design really got going in the late 80s and early 90s with SmallTalk and the beginning standardization of ANSI C++. SmallTalk fanatics tended to deride C++ because you could actually create variables that were NOT in classes in C++. So, OO has always had some purists with ultra-orthodox definitions of OO. I believe that the othodox view of OO is that it must support the encapsulation of data and methods that work on the data, must support inheritance of objects, and must support runtime polymorphism.
Now, whether or not you would use the last two of those depends entirely on the program. You'd really have to do a bunch of stretching exercises before attempting to use runtime polymorphism in a calculator application, or else you'd be likely to strain something (if only credulity). Inheritance in a calculator application would be quite taxing enough. However, if you are using some languages, such as .NET (whether VB, C#, managed C++, or others), then you will be using objects whether you like it or not, so you could SAY that the application is Object Oriented if it benefitted you to do so. For example, in .NET, forms and controls are all objects, and you can't write code that isn't in an object, so everything you create in those languages is in objects. You'd only be using the most superficial of OO principles, though.
I took over a project that was headed into inheritance hell, much like what dilettante described. It had all the classic features: Lots of little classes to encapsulate bits of data, lots of inheritance and probably some polymorphism, not finished, and so forth. That third one is essential for those projects, too, because they become so horribly complex and cumbersome that they generally sink under their own weight. The driver seems to be a desire to design with OO regardless of whether or not it is warranted. The goal should be a working program that is maintainable, first, rather than a program that is written in a certain style first and works second.
Thanks for all the great ideas! I was sitting at my computer today and could not for the life of me think of something to write about. This was really helpful. Thanks again!
Oooookay! We inspired him to write about something...and a few hours later he's banned. That must have been a doozy!
Oh... that's probably my fault... :P I noticed that his sig block had a number of... umm.... ads.... some to some really questionable sites... it just happened to be the exact same links and sig block of another poster posting ton of stuff in the PHP forums too... wonder if he got banned as well... hmmm... might need to go check. Thing was at least the posts were useful.
-tg
I had a look through a bunch of them and couldn't find anything useful at all. They were all just Barnum statements that could apply to any thread. Couple that with two logins having the same IP address and the same highly dubious sigs and... well... conclusions were drawn.Quote:
Thing was at least the posts were useful.
Anyway, on topic:-
Yes but not neccessarily advisable. I personally think OO is the best choice for about 90% of applications. It's more flexible and maintainable and, once you get used to the paradigm, it's easier to visualise an OO application too. For most work you'll ever do that maintainability is the trump card.Quote:
is it possible to make every program object oriented?
However, it's not as testable as functional programming. Because an object has state which the methods can depend on, the result of a call to a method can change indepentently of the parameters passed to the method call. Or, in maths terms, it's non-deterministic. That should never happen in a properly written functional application (and I do mean "properly", so no nasty global variables). For that reason highly safety critical system could still benefit from a functional aproach.
Welcome to a programming philosophy debate, where there's dozens of viable answers and it's hard to call anything right or wrong! Part of the reason it gets this way is the more time you spend developing, the more you tend to think the simple explanations are wrong. Your more complicated ideas tend to be influenced by the projects you've tackled, which invariably taints your bag of tricks towards the solutions that work best in your domain. And those solutions can be completely wrong in other domains. Programming is hard.
An "object-oriented" approach to programming doesn't need an object-oriented language, though it's certainly easier. To think about code from an OO perspective, you try to describe everything as an "object". Objects have "properties" and also some concept of "methods" that represent the things they can do. So if you're writing a farm simulator, it makes sense that you would have a code object for "cow". It might have the properties "Weight" and "Hunger", and might have methods for things like "Moo" or "Eat". The idea is that object-oriented code is supposed to read really naturally:
"Put the cow that has Id 4 into the Barn with Id 6" could look like this:
OO code likes to separate things in such a way that "cow" things belong to "cows", and it's usually not possible to accidentally ask a cow to do something pigs do, like oink.Code:cow = herd.Find(4)
barn = barns.Find(6)
cow.MoveTo(barn)
That sounds sensible and obvious, but before it came along people tended to represent those concepts less formally. Instead of a "Cow" you'd have a data structure capable of holding "Weight" and "Hunger". You'd have a group of methods that, given that data, could do the things cows could do. But since they work on data structures that are often similar, it was common to have sets of functions that worked on multiple things that shared similar data.
"Put the cow that has Id 4 into the Barn with Id 6" might be:
As you can imagine, if I were being silly with copy/paste in that code above, a misplaced "ANIMAL_PIG" could cause MoveAnimalToBarn to think it was working with a pig instead of a cow, and potentially do wrong things. This was difficult to catch, and the compiler certainly couldn't help you. This is just one of many conceptual differences between OO and non-OO code, and each of them has a long list of pros and cons.Code:cowData = GetAnimal(animalData, ANIMAL_COW, 4)
MoveAnimalToBarn(cowData, ANIMAL_COW, 6)
In the end, it turns out that object-oriented languages implement their features using techniques that data-oriented programmers developed to keep their code more sane, like checks to make sure cow data wasn't pig data. It turns out that the things that make code easy to understand and maintain share a lot of qualities no matter what language is used. Right now object-oriented approaches are the most popular, but another style of programming called functional programming is getting a lot of attention. I'm not very qualified to discuss that one yet.
Depending on your background, there's tons of different ways to approach solving problems with object-oriented code. This is actually called "object-oriented analysis and design" and involves many terms like "UML", "TDD", "SOLID", "YAGNI", "Agile", and so on in an almost unenumerable set. Testing comes up often, and discussions of whether one method or another makes code easier or harder to test. Programmers like to argue about and refine our processes. Using any language, I could write a program 12 different ways and argue that any one of them is or isn't object-oriented for various reasons. I can write a completely untestable OO program or one that is 100% tested without.
A lot of the arguments feel like chefs arguing over which brand of knife cuts the best, when any outsider might note that tomatoes don't seem to care about anything but the sharpness of the blade and the steadiness of the hand that holds it. That's how programming languages work: good discipline and understanding of fundamentals beat fancy language features any day.
So sure, you could write any program in an object-oriented style. But for some programs and some design methodology, you spend more time setting up things the "right" way than you do actually solving the problem. A common joke example of "correct" object-oriented design uses 37 files and more than 1,000 lines of code to implement "Hello, World". But any sensible developer could do it in 1-10 lines of code, depending on which school of line counting you subscribe to.
We are scientists, but we are also engineers. Worry less about meeting some formal definition than you worry about meeting budgets, schedules, and maintenance expectations ;)