Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I many times saw terms binding, glue, and wrapper in a similar context and meaning(if we are talking about some "adapter code"). So what exactly means each of these terms? Is it a synonyms? Or what is the difference?
binding, wrapper and glue are - in this context specifically - are all sort of synonyms of each other and can sort of be used interchangeably..
bind, wrap and glue are all verbs which mean they're a word to describe an action, state or occurrence; even more-so they all revolve contextually around attachment. So yes - they are synonyms as far as the english language is concerned. However, concerning programming and the written paradigms used to describe ones actions within it may become more 'grey'.
Let us use an example. Directx and c#:
binding by definition is to "tie or fasten" something to something else, as is glue and to a lesser (but still valid) extent wrap. Which makes sense in this example as dx is is written and designed for c++, but there are libraries that wrap the c++ code providing a useable library for c# programmers to use; inside which, the code binds or glues the original c++ code to the c# equivalent - and vice versa - allowing these two (originally incompatible) sources to communicate.
So in using the c# alternative allows us access to the - if fully featured - functionality of the original c++ version.
So when talking about a wrapper one can refer to the base as binding or glue code. However - in my opinion - wrapper is a much broader term contextually, of which contains the actions of binding and 'gluing'.
This is my understanding - if somebody believes me mistaken, please don't hesitate to correct me.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I’m learning Java and have recently started my first project. The idea of this project is to pass one input argument - path to file/folder, which would be analyzed in order to find all files with predefined extension, parse them and create objects based on the results of parsing to store for future.
So far I’ve written all the code and my project structure (simplified) looks like that:
Class defining resulting object
Class that analyzes the input parameter (exists, is file, is folder) and processes it, returning list of all suitable files
Class that parses suitable files and creates objects
The question is - am I following OOP with that structure?
From what I’ve read on the web the last two classes seem to look like polterheists. But I don’t think that it is a good idea to move the logic of the third class to the object class because it consists of lots of methods (define current section of the file, strategy to parse each separate section).
I am learning on my own and don’t want to start my journey by cultivating bad habits.
I am learning on my own and don’t want to start my journey by cultivating bad habits.
You're saying this like you have a choice :)
From what you described it seems reasonable, of course w/o seeing the code we can't say. And even if you show the code - 100 people will have 100 opinions, there's a lot of debates around OOP.
What's important is not to look at your design as something static. Once your app starts to be more complicated you'll have to re-work some of it.
PS: stackoverflow doesn't like this kind of questions since everyone will have an opinion. You'll have to find other resources if you keep having such questions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm fairly new to Java but love it so far. My question is, i'm a little unfamiliar with Classes. I know what they are, and generally how to work with them as I'm not brand new to programming, but I would like a professionals opinion.
I'm currently writing a small multi threading program to launch parallel power shell sessions by spawning cmdlines for target machines in a csv, capture the output and write to a csv.
Should I put everything into one class and breakup the logical operations to methods within the class and string them together? Or should I make a Thread executor class, cmdline powershell class, a csv operations class, etc (My thought behind that was to allow code reuse, but that'll be kindove time consuming and in my mind impractical since i'd have to specify the datatypes and return types for new situations in the future).
Any help would be appreciated!
There is no "way" so to speak,
It's all your preference.
But just don't cram everything into one class.
Generally, you want to be as neat as possible.
In the future, you will thank yourself for using different classes.
If your project grows, and a bug is born, you don't want to be looking through one very long class, but instead simple broken up pieces.
Let's say you have these classes:
GPS,
Main,
Search
And someone reports a bug with the GPS not working.
Instead of looking everywhere saying, where did I put the GPS code,
it's right in front of your eyes!
I've went to everyones links and found the info very helpful. So far I've come up with this.
Make a package that contains classes that perform a specific set of tasks (also don't make utility kits that are very general). The package in my case would be called com.jt.threads.powershell or something.
Keep classes small and breakup the program by conceptual types. (ie. data reading and writing operations on a filesystem should be in one class with the focus on helping the package perform a certain task or range of tasks.)
Methods within classes should focus on getting, setting, changing the objects attributes or adding logic.
The program entry point should join it all together, except in the case of large applications, in which case an interface should be used (still learning about them).
With true OOP, i don't think it's a good idea to create code for reuse, unless it's supporting a range of very very very similar tasks (that way if I have to change something, it won't break other classes outside of the package).
Thank you all! I feel a lot better knowing that I'm on the right track. I was worried that by NOT making code reusable in a lot of situations that I was doing something wrong. I started programming in Python 6 months ago for my job, but I totally ignored classes and I want to have good programming habits and apply OOP as best I can going forward! Python is definitely convenient and a great starter language, but I wish I learnt Java first so I can get a solid grasp on OOP.
There is no “The way” to organize or group classes. Anything goes as long as it works as expected and you understand what you write.
As a Programmer you only need to,
1. Know and understand what you write.
2. Know and understand what other Programmer as written.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I noticed that C++ and Java seem to have many features in common in terms of syntax, although I would assume them to be fairly different languages. For example, both languages support casting and define functions by specifying the return type and then the name of the function. The for loops also seem very similar. Also, they both use curly braces for a variety of statements and structures.
Is there a reason for this? Did Java and C++ have some common predecessor, or was the syntax of one based on the other, for example? Or am I just reading too much into this?
Java is just a member of the family of C-style languages (i.e. the languages syntactically based on C Programming Language). The family includes languages like
C++, Java, JavaScript, PHP, Perl
which were very popular, for example, in 1990-s and the beginning of 2000-s.
Today's popularity of
Python, Ruby, Rust, Kotlin, Swift and others.
slightly moved the focus away from C-style languages. One of the reasons to move away from C-style is that C has context-dependent grammar and the new languages tend to have almost context-independent grammar, which makes its parsing easier and more predictable.
Anyone designing a new language would have nothing to gain by using different syntax for the same operations. So if the potential users of the language are, for example, used to "a++" being a variable "a" whose value increments but returns the existing value of a, or they're used to braces being what delimits a block of code, there's no reason for a new language not to use those same things. If this new language did switch these things, up, they risk potentially confusing and discouraging people from using it.
This extend not just to Java and C++, but some other languages as well. For example, JavaScript and Perl use many of the same syntax features that Java and C++ do.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Most of the people says that abstraction is hiding something and showing only functionality to the user. Can anyone explain me what are all the things you are hiding and what are all the things you are showing?? please don't explain with the examples of animal, engine, vehicle.
I think this is a case where a concrete example would help a lot.
HashMap has an internal structure for handling hash collisions, which is an implementation of a singly-linked list. Now, do you know how that internal structure works, what it's called, what its fields are called, etc? More importantly, do you care, so long as the HashMap "just works"?
If the answer to both of those is "no" — which is what it should be for anything other than curiosity/learning purposes — then those details have been hidden from you and exposed via the abstraction of Map's interface.
The result is a class that's easier for you to reason about (because you have less to learn), and easier for the library maintainers to maintain (because they don't need to worry about a change they make breaking your code, so long as they still abide by the interface).
Abstraction is an overloaded term.
Abstraction, in object oriented languages, basically means leaving away unnecessary details when modeling real world objects. You could also think of it as a simplifying process.
Abstraction, in computer science as a whole, also means hiding complexity by providing some sort of simpler interface. Your question seems to aim at "data abstraction" which means hiding the exact way data is represented with an abstraction layer. This could be e.g. the Number data type in databases. You just know it is a number, but not how it is stored on disk.
Abstraction sometimes is used equivalently to encapsulation, too.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
i have been reading about this topic , and the more i read the more confused i get ,
can somebody please elaborate , we were using language C which follows structural approach ,
so what was wrong with this approach , that we moved to create a object oriented language JAVA .
I have been reading so many theoretical aspects , can some body please give more of a few practical illustrations ,
WHY WE NEEDED OBJECT ORIENTED APPROACH IN THE FIRST PLACE
I am not looking for an answer to be given in any interview or tutorial
I am looking for an answer to get the better understanding/practical importance of object oriented aproach
There are many explanations regarding this. But I would like to refer this
Modularity: The source code for a class can be written and maintained independently of the source code for other classes. Once
created, an object can be easily passed around inside the system.
Information-hiding: By interacting only with an object's methods, the details of its internal implementation remain hidden from
the outside world.
Code re-use: If a class already exists, you can use objects from that class in your program. This allows programmers to
implement/test/debug complex, task-specific objects, which you can
then use in your own code.
Easy Debugging: If a particular object turns out to be a problem, you can simply remove it from your application and plug in a
different object as its replacement. This is analogous to fixing
mechanical problems in the real world. If a bolt breaks, you replace
it, not the entire machine.