Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Originally posted by Gerald Davis:
The thing I don't like about Object Oriented Design is I am forever shifting around objects and responsibility in Class Diagram.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
... We don't see C and COBOL and Pascal as growing languages any more. ...
Originally posted by Guy Allard:
I'll just point out that modern IBM mainframe COBOL has OO syntactical constructs: class declaration, implementation, inheritance, ........
Guy
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Gerald Davis:
[QB]Good oop is always compared to bad Funtional programming.
QB]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
Idunno about that. I went from pretty hot stuff (have to say that myself) at functional programming to a rookie at OO and still liked my OO work better.
Originally posted by Gerald Davis:
Relation modal is more flexable, because you can use queries. to get different aspects of the system.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Actually doing that can make a system more rigid - because you have all kind of wired queries you don't have control over, you can't change the underlying relational model any longer.
There needs to be a balance between doing things the easiest way now, and investing some time in decoupling, so that changing things in the future doesn't become impossible. OO shines in the latter aspect, in my experience.
The thing I don't like about object oriented technology is it seems to encourage the inflexible tree structures.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Gerald Davis:
I used MS-Access for my better projects, and I use queries as sort of interface between the the Database and the code so I see them as a good thing.
I don't get your angle on this. do you have any links or could you explain better.
The thing I don't like about object oriented technology is it seems to encourage the inflexible tree structures.
Example if modelling business employees using object oriented methodology, It would be natural to map employees by order of importance CIO, middle managers, supervisers and lastly lowly white collier workers.
But there is more then one representation of the employees. How about cross referential teams and situations were specialist members of staff have more importance then higher ones.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Yes, so don't do that. That doesn't mean that you shouldn't use OO, though. Depending on the requirements, the Role Object pattern might become handy, for example.
It's important to notice that OO is *not* meant to be used to mimic hierachies that seem to match "the real world". OO is a tool to manage code dependencies. More specifically, inheritance ("building trees") is a tool to reuse code, and in statically typed languages like Java also to decouple code through the use of polymorphism. (In other languages, like Smalltalk, you don't need inheritance for polymorphism.)
If you take the time to learn how to use the tools of OO effectively, I'm positive that you will find them to be quite valuable!
Originally posted by Gerald Davis:
Thanks dude , I really appreciate the your time.
I have to say something about object oriented code reuse, to put it simply functions are smaller reusable components then class especially
to the fact that they are not hard-grafted to data.
Currently my project I am working on is a HTML editor, I have made the big step of not using a single user defined class. As a consequence
my potential for reuse has increase because by my nature I always liked creating small functions.
The freedom of being able to group functions next to each other the they way I want in the source without the classes getting in the way makes the chance of reuse much easier.
I am dying to know what kind of way I might become a victim of functional programming.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
First, in functional programming you don't have globals, as far as I know, as it is the discipline of programming without side effects.
Second, it might well be that you don't get into any problems. Especially for small programs, applying OO techniques might not be necessary.
I am currently working on a project that is now running for more than six years and has approximately 0.5 million lines of codes in more than 60 modules. I can tell you that without heavy application of OO principles, this project would have died.
Originally posted by Gerald Davis:
OO tends to group operations around nouns while functional programming tends to group around tasks
One of the problems with using OO subclassing to handle variations is that the "boundaries of change or variations" often do not fall cleanly around a method's boundary.
Lets say I have a functions for parsing a string and one for persistence. The object oriented way of doing things is to have the parsing functions as a method in a parsing class and persistence function as a method in a persistence class.
I would be forced to use the whole Parsing and Persistence class just to use those two methods.
Also I can put these functions next to each other, to make it easier to spot duplicate code.
Functional seem to have a more, fine gained ability to reuse then Object Oriented programming.
If you wanted to reuse a method is to subclass it. If the code is not reusable then simply create two methods with different implementation.
But suppose the code is 90% reusable, you cannot simply reuse it so you are forced to create two different implementations in the subclasses.
With functional programming, you just make two of those functions into one, using case statements in the places where the code is different.
The Java String class has many methods for manipulating strings. But wouldn't it be great if String class was a simple data type and you just used only the methods you needed. The resequence of this would be. Less bloated code, no accidental use of methods unrelated to the task at hand, because simple string data types have no methods.
As you can see The length() object is reusable. Since the two object implementations are a little different, some case statements in the length functions implemention would be required. The more classes use this functions for more the better reuse.
Having a length method in every class will only create duplications in code.
for larger methods should share some of its functionality with others
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
I don't like to have large methods. If a method is larger than a handfull of lines of code, I tend to split it into smaller methods, of which I often move some to other (more generic and therefore more reusable) classes.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
Ok, I've got some great functional language and I'm working on bank accounts. I've got some functions like readAccount() from database, writeAccount(account) back to database, debitAccount(account, amount), generateStatement(account), on and on. Good functional programming.
One day I notice that the account record is referenced all over my system. When I change the account structure I have to change some modules, recompile, test and deploy a larger number of modules. I see a neat opportunity to gather all the account functions together in an account module. Now anybody who wants to do something with account can call the account module. Better functional programming!
But my peers (and maybe myself) don't all remember to do that. They start writing new methods that work on account in other modules. One of them corrupts the account record and costs me a weekend of fixing up the database. I see a neat opportunity to "hide" the account structure behind my code so nobody else can mess it up.
I move the account record off the stack onto the heap. Now it's not a parameter any more, it's something in memory. Now the read method doesn't return an account. I keep a secret pointer to account on the heap. I return a pointer to a copy of my module that knows the secret location. When you call a function on the copy, it uses the account that it points to.
Whoa, I just invented objects! And the Beatles are on the radio because it's 1967.
What is OO but even better functional programming! Ed Yourdon called it "structured structured" programming with only a slight wink. (If you don't know Ed Yourdon, don't talk about functional programming any more.)
What might be those restrictions that OOP imposes on a methodology?Originally posted by Gerald Davis:
When my applications goes open-source, I will have a set of 10 commandments for how to work on my application; my own custom methodology, I think there is something about custom methodology in XP-programming concepts. I believe this approach would be more flexible then the restriction oop impose.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
What might be those restrictions that OOP imposes on a methodology?
Originally posted by Gerald Davis:
Obsessive use of data hiding and the ownership of data by one object; not only is this restrictive but it compromises code reuse.
Ah. That's what they all sayOriginally posted by Gerald Davis:
My customer methodology will make sure that everybody does the correct thing.
Originally posted by Gerald Davis:
I will also implement data-access-lists as a more flexible way of data hiding. Table Oriented Programming might be an option.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
quote riginally posted by Gerald Davis:
My customer methodology will make sure that everybody does the correct thing.
Ah. That's what they all say
I have to say I'm very suspicious about the "will make sure" part... Could you share with us how you're planning on accomplishing that?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Gerald Davis:
Table Oriented Programming might be an option.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Lasse Koskela:
Umm. Could you elaborate on the data-access-list part?
Originally posted by Lasse Koskela:
I thought you were talking about data hiding. How does that prevent code reuse? If you want to share data, would it be an option to share the object holding the data instead?
Lasse:
Umm. Could you elaborate on the data-access-list part?
Gerrald:
The idea behind that is, I could prevent curtain module or functions from accessing the data by keeping a record of them in a list. If it�s in the list it cannot come in.
I don�t know how I could possibly implement something like it
Suppose you have data in a class called Customer but somewhere else in the project customer data is used in a different context or as a part of a sql like query, things could get complicate especially if the design changes.
Don't mess with me you fool! I'm cooking with gas! Here, read this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|