![]() ![]() State is a very important concept in object oriented design and analysis. There’s an implicit learning learning curve here but the benefits are clear: a rich set of tools, patterns, abstractions, features, developed from the ground up from language and software engineering perspectives, that adds to what’s already available from the chosen Prolog compiler. Libraries, such as the optionals and expecteds implementations, can also enable interesting solutions to tricky problems. For example, parametric objects and event-driven programming enable clean, declarative solutions for a surprising number of problems. When you get closer to the language level, there are some Logtalk features that enable creative solutions that are outside the radar of traditional Prolog programming. Related, note that most native Prolog resources (notably, libraries) can be used as-is from Logtalk. some data in plain Prolog, in RDF format, or even in an external database is sometimes the sensible choice. One thing to keep in mind is that, just because you’re using Logtalk objects (same goes with Prolog modules) doesn’t mean that everything must an object (or a module). The two models, relational and object, can coexist nicely, specially in those cases where the relational model takes care of knowledge representation and the object model takes care of organizing the predicates that reason about the represented knowledge. Being aware of that, from a sufficiently abstract level, traditional OO design methods are useful and can be applied. The trap to avoid is start thinking in terms of imperative OOP with dynamic objects and mutable state taking central stage. As you mentioned earlier, the object model brings structure based on declarative OOP concepts. The object model allows a much richer set of design patterns when compared with what’s sensible with Prolog modules (notably, without half-broken hacks). From a relational perspective, all the good advice from more traditional Prolog programming applies, specially about finding the best representations. There are two starting points: the relational model and the object model. ![]() So, when you solve problems with Logtalk - how do you go about it – what is the analysis / design method at work …ĭoes it correspond to typically OO analysis methods or does it require adopting a different thinking paradigm as well. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |