• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OOP is POO the functions are comming

 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While I was reading some ant-oop material it mentioned about most books on object orientation design being about GUI or various small scale thing , and there not being much on object oriented business modelling.

Don't take me as a madman but object orientated technology is mostly a myth. I used to be a VB hating Object Oriented Purist. I would not listen to those older and wiser them myself ,until experienced developer talked about design patterns.Then it occurred to me that he has been to the land of oop and did not like it.

He went on to tall me that Object Oriented Design is to a functional developer, as EJB is to an Object Oriented developer. I don't know how things have change since I used EJB but I found it hard to set up, very slow and has a high learning carve. Even though I don't stay up to date with IT like I used to, I am almost certain that EJB has not caught on, and Java seem to in much the same situation as George W Bush is in today; most support him but there are plenty of anti's out there.

Check this out http://www.geocities.com/tablizer/meyer1.htm
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Great topic, but unfortunately not apt for this forum. We have a dedicated "OO, Patterns, UML and Refactoring" forum and I am moving this thread there.
 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Try reading Domain Driven Design by Eric Evans. It addresses the exact issue that you have mentioned - use of OOP for Business Modelling. It's one of the best books I have read on the subject so far.

There are also other initiatives like Analysis Patterns by Martin Fowler, which try to emphasize on reusable business models.

The advantage/disadvantage with OOP is that it has been used and abused a lot. As a result, there are a lot of folks out there who think that they know OOP because they work in Java or some other OO language without understanding the fundamental concepts.

With an ever-demanding market, I don't see how this can change anytime soon. Managers rarely care if the programmers know OO. They are worried more about deliverables and good programmers.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the link. When I pick up doing the architect certificate, I will check out this book. But I will be looking at Structured Design also. The thing I don't like about Object Oriented Design is I am forever shifting around objects and responsibility in Class Diagram.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Well, don't do that. You could use CRC cards instead, for example, until the design stabilizes.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The acceptance of OO concepts is pretty hard to dispute. We don't see C and COBOL and Pascal as growing languages any more. I'd hardly call it a myth.

I make a point not to say bad things about COBOL and procedural languages. (Ok, I say bad things about C.) Functional decomposition is a powerful way to organize code and perfectly appropriate to some problems. I still wish I could do certain data manipulations and case statements as easily in Java as I did in COBOL.

The article you linked has some pretty typical first-reactions to OO languages and tools. I had the same kind of reaction moving from COBOL to Pascal but I got over it when I got more fluent. Sometimes that's due to a bad introduction. I took a couple OO classes from people who never should have been allowed in front of a classroom. Others who hadn't been exposed to OO walked away in disgust.

I have to say I didn't have a bad reaction moving to OO, though. Borland took Pascal from procedural to OO with about 3 new keywords and it made great sense. Smalltalk is a thing of amazing beauty ... once you learn to program standing on your head.

I won't argue that building UI in VB or FoxPro or PowerBuilder and putting some code snippets in the events isn't easier than building Swing. Getting a Swing UI to look right is fairly well beyond me. But I totally endorse the kind of separation of concerns I get from a good MVC design.

Feel free to bring up some particulars of OO vs procedural and we can talk about our experiences, whether or not we found OO a better approch.
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That article seems old: 2002. Some things don't make sense when you consider Web Services or MOM.

I also wouldn't talk about OOD and EJB in the same breath. EJB bends some OO rules that most people take for granted now (like requiring inheritance to get services). Try reading some of Rod Johnson's J2EE books if you want better commentary on OOD as it pertains to J2EE -- I think he's pretty good.

I have no problems with procedural programming. I use Perl to do it these days. In the past I used C a lot for developing game code. Then I jumped into C++ briefly before landing in Delphi, where I was a contributor to GLScene (www.glscene.org). After working with that graphics library for 2 years in OO, I don't think I could have gone back to C. There was just too much I took for granted with OO -- in a good way.

So, today I use Java and Perl. Honestly, I don't find a lot of the business logic I work on to be simplistic. It could be the nature of the work I do (mostly custom solutions), but I enjoy the OO benefits in Java as much as I did when I was using Delphi for 3D graphics. When I think back on it, OO never seemed like a PITA to learn because I could see a use for it. Maybe that's the line in the sand for a lot of people. I do know a lot of procedural programmers that don't see the use for OO. John Carmack is a good example: he didn't switch to C++ til when, Q3?
 
Ranch Hand
Posts: 776
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
... We don't see C and COBOL and Pascal as growing languages any more. ...



I'll just point out that modern IBM mainframe COBOL has OO syntactical constructs: class declaration, implementation, inheritance, ........

Guy
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Choosing methodologys are much like choosing a car. I love the BMW's 5 series I bought one secondhand. They are fast , very reliable, trendy and cheap. But they are envolved in many road accidents, it even reflects in the fact the ensurance premiums are so high with this car. many users also abuse their car so it make the car seem reliable too .so at first glance it must be a bad buy one.

But but the real reason why there are so many accidents is because of recklass driver boy races. Over here in England the BMW considered a poor mans sparts car after all. But I am not a reclass man ,I am respansible on the road. So for me the BMW is an ideal choice, especially to the fact that I know what to look for in a second hand car.

Functional programming has the same bad reputation as the BMW 5 series. It is has been used by bad programmers, and rastricted languages like C and Pascal. Good oop is always compared to bad Funtional programming.


Supose you want to map an corperate hierarchy for a business, the boss would be at the top and supervisers in the middle and blue coller at the bottom ,ja. You would map this into Object Modal wouldn't you. But this is only one view of the modal. For example: god sees all men as equals so this modal would be incorrect wouldn't it, oop modals are too inflexable

I have to go to work now, my boss is calling me! but when I come back I will show you an axample of good functiona program compared to oop.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Relation modal is more flexable, because you can use queries. to get different aspects of the system.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Guy Allard:

I'll just point out that modern IBM mainframe COBOL has OO syntactical constructs: class declaration, implementation, inheritance, ........

Guy


I browsed a manual on OO COBOL after I left the mainframe world but never tried it. It was not a syntax I'd choose to use.

I got very happy with COBOL II towards the end of my mainframe time in the 90s ... nested programs, evaluate, mixed case, end-keywords, fewer required sections, many restrictions lifted in CICS, lots of big improvements in a short time.

One way I judge languages and programs is how many lines sing to me of the business at hand, and how many drag me through mundane housekeeping. CICS COBOL ranks very well on this scale once you're into the procedure division, partly because the supporting frameworks are so rich and solid. OO COBOL had too many lines of housekeeping for me. Java can be done well, or it can have 20 lines of logging and try-catch for every line of useful business code.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
[QB]Good oop is always compared to bad Funtional programming.
QB]



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.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



OOP and functional can live happly together complementing each other. Like the way VB uses the object oriented C++ librarys for things like GUI and file access. VB is used as a glue code to connect the librarys together.

I am doing much the same thing with Python and wxWindow that is implemented in c++. Even though I am using object oriented librarys ,I am using python in a functional way. I don't see how I will became a victim of bad design. My applications is damn fast too because wxWindows does most of the hardwork for me; so easy I feel like that I'm cheating.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
Relation modal is more flexable, because you can use queries. to get different aspects of the system.



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.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The thing I don't like about object oriented technology is it seems to encourage the inflexible tree structures.



That sounds like some aspect of a design that you've already identified as having problems. Learning to do good OO designs that keep you out of trouble instead of getting you into trouble takes a while.

I'm gonna take a guess ... did your example have something like an Employee class and Supervisor extends Employee to add some features, and Manager extends Supervisor to add some features? It's a very common horror to confuse what a person (or object) DOES with what it IS. A single Person class with pluggable behavior or configured permissions would work a lot better. Google for Strategy and State patterns for some examples of changing behavior, say when promoted from Supervisor to Manager, without touching the Person class.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



Yes, of course. I didn't want to imply that SQL or whatever query language you use is a bad thing.


I don't get your angle on this. do you have any links or could you explain better.



There is a risk coming with having your code coupled tightly to the relational structure of your data. Requirements change - for example business might want to do more with the data, probably even adding some kind of data to the mix. Often the existing structure isn't optimal for the new requirements - a database refactoring would be beneficial. If too much of your code depends on the database structure, you can't change the structure cost effectively - all you can do is build around it, the structure begins to degrade.

Hardcoding queries into your code is a way to very tightly couple your code to the database structure - when you change the structure, your queries won't work any longer.

The thing I don't like about object oriented technology is it seems to encourage the inflexible tree structures.



That's like saying hammers encourage to smash things...

OO technology doesn't encourage anything. It gives you tools that can be used for the good and for the bad.


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.



That would a quite naive approach, and certainly nothing I'd like to encourage.

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.



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!
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!



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.
All Data are group together, this way I can think better how to serve them without without the distraction of functionality, much the same way as SQL. They are global variables but their numbers are few, there is not a single global veritable that doesn't give meaning to the applications logic. Plus very few of my functions access them directly.
I have more freedom to move functions to other modules more easily
Thinking less about OOP complications and more about glueing library and functionality together and leave the OOP to the library developers.

I am dying to know what kind of way I might become a victim of functional programming. Will it be name-space clash or will it be ugly dependencies that make my applications hard to change.
I know that readability will never suffer, there will never be a single nested loop in my applications case statements will never rune out of control and assertions will be uses frequently.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
Thanks dude , I really appreciate the your time.



You're welcome - this is an interesting discussion.

I have to say something about object oriented code reuse, to put it simply functions are smaller reusable components then class especially



I'm a fan of small classes - classes that only contain a handfull of methods, that simply are reused together. If there is a method that can be reused in a different context, it simply belongs on a different class.

In fact, it isn't totally unusual to have classes with only one method - take a look at the Command pattern, for example.

to the fact that they are not hard-grafted to data.



I don't follow you here. Certainly operations depend on the structure of the data they work on, regardless of what programming paradigm you use?


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.



Can you give an example of such a reusable function that you think would be harder to reuse if you used OO?


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 don't see at all how classes get in the way of grouping functions. Could you please elaborate?

I am dying to know what kind of way I might become a victim of functional programming.



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.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



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. This results in awkward handling of the way subclasses are overridden, split up, moved, and named. I find that procedural approaches to be more "boundary friendly" in this regard.

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. With functional I just use only those function instead of bringing in the whole objects. 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.

Another example:
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.

Object oriented
>> String a=�String�
>> print a.length()
6

>>Functional
>>String a = �string�
>>print length(a)
6

>>set s=(2,3,3,4,4,)
>>print length(s)
5

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.

To summerise: Reuse can be class level, function or method level or case statement level. The length() method is very small, so leaving it as method is ok, but for larger methods should share some of its functionality with others

I'm loving it.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
OO tends to group operations around nouns while functional programming tends to group around tasks



Did you notice that a task is a noun, too?

If you are talking about finding nouns in the requirements documents and making those classes, that's a quite naive approach from the early days of OO modeling. It's sad that it's still taught at so many places...

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.



Than you have a bad OO model. The basic principles of OO design clearly state that you should put things together that change for the same reason (Single Choice Principle) and don't put things together that change for different reasons (Single Responsibility Principle).

And you will find many articles out there favoring composition over inheritance. Overusing subclassing is a typical beginner error.

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.



There is no "OO way" of doing that - OO just gives you tools like polymorphism, encaspsulation and inheritance, how you use them is up to you. And actually I'd say your problem statement is way to vague to decide what a good design would look like.

You are right, though, that often it is a good idea to decouple parsing from persistence. The reason is that both change for different reasons. If the way persistence works needs to be changed, you don't want to even have to think about parsing.

I would be forced to use the whole Parsing and Persistence class just to use those two methods.



If that proves to be too inconvenient, change the design.

Also I can put these functions next to each other, to make it easier to spot duplicate code.



I'd actually expect more potential for duplication between several methods of parsing and several methods of persistence.

Functional seem to have a more, fine gained ability to reuse then Object Oriented programming.



Then your classes are probably too big.

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.



That certainly sounds awfull. If you could show us such an example, I'm sure we could come up with a better OO solution.

With functional programming, you just make two of those functions into one, using case statements in the places where the code is different.



The problem with this is that every time you find another such difference, you need to touch that case statements again. This adds much risk, as it violates the Open Closed Principle (which says that ideally you should be able to add functionality by just adding code, without touching existing code).

A better solution probably would be to use some form of polymorphism, for example the Template Method or the Strategy pattern. Again, if you'd care to show us such a function, I'd be more than willing to show the equivalent OO solution.

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.



Sorry, I don't follow you here. I don't see any code bloat in the String class, and I don't understand at all how you could accidentally use methods unrelated to the task at hand.

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.



And the more bloated and harder to maintain the function actually becomes.

Having a length method in every class will only create duplications in code.



What kind of duplication, and why couldn't I remove that by using OO techniques???

for larger methods should share some of its functionality with others



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.

To summarize: I wholeheartedly agree with you that duplication is bad and should be avoided wherever possible. Where I disagree with you, based on years of experience using OO languages, is that OO forces us to accept significant amounts of duplication. Quite to the contrary, the power that OO gives us to define abstractions allows us to remove duplication quite effectively.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, I will need read and think about what you have said before I reply.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.



What I mean by larger methods is methods with a lot of functionality it. I also create small helper methods for larger ones. Sometimes I reuse these helper methods in other parts of the class. Sometimes I reuse helper methods from other classes but that can be messy so I put a lot of them into a class called Functions so the whole applications can resue them.I like using static methods because you don�t have to initiate the whole class to use them. This is what got me into functional programming in the first place.

You are definitely a man after my own hart; good easy to manage code is what you believe. But I am not the best at explaining concepts clearly unless I spend lets of time on it. So I give you link on anti oop website http://www.geocities.com/tablizer/myths.htm .
If you are interested in system design concepts, it is a most interesting read. Tell me what you agree and don�t agree with it. All I know is, if there is a concept you don�t like, I will take head of your wornings.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.)
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are you sure you are talking about *functional* programming - such as programming in Lisp, Haskell etc.?

Remember, there is a *big* difference between those and *procedural* languages, like C, Pascal, Modula etc...
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right, in this thread 'functional' has often meant 'procedural with functions' not the proper definition of functional. I think. Anyhow, that's how I was abusing it.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.)



Well, that is a great way to explain how system requirements made it necessary to have objects. So when or if (and that's a big if) I created user defined object in my applications I will remember this post and why I am doing it.
So let me summarize:
1. Functions that relate to data
2. The grouping of related functions
3. Data hiding
4. A pointer. Does the same job as a proxy pattern thingy.

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.

Do I know Ed Yourdon, I don't even know difference between function and procedual programming thanks to the success of oop. Your being hurrible to me
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

What might be those restrictions that OOP imposes on a methodology?

With regard to XP and custom methodology, yes, XP advocates that you should adapt the methodology/process to suit your specific situation and surroundings. It doesn't really say anything about creating a new process from scratch.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
What might be those restrictions that OOP imposes on a methodology?



Obsessive use of data hiding and the ownership of data by one object; not only is this restrictive but it compromises code reuse. My customer methodology will make sure that everybody does the correct thing. I will also implement data-access-lists as a more flexible way of data hiding. Table Oriented Programming might be an option.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


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?

Originally 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?

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.


Umm. Could you elaborate on the data-access-list part?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?



We have an incredible methodology here, but you can lean a horse to water, but you can't make him drink.

There are developers at all different levels, some understand the importance of following the created standards and following a methodology creates, but there are others that aren't completley familiar with the one the company they are working for uses, and therefore sometimes doesn't follow it, and it really occurs when you have a large project and many developers. Sometimes the schedule makes you have to use some developers on a different team within your project, that isn't familiar with your teams architecture, and do it their way. Yes they help you with saving time, but that code eventually will need to be refactored.

It's all part of our imperfect development world.

Mark
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I apologize to all for the wording of that Ed Yourdon remark. Bad rancher, bad!

I brought him up because he was widely known as one of the strongest proponents and leading innovators of structured procedural programming and when the OO light went on in his head, he strongly endorsed it as the next step in advancing the craft. I feel the better you understand structured stuff the more you appreciate OO.
[ November 17, 2004: Message edited by: Stan James ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerald Davis:
Table Oriented Programming might be an option.



Polymorphism basically is not much more than fancy syntax for jump tables!
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:

Umm. Could you elaborate on the data-access-list part?



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

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?



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.
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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



So Lasse figured out well the problem :-).


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.



I am not seing any problem here. Maybe you point it out.

./pope
 
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
reply
    Bookmark Topic Watch Topic
  • New Topic