ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
OOP let's you organize the code better. It's easier to maintain a complex code when it's organized in classes. It's easier to understand it when it's object oriented as well as reuse objects across different applications. If the code is designed well and according to OO design principals it might be really helpful to use OOP. However in PHP, IMHO, introduction of first form of OOP leaded many developers to creating the code that did not comply to the OOP standards. Many people started using objects without even understanding what encapsulation or inheritance is... therefore so much crappy code has been created. But, people learn on their own mistakes - don't they?
In procedural programming you will define you data structures and then design the functions that will manipulate these data structures. The two are quite separate entities and it is possible to have functions that will operate differently depending on which data structure is passed in, meaning that the function is almost independent of the data structure.
In Object Orientated programming the data and the functions are tightly coupled. That is a class will define the data and the methods together.
Both approaches work, it's just that the the OOP paradigm scales better. So the industry has gone a little OO crazy. But there is still no substitute for good design.
Many people started using objects without even understanding what encapsulation or inheritance is... therefore so much crappy code has been created. But, people learn on their own mistakes - don't they?
I am one of those people. The code works, but very inefficient and the way it grew, it's all in a mess so much of a mess (specially repetition of code) that's it becoming hard to maintain my scripts, and I tend to make it even more messier as I add new functionality.
I'd say try to redesign the code... if it's not to late And yeah, repetitions suck big time. One of the main points of using OOP is to avoid creating them. But as you can see, without a proper design skills OO program can be more difficult to read than a bunch of well organized functions, so people should think twice before using these practices. And maybe learn UML before doing anything?
IMNSHO, OOP should be used sparingly and only in certain specific circumstances in scripts, in interpreted languages such as PHP, and in "compiled on the fly" languages such as perl. OOP increases server load in such cases (sometimes it hugely increases server loads), and the fact that hardware is now generally faster than software doesn't excuse sloppy programming that wastes huge numbers of bus cycles.
On the other hand, in a compiled language OOP can make all kinds of sense because properly designed objects do indeed help a project scale and can indeed greatly enhance readability.
When working on many different projects where similar functionality is required, and all that under deadline test, then OOP code can make it significantly easier to proceed with the job without having to remember all intricate details.
Work without OOP becomes difficult as the project grows in size and time is running out for delivery dates. This is even true for those who do not like OOP constructs.
I would say that there is a role for OO in web development using scripting languages (such as PHP). For someone who is comfortable with OO concepts they can produce well designed code. Yes there is an overhead but that may not be significant, the extra safeguards that OOP provides can lead to savings in the development and maintenance. So long as those savings are greater that the cost of the extra work the hardware is requested to do it is a viable solution.
Agreed, but it is generally easier to structure large application using O-O design. Which is why many applications, even small ones are done using OO concepts because it has been decided by the developers that an O-O project will be easier to maintain and that it will scale better. That is not to say that there is no scope for pure procedural (or even a mixture) but O-O does have some advantages which tend to be when it comes to maintaining and enhancing the application.
OO is the way to go in a project that is expected to become large and an environment that is compiled.
But employing OO by itself is no guarantee of maintainable code. Some of the most impenetrable code I have EVER tackled was written in C++ and was designed to solve Schroedinger's Equation and Poisson's equation in a layered semiconductor structure. It was fully object-oriented, including in some instances where that added a great deal of complexity while not adding any particular benefit. Variables were named somewhat arbitrarily - and in a couple of cases, deceptively. The documentation was spotty.
I spent a LONG TIME reverse engineering that code to learn WTF was going on. Many aspects of the particular problem would have made a lot more sense if written procedurally, and of course the thing was just badly designed anyway.