Alexis,
Good luck with your studies. I commend you for looking outside of the
classroom for knowledge.
You will soon find that what we learn from books and in classes, doesn't
always happen in the real world. I changed careers a few years back and
got my first programming job a little over a year ago. The company I work
for built a software package on top of a legacy database that breaks all of
the basic DRY principals. On the server side, we use Linux, MySQL, and
Java (they let me use Groovy and Grails on my projects. Woot!!) The client
side runs on Windows and is programed using C#.
So we have a lot of OO technology around here right? So, not county my
Grails projects or the native C# objects like forms, buttons etc, guess how
many objects you will find in our software??? If you guessed between 0 and
maybe 5, you would probably be correct. Somehow, the software was written
in a procedural manner using OO technology. All of the logic is tied to
the forms we use and it's often repeated in several places. We have no
DAOs either, all of our data calls are straight up SQL statements dumped in
to datasets. My attempts to create reusable objects usually break
something unexpected as does any changes made to legacy tables in the
database. I found one class that has over 24k lines of code. Yes, I said
over 24,000 lines of code!!!
I'm lucky because I'm able avoid our client code and program on the server
side in a nice OS envornment, but I still have to deal with that legacy
database everyday and I can't do much with it because if I change it, I
break our client.
When I first got here I was floored by what I saw. I would call friends I
know who work for fortune 500 companies and found out that other than the
24K line monster I found, what I was seeing is actually pretty common.
Programmers are problem solvers. We figure out how to make things work
using the knowledge we have, the knowledge we can obtain and the tools we
can use. It may not always be pretty, it may not always be the "best
solution", but we figure out how to make it work. I'm sure someone is
going to come along some day, take a look at my code and wonder what I was
thinking (if I'm still here, I'll tell them to look at the database I was
stuck with!) But I'm doing the best that I can right now.
So study hard and pray that you don't end up at a company that somehow
managed to everything as backwards like I did! LOL (We all have to start
somewhere right? :) )
Tim
On Wed, Dec 28, 2011 at 11:39 PM, PCMan <pcman.tw@...> wrote:
> On Thu, Dec 29, 2011 at 10:45 AM, Alexis Lopez Zubieta <
> azubieta@...> wrote:
>
>> Thanks for your replies Klaus Knopper and PCMan.
>> As I understood you are planing to use an structured approach to create
>> lxpanel2 and the rest of the LXDE desktop environment.
>> Now I want to expose something. I'm an student of informatics engineering
>> in the UCI where I learned to design and create applications with Object
>> Oriented techniques. But when I came to the world of LXDE I found that
>> there is not an object in the whole code and also I didn't find any design
>> or model of the programs that you build.
>> So two questions come to me:
>> - Are you designing the aplications before start to write code?
>>
> Sure, but I did not receive any formal training and taught myself
> programming with books, other OSS projects, and, google only.
> So the design can be a little bit weird sometimes.
> GTK+ itself is designed in a fully OO way and uses a lot of design
> patterns, but it's written in C.
> However there is no language support for objects in C. We only have struct
> + functions.
> A virtual function table in GTK+ world is a C struct which needs to be
> filled by hand.
> Things does not look like OO initially, but its spirit is OO sometimes.
>
>> - How do you do it? (wich engineering thechniques do you use?)
>>
> None. I did try and error in the past.
> Now I often tried to figure out the design/interfaces/APIs first, and
> start implement them later.
> For the GUI programs, now I tend to design the GUI first.
>
> Regards
>> Alexis.
>>
>> ------------------------------
>> *From: *"PCMan" <pcman.tw@...>
>> *To: *"Klaus Knopper" <lxde@...>
>> *Cc: *"Alexis Lopez Zubieta" <azubieta@...>, "lxde-list" <
>> Lxde-list@...>, "lubuntu-desktop" <
>> lubuntu-desktop@...>
>> *Sent: *Wednesday, December 28, 2011 4:58:39 AM
>> *Subject: *Re: [Lxde-list] About lxpanel2
>>
>>
>> If your "object oriented" refers to the programming language, I'm using
>> Vala now, which is a OO language built on top of GObject/C runtime. The
>> language itself is OO. This, however, does not mean that the program
>> written in it will be OO.
>> I'm not a fan of "making everything an object" approach. No single
>> programming style is best for all cases.
>> Using too much OO stuff in GObject will create extra overhead as its type
>> system is all created at runtime.
>> Type-casting and virtual function calls sometimes requires looking up in
>> tables. Signal emission in GObject/C
>> is also very inefficient, too. So basically, I'd avoid "unnecessary" OO
>> whenever possible.
>>
>> If the term "object oriented" here refers to making everything on the
>> desktop an object, that's a totally different thing and is not related to
>> language used.
>>
>> On Wed, Dec 28, 2011 at 5:27 PM, Klaus Knopper <lxde@...> wrote:
>>
>>> Hi PCMan,
>>>
>>> On Wed, Dec 28, 2011 at 03:21:02PM +0800, PCMan wrote:
>>> > On Wed, Dec 28, 2011 at 11:05 AM, Alexis Lopez Zubieta
>>> > <[1]azubieta@...> wrote:
>>> >
>>> > I have a question about lxpanel2.
>>> > Are you planing to make it using an object oriented approach?
>>> >
>>> > What do you mean by object oriented approach?
>>> > I don't understand what you mean. Any examples?
>>>
>>> I THINK he means whether or not you will be using an object oriented
>>> programming model and programming language (or interpreter on the
>>> runtime or macro level), which has certain advantages (everything like
>>> programs, icons, files, windows etc. are objects where all the code
>>> needed to manage the object is included in the objects class, and not
>>> spread across different places in the code), and disadvantages (well,
>>> object oriented code tends to get voluminous and slow, maybe even buggy,
>>> at least that is the common perception).
>>>
>>> http://en.wikipedia.org/wiki/Object-oriented_programming
>>>
>>> Gnome and KDE both use object oriented models for their desktops, where
>>> KDE also uses an object oriented language, while GNOME works more with
>>> procedural languages (C) and its own object management code.
>>>
>>> Btw, for LXDE, I would, independent of that question, opt for using
>>> anything that is stable, small (in the total resources footprint) and
>>> fast, even if it means less features. I like C, even that it means you
>>> have to be extra careful about memory management and pointer
>>> arithmetics.
>>>
>>> One of the "major features" of LXDE for me was always that it needs less
>>> than 5 seconds to start up all necessary components (lxpanel, pcmanfm,
>>> window manager), instead of initializing a lot of services before you
>>> can do actual work on the desktop. I hope that the new versions of
>>> lxpanel and pcmanfm will still be similarly efficient, no matter which
>>> model or toolkit you will use.
>>>
>>> Regards
>>> -Klaus
>>>
>>
>>
>> --
>> ------------------------------
>> University of Informatic Sciences (UCI) http://www.uci.cu*
>> *Nova Light Development Team http://www.nova.cu
>> Alexis López Zubieta azubieta@...
>>
>>
>> <http://www.antiterroristas.cu/>
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~lubuntu-desktop
> Post to : lubuntu-desktop@...
> Unsubscribe : https://launchpad.net/~lubuntu-desktop
> More help : https://help.launchpad.net/ListHelp
>
>
|