SCJP, SCJD,SCWCD,SCDJWS,SCEA 5 MCP-C#, MCP-ASP.NET - http://www.khaledinho.com/
Life is the biggest school
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 Khaled Mahmoud:
In my opinion only the methods that belong to the same object should access the object private data and that case B some how is considered a violation of the object oriented principles.
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
SCJP, SCJD,SCWCD,SCDJWS,SCEA 5 MCP-C#, MCP-ASP.NET - http://www.khaledinho.com/
Life is the biggest school
Originally posted by Khaled Mahmoud:
Well, talking about Information hiding.Only the object alone, must be able to access its private data members.No other objects must do so.
I am not talking about specific advantages or disadvantages I am talking according to my common sense in Object Orientation.
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 Ricky Clarkson:
Ernest Friedman-Hill, you said: "you might not have considered that efficient copy and compare methods are difficult to write in languages with object-based encapsulation."
Why are they difficult to write?
Originally posted by Ricky Clarkson:
Why would one object need to get access to the non-interface portions of another?
Originally posted by Ricky Clarkson:
Ilja, if you had a modular system that didn't depend on objects, such as Pascal's 'interface' and 'implementation' sections, do you think you'd still use objects to achieve the same thing?
It seems to me that you're (ab?)using classes as both namespaces and containers that facilitate polymorphism. Fine, you have no choice in Java, but it's worth recognising that it might not be the ideal.
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
Arguments about what models the real world most closely don't move me. Preventing the objects of a class from accessing each other's data does not simplify my code, reduce coupling, or ease maintainence in any way
I'm not sure I understand the question. If you are asking whether I'd want to make use of polymorphism, then the answer is yes.
Originally posted by Ricky Clarkson:
Ok. You said: "OO is not about common sense, nor about academical pureness etc. To me, it simply is a tool to manage dependencies in source code."
To me, that means that OO is a module system to you.
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
The point of OO is that polymorphism allows us to inverse dependencies by introducing abstractions. My code doesn't depend on the database driver of a specific vendor - they both depend on JDBC.
Originally posted by Ricky Clarkson:
That's exactly the same as coding to the interface portion in a non-OO module system, such as Pascal, and the same code being able to work with multiple implementations. That's not about objects.
Objects do, however, provide a convenient way of being able to cope with more than one implementation at a time.
There is another way:
That's an interesting way of allowing one codebase to be called, by one program, and use more than one implementation of some library. It makes Java DI solutions look like the overkill that they are.
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
If OO were purely about objects, we wouldn't need to distinguish it from object *based* languages.
There are an endless number of ways. So what?
There still is something about the Strategy design pattern that is missing from this discussion: a Strategy can consist of more than one method/function.
But it's not as easy as saying "design patterns are always a hint that the language is missing something".
I'm never sure what the point is in these discussions. Different languages have different features. I'm happy enough to just use what's there most of the time. If someone describes something in language x that will help me write better Java, I'll take the time to study up. If it's just how x is different, not of much interest today.
Originally posted by Stan James:
I'm never sure what the point is in these discussions. Different languages have different features. I'm happy enough to just use what's there most of the time. If someone describes something in language x that will help me write better Java, I'll take the time to study up. If it's just how x is different, not of much interest today.
...
What was the disagreement about?
Lisp is often considered an esoteric AI language. Our results suggest that it might be worthwhile to revisit this view. Lisp provides nearly all of the advantages that make Java attractive, including automatic memory management, dynamic object-oriented programming, and portability. Our results suggest that Lisp is superior to Java and comparable to C++ in runtime, and it is superior to both in programming effort and variability of results. This last item is particularly significant because it translates directly into reduced risk for software development.
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
Well, if all this was a disguised invitation to learn Lisp, I guess I'm passing. At this point in my life I will probably take up a new programming language only if paid to. I don't do enough extra-curricular coding to make it worth using the next most wonderful thing since sliced CPU time
Originally posted by Stan James:
So what's been the value of all this to a Java guy? They do it better in Lisp, functional languages kick butt, and ...
Originally posted by Ricky Clarkson:
I am only making the point that design patterns are just a halfway point until you have a reusable solution that you can reference, rather than repeat.
It may still be worth skimming since several posts show some insight into Lisp's real problem, namely that the patterns required for Lisp's effective use are slow to spread outside pocket communities and that people within those communities are so used to this problem that they discount any pattern originating outside these pockets. -- Ward Cunningham
So what you're telling us is that you will not pick the best tool for the job, on the grounds that your life/career is nearly over?
Stan, I assumed that people who spend some of their time talking on JavaRanch actually are interested in programming.
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
For the longest time this was a major drawback of the Java-centric environment - it was all about Java.
The sad truth is that a significant portion of people who are paid to write code for a living can't be bothered to apply the DRY principle.
So raising awareness about design patterns (when to use them, when to ignore them, how to communicate with them) in the entire community is not as simple as any particular individual learning about them.
They simply stick with what they are more comfortable with and never deepen their SQL skills beyond the very basics.
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:
I'm less interested in design patterns than the principles that led to them. Patterns are good to know when your problem fits one of them, but day to day coding without the basics will eternally suck.
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 Peer Reynders:
Granted, I think it would improve many IT oriented curricula if they included a functional programming course simply to ensure that the student can deal with concepts outside of the imperative programming paradigm.
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 Ricky Clarkson:
Stan, I assumed that people who spend some of their time talking on JavaRanch actually are interested in 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 Ricky Clarkson:
I am only making the point that design patterns are just a halfway point until you have a reusable solution that you can reference, rather than repeat.
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 Peer Reynders:
I'm surprised there hasn�t been more talk about functional programming in the agile quarter. They focused on making the process and the people more productive - I figured that they would be turning their attention to tools and languages at some point of time.
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 Ricky Clarkson:
quote:
--------------------------------------------------------------------------------
If OO were purely about objects, we wouldn't need to distinguish it from object *based* languages.
--------------------------------------------------------------------------------
That distinction is fairly arbitrary. OO doesn't actually depend on classes, it just turns out that classes are quite convenient.
In the words of Alan Kay:
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
The tone of "So what?" is quite harsh in English. If I have offended you, it is not on purpose. It might be a tone gained by accident in translation (from German?).
quote:
--------------------------------------------------------------------------------
There still is something about the Strategy design pattern that is missing from this discussion: a Strategy can consist of more than one method/function.
--------------------------------------------------------------------------------
One way of doing that with the generic methods approach is to make the method return an object that has references to two functions.
Or you could just implement a one-method strategy twice.
I've yet to come across a design pattern worthy of its name.
what I mean is that, with the right refactoring and programming language, design patterns get reduced into a single method/function quite often, or get replaced by a language feature, such as Scala's inbuilt singleton support (you can declare a global object - it is a singleton still, but it's so trivial to use that it's not even worth calling it a singleton - it's a global object).
Still, I think Lisp's special variables are a better replacement for singletons, and they predate the term 'singleton' as used today.
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:
Somehow that doesn't sit well with me, but I can't say quite why. If people want to, they can grow and learn quite a lot in Java.
Originally posted by Peer Reynders:
Sometimes confusion arises because some people fail to disambiguate between idioms, which are closer to the implementation and often specific to a programming language (or a family of programming languages), and design patterns which are supposed to be more abstract.
However it seems that Peter Norvig claims that he can eliminate the need for 16 of the 23 GoF patterns in Lisp or Dylan
which would effectively relegate them to idioms for imperative languages
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 Stan James:
Or maybe some language has reached the place where every line of code sings of the business domain. I'd much rather write and read code about insurance and call centers than http sessions and strategy factories. I strive to improve that business to noise ratio, but it's never all that great.
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 Peer Reynders:
If you can simply pass in functions (or closures) as objects then what is the big deal with the Strategy pattern?
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