C/C++ get {} set{}, δεν υποστηρίζει ?

[migf1]

Είναι σαν να λες, ναι μεν μπορώ να καρφώσω με το κατσαβίδι (κρατώντας το ανάποδα και χτυπώντας το καρφί με τη λαβή του κατσαβιδιου), αλλά αν είχα σφυρί θα το προτιμούσα...

 

Άλλοτε είναι σαν να θες να καρφώσεις με το κατσαβίδι ανάποδα, άλλοτε σαν να θες να καρφώσεις με το δάχτυλο, κι άλλοτε σαν να θες να καρφώσεις χτυπώντας το καρφί με την ανάποδη μιας καρφίτσας. Και εξαρτάται όχι μόνο από το εργαλείο που χρησιμοποιείς αλλά και από το πάχος του καρφιού, καθώς και την σκληρότητα του τοίχου.

 

Με άλλα λόγια, είναι τελείως άλλο πράγμα να προσμοιώσεις σε C απλά μια OOP κλάση με μερικές μεθόδους, άλλο να προσομοιώσεις και κληρονομικότητα, άλλο να προσομοιώσεις και πολλαπλή κληρονομικότητα, άλλο να προσομοιώσεις και encapsulation, και message mapping, και πολυμορφισμό και data abstractions, και, και...

 

Αν σου ζητήσει κάποιος για μια δουλειά και σου πει έχω αυτό εδώ πχ το διάγραμμα uml με κλάσεις αντικειμένων, σχέσεις μεταξύ τους κλπ κλπ, και θέλω να το υλοποιήσεις σε C τι θα του πεις;

- Όχι η C είναι procedural

ή

- ΟΚ, θα το κάνω αλλάτυπάρχουν δυσκολίες... Μήπως να χρησιμοποιούσαμε μια άλλη γλώσσα;

 

Αν λοιπόν σου ζητήσει κάποιος αυτό που λες τότε θα πρέπει να είσαι σε θέση να μπορείς να αξιολογήσεις το μέγεθος και το εύρος αυτού που σου ζητάει, καθώς και να είσαι σε θέση να μπορείς να αξιολογήσεις τα trade-offs μεταξύ του να το υλοποιήσεις με μια γλώσσα που δεν υποστηρίζει OOP και μια που υποστηρίζει.

 

Αν σου ζητάει λοιπόν ας πούμε το 80% αυτών που σου έγραψα παραπάνω και ξεκινήσεις με την πεπεοίθηση πως η C υποστηρίζει OOP, θα τελειώσεις κάνα-δυο-τρια χρονάκια αργότερα συγκριτικά με τον ανταγωνιστή σου που θα τον πείσει να το κάνουν με μια γλώσσα που υποστηρίζει OOP.

 

As simple as that!

[παπι]

nilos επιβεβαιωνεις το ποστ #44.

[nilosgr]

Migf1 συμφωνώ στο ότι είναι κακή (ίσως και κάκιστη ιδέα, ειδικά για μεγάλα/περίπλοκα/απαιτητικά projects) αλλά δεν παύει να είναι doable ;-)

 

Και η java πχ δεν έχει πολλαπλή κληρονομικότά αλλά βάζεις ένα inner class και κανείς τη δουλειά σου ;-)

[migf1]

Εγω παντως βλεπω οτι οταν ακουτε oo πατε απευθειας σε αυτο που προσφερει η c++.

 

Τί εννοείς πάπι; Η C++ δεν είναι αμιγώς OOP paradigm γλώσσα, είναι multi-paradigm... δηλαδή υποστηρίζει εγγενώς και oop και procedural kai generic και functional.

 

Εγώ πάντως βλέπω πως πολύς κόσμος στο νήμα μάλλον μπερδεύει το oop-paradigm με το structured-paradigm.

 

Migf1 συμφωνώ στο ότι είναι κακή (ίσως και κάκιστη ιδέα, ειδικά για μεγάλα/περίπλοκα/απαιτητικά projects) αλλά δεν παύει να είναι doable ;-)

 

Και η java πχ δεν έχει πολλαπλή κληρονομικότά αλλά βάζεις ένα inner class και κανείς τη δουλειά σου ;-)

 

Μα πότε ισχυρίστηκα πως δεν είναι do-able? Αντίθετα είπα πως έχω γράψει και εγώ oop interfaces αποκλειστικά σε C, καθώς επίσης έδωσα και γνωστά και επιτυχημένα παραδείγματα έτοιμων oop βιβλιοθηκών, γραμμένων αποκλειστικά σε C.

 

To "support" όμως είναι τελείως διαφορετική έννοια από το "doable". Εσείς λέτε εδώ και τόσες σελίδες πως η C υποστηρίζει εγγενώς oop, επειδή υποστηρίζει struct και pointers.

[defacer]

Από τη στιγμή που μιλάμε για γλώσσες προγραμματισμού που είναι όλες Turing-complete, τι έννοια έχει η λέξη "doable"? Ξέρουμε καμία γλώσσα προγραμματισμού στην οποία το ΟΟ δεν είναι "doable"?

 

Και αν δεν ξέρουμε καμία (στην οποία περίπτωση ο όρος doable αποσύρεται γιατί δεν έχει κανένα νόημα) τότε τι ακριβώς σημαίνει "support"? Ας πούμε τραβάμε κάπου μια γραμμή πριν από την οποία βρίσκονται όλα τα χαρακτηριστικά που αν δεν υποστηρίζεις δεν είσαι OO και μετά από αυτήν είναι τα "προαιρετικά"? (Εφόσον η C++ είναι εξίσου OO με τη Java, πάει να πει ότι τα interfaces είναι προαιρετικά μιας και η C++ δεν έχει. Και εφόσον η Java είναι εξίσου OO με τη C++ πάει να πει ότι η multiple inheritance είναι προαιρετική μιας και η Java δεν έχει -- κοκ).

 

Πού ακριβώς την τραβάμε αυτή τη γραμμή; Και ποιός ακριβώς το αποφασίζει αυτό; Αποφασίσαμε ότι interfaces και multiple inheritance δε χρειάζονται για να βαφτίζεται ο δούλος του θεού "supports OO". Virtual functions χρειάζονται; Γιατί; H keyword "class" χρειάζεται; Αυτή πάλι γιατί; (Hint: "επειδή έτσι λέω εγώ" δεν είναι ικανοποιητική απάντηση).

 

Αυτά και άλλα πολλά στο επόμενο επεισόδιο κατά το οποίο πολύς κόσμος στο νήμα θα μάθει πως το ΟΟ είναι ένα (not) και δε μπορεί ο καθένας να λέει το μακρύ του και το κοντό του.

[migf1]

Υποστηρίζω σημαίνει πως παρέχω διευκολύνσεις ή είμαι σχεδιασμενος εξαρχής (ή ακόμα κι αποκλειστικά) έτσι ώστε να προάγω την φιλοσοφία του paradigm ή των paradigms που υποστηρίζω.

 

Περιμένω ακόμα κάποια πηγή που να χαρακτηρίζει την C ως OOP-paradigm γλώσσα, έστω και έως partially supporting.

 

Επίσης, σε όποια σοβαρή συνέντευξη απαντήσεις θετικά σε ερώτηση "είναι η C oop-paradigm γλώσσα", έχεις φύγει σούμπιτος πριν καν ολοκληρώσεις το "ναι".

 

Και τέλος, όλες οι γλώσσες που υποστηρίζουν το oop-paradigm έχουν μια minimum κοινή βάση παροχής εγγενών,στανταρισμένων εργαλείων μέσω των οποίων υποστηρίζουν το oop-paradigm... η C απέχει κάτι έτη φωτός από αυτή τη μίνιμουμ βάση.

 

EDIT:

 

Α ναι, όταν αναπτύχθηκε η C υπήρχε oop!

[Timonkaipumpa]

Αυτό που λέει ο nilosgr.

 

Δεν νομίζω κανένας να πάει να γράψει OOP και να προτιμήσει C ή Assembly. Όμως, εάν χρειαστεί να το κάνει μπορεί.

 

Έτσι, μπορεί να μην παρέχει ευκολίες η C ή η Assembly όμως ΜΠΟΡΕΙ να κάνει κανείς OOP.

 

Οπότε, η λέξη "υποστηρίζει" δεν είναι η κατάλληλη για την σχέση της C με τον OOP.

 

 

Με την Prolog; Μπορεί να κάνει κανείς OOP (χωρίς το extension που βασίζεται σε Prolog αλλά δεν είναι "καθαρή" prolog); Εδώ νομίζω ότι η λέξη "υποστηρίζει" κολλάει περισσότερο.

[migf1]

Δεν θα με τρελανετε εσείς ρε μάγκες!

 

Σοβαρά τώρα, έχετε επαφή με το αντικείμενο, εννοώ το έχετε διδαχτεί ή απλώς γράφετε για χαβαλέ να περνάει η ώρα. Αν είναι το 2ο πείτε τουλάχιστον να μην τρελαίνομαι τσαμπα και βερεσέ

 

http://web.cs.mun.ca...html#PSWDecompo

«A language is said to support a style of programming [aka paradigm] if it provides facilities that makes[!] it convenient (reasonably easy, safe, and efficient) to use that style. A language does not support a technique if it takes exceptional effort or exceptional skill to write such programs; it merely enables the technique to be used. For example, you can write structured programs in Fortran, write type-secure programs in C, and use data abstraction in Modula-2, but it is unnecessarily hard to do because these languages do not support those techniques.

Support for a paradigm comes not only in the obvious form of language facilities that allow direct use of the paradigm, but also in the more subtle form of compile-time and/or run-time checks agains unintended deviation from the paradigm. ... Extra-linguistic facilities such as standard libraries and programming environments can also provide significant support for paradigms.»

...

Decomposition around Hidden Data «Over the years, the emphasis in the design of programs has shifted away from the design of procedures towards the organization of data» [WIOOP]. There are several paradigms for decomposing systems into units in which some data is hidden from the rest of the system.

1. Data Hiding (c.f. Object Abstraction) ``This paradigm is also known as the "data hiding principle"'' [WIOOP]: «[P]artition the program so that data is hidden in modules,» [WIOOP]; each module offers to the outside procedures, and variables. Supported by the module construct in the language [WIOOP].
   
   • Data [Type] Abstraction (see also below): «Programming with modules leads to the centralization of all data of a type under the control of a type manager module» [WIOOP]. Modules are not enough as a language support: «A type created through a module mechanism is in most important aspects different from a built-in type and enjoys support inferior to the support provided for built-in types. ... In other words, the module concept that supports the data hiding paradigm enables [data abstraction], but does not support it» [WIOOP, 5].
     
     • Object-Oriented Decomposition (see also object abstractions): «Rather than writing procedures that manipulate data structures, operations and data are viewed as an organic whole, a unit that provides a service ... used by other portions of a software system. This view can be succinctly summed by a twist on a well-known quotation: "Ask not what you can do to your data structures, but ask what your data structures can do for you."» [Leda, p 12]. In object-oriented design: «object-oriented decomposition: The process of breaking a system into parts, each of which represents some class or object from the problem domain. The application of object-oriented design methods leads to an object-oriented decomposition, in which we view the world as a collection of objects that cooperate with one another to achieve some desired functionality» [booch, 1991, p 516, quoted from [Quib: glossary: funktionale Dekomposition]]. In the program this designed decomposition is then expressed in terms of class definitions which comprise method definitions, and which are related in an inheritance (subclass/subtype) hierarchy.
       
     • 
       
     • Minimal feature set: «A minimal list of features that should be supported in any object-oriented programming language includes:
       
       • Objects, consisting of both state and operations.
          
         
       • Classes, to generate objects (though delegation would be a reasonable alternative).
          
         
       • Mesage sending, as a way of specifying computation.
          
         
       • Instance variables, representing state.
          
         
       • Subclasses, to support reuse of the instance variables and methods of an existing class in definining a new class.
          
         
       • Subtypes, depending only of object interfaces, to provide a mechanism for programmers to use and object of one type in a context which expects one of a different but related type.
          
         
       • Keywords, self and super, representing the resevier of a message and its superclass, respectively.» [K Bruce et.al.: PolyTOIL: A type-safe polymorphic object-oriented language; extended abstract in ECOOP'95]
         

...

[Timonkaipumpa]

Να ρωτήσω κάτι..

 

Εάν μία γλώσσα σου δίνει τα εργαλεία να "σπάσεις" τους specifiers private και public, είναι ΟΟΡ ή όχι;

 

Δηλαδή, εάν καταργεί το private και public, ενώ τα έχει και τα χρησιμοποιεί όμως (και όχι όπως είναι η python), είναι ΟΟΡ ή όχι;

[migf1]

Timon, νομίζω δεν χρειάζεται να παίξουμε άλλο με τις λέξεις (θα μας πάρουν με τις ντομάτες)... εδώ δεν μπορούμε να συννενοηθούμε (στο νήμα εννοώ, όχι εμείς οι 2) στι τι σημαίνει "η γλώσσα τάδε υποστηρίζει το τάδε paradigm", που είναι αυτονόητο για όποιον έχει έστω κι ελάχιστη επαφή.

 

Που να πηγαίνουμε τώρα παρακάτω

[Timonkaipumpa]

Μα...

 

Εάν η απάντηση στην ερώτησή μου είναι όχι, τότε δεν είναι η C# OOΡ.

 

Εάν είναι ναι, τότε εφόσον η C# σου δίνει την δυνατότητα να καταργείς το private κτλ, ποια η διαφορά της από την C αναφορικά με τον περιορισμό στην πρόσβαση των attributes των οντοτήτων; Καμία. Το αυτόματο name mangling δηλαδή κάνει το ΟΟΡ; Το αυτόματο VTable ή Mapping κάνει το OOP;

 

Τι "κάνει" το OOP, από την στιγμή που έχουμε reflection;

[παπι]

απο αυτο που ποσταρες

The process of breaking a system into parts, each of which represents some class or object from the problem domain. The application of object-oriented design methods leads to an object-oriented decomposition, in which we view the world as a collection of objects that cooperate with one another to achieve some desired functionality

 

Ειναι απλα μια ιδεα

[Timonkaipumpa]

Παπί, εγώ συμφωνώ.

 

Για αυτό έγραψα πριν ότι η λέξη "υποστηρίζει" δεν είναι κατάλληλη για την περίπτωση της C και του ΟΟΡ. Γιατί από την μία δεν θα το έκανες αλλά από την άλλη μπορείς να το κάνεις.

 

Δηλαδή, δεν υποστηρίζει η C++ interface εφόσον δεν μπορείς να το κάνεις με έναν specifier;

[migf1]

Μα...

 

Εάν η απάντηση στην ερώτησή μου είναι όχι, τότε δεν είναι η C# OOΡ.

 

Εάν είναι ναι, τότε εφόσον η C# σου δίνει την δυνατότητα να καταργείς το private κτλ, ποια η διαφορά της από την C αναφορικά με τον περιορισμό στην πρόσβαση των attributes των οντοτήτων; Καμία. Το αυτόματο name mangling δηλαδή κάνει το ΟΟΡ; Το αυτόματο VTable ή Mapping κάνει το OOP;

 

Τι "κάνει" το OOP, από την στιγμή που έχουμε reflection;

 

Δεν υπάρχουν ακριβείς ντιρεκτίβες για το σύνολο των χαρακτηριστικών που ορίζουν το oop-paradigm. Γίνετια της Πόπης επί 10ετίες με αυτό το θέμα (κάθε major vendor βαφτίζει σχεδόν κατά το δοκούν ως oop νέα χαρακτηριστικά που προσθέτει σε νέες γλώσσες που φτιάχνει ή παλιές που βελτιώνει).

 

Για αυτό λοιπόν μιλάμε για μια μίνιμουμ βάση που περιγράφει το oop-paradigm, την οποία λίγο-πολύ την υποστηρίζουν όλοι ή σχεδόν όλοι, έστως και με ελαφρώς διαφορετικές προσεγγίσεις ή ονομασίες. Κι απο κει και πέρα ο καθένας βάζει από πάνω τα δικά του. Δηλαδή όλες οι OOP υποστηρίζουν εγγενώς και με συγκεκριμένα εργαλεία τουλάχιστον κλάσεις, αντικείμενα, μεθόδους & κληρονομικότητα, με λίγο-πολύ κοινή φιλοσοφία διαχείρισης. Στα υπόλοιπα κάνει ο καθένας ότι θέλει και συνήθως η αγορά είναι αυτή που καθορίζει ποια απορρίπτονται και ποια αποδέχονται.

 

Παρμπιπτόντως, αυτό είναι άσχετο με το τι σημαίνει "η τάδε γλώσσα υποστηρίζει το τάδε paradigm" ... αυτό δλδ δεν έχει να κάνει συγκεκριομένα με κάποιο paradigm, αλλά με το ότι όταν ακούει ένας που έχει έχει έστω κι ελάχιστη επαφή με το αντικείμενο πως "η τάδε γλώσσα υποστηρίζει το τάδε paradigm" καταλαβαίνει πβς η γλώσσα αυτή παρέχει αυτοματισμούς που διευκολύνουν αυτό το paradigm (και όχι π.χ. ότι είναι do-able, διαχωριστικές γραμμές, ή ότι άλλο ξέρω-γω γράφτηκε μέχρι τώρα στο νήμα).

 

ΥΓ. Δεν ξέρω C#

 

απο αυτο που ποσταρες

The process of breaking a system into parts, each of which represents some class or object from the problem domain. The application of object-oriented design methods leads to an object-oriented decomposition, in which we view the world as a collection of objects that cooperate with one another to achieve some desired functionality

 

Ειναι απλα μια ιδεα

 

????????

 

Αυτό είναι ο ακρογωνιαιος λίθος της έννοιας object-oriented-programming (είναι αυτό που σου έγραφα μερικά ποστς πιο πριν, ως βασικό χαρακτηριστικό του oop έναντι του procedural paradigm).

[Retromaniac]

Νομίζω ότι μπορώ να σας λύσω την διαφωνία χωρίς να επεκταθώ πολύ. Και νομίζω ότι έχετε δίκιο και οι 2 πλευρές.

Στην C μπορείς να κάνεις Object Oriented Programming και είναι ολοφάνερο ότι πληρή τα κριτήρια για αυτό. Είναι δηλαδή μια γλώσσα που μπορεί να υποστηρίξει προγραμματισμό με προσανατολισμό στα αντικείμενα.

 

Για αυτό έγραψα πριν ότι η λέξη "υποστηρίζει" δεν είναι κατάλληλη για την περίπτωση της C και του ΟΟΡ. Γιατί από την μία δεν θα το έκανες αλλά από την άλλη μπορείς να το κάνεις.

Ακριβώς, η λέξη κλειδί είναι μπορείς,

Υποστηρίζει θα συμφωνήσω είναι λάθος.

Μπορεί να υποστηρίξει (με αρκετό κόπο από την πλευρά του προγραμματιστή) είναι το σωστό,