Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Modules design pattern: abstraction vs incarnation (providing not so static data)

by haj (Curate)
on Nov 20, 2020 at 14:19 UTC ( #11123899=note: print w/replies, xml ) Need Help??


in reply to Modules design pattern: abstraction vs incarnation (providing not so static data)

I find it rather difficult to advise on this article and would suggest a different approach: Step back and describe the problem you're actually trying to solve. You seem to be stuck in "solution space", with some design decisions already made - but these might actually get in the way.

As an example, you write modules are intended as an abstraction of behaviours and scripts are generally the incarnation of these behaviours in the real life. I'd challenge that view and say that objects are the incarnations, and that you are (ab)using subclasses instead of different objects of the same class, each with their own attributes. Also, you seem to use scripts to store particular objects. All this might be justifiable, but I can't see how.

Also, the decision to be a fan of OO frameworks only when I will have the need to use all the features they provide seems questionable. You might fare better if you decide to embrace them as soon as they help to solve your problem. I am pretty sure that almost no one needs to use all the features of Perl itself, yet many of us are Perl fans, and quite happy with it.

So, perhaps the problem has occurred before. I don't recognize it. Chances are that some features of OO Perl frameworks have been created to solve your problem. Can you describe how you intend this to be used? Are users supposed to write their own modules, and how should they feed them to the system? Can you describe the problem without using the words "incarnation", "abstraction" and "design pattern"?

  • Comment on Re: Modules design pattern: abstraction vs incarnation (providing not so static data)

Replies are listed 'Best First'.
Re^2: Modules design pattern: abstraction vs incarnation (providing not so static data)
by Discipulus (Abbot) on Nov 20, 2020 at 16:04 UTC
    hello haj and thanks for looking at my long post,

    did you also followed links I provided? Forget for the moment my Game::Term project and focus on the Perl::Teacher one.

    In Perl Automateaching -- part 1: brainstorming I presented the idea and I asked for suggestions on the implementation (how to judge perl documents) while in automateaching -- part 2: proof of concept I sketched out some viable approach to accomplish my task.

    In my mind Perl::Teacher and all its classes are the teaching framework and must be written by me. This is what I named abstraction in this post.

    No one line of code has stil been wrote for the Perl::Teacher module, so I have really took no techincal decisions at the moment, only the decision to process perl documents using PPI (ie: no code given into STDIN).

    By other hand all lessons contained in courses can be written as separated modules by anyone. This is what I named incarnation in this post. So in the future peraphs haj will publish on CPAN Perl::Teacher::Course::EN::PerlIntro and this will contain Perl::Teacher::Course::EN::PerlIntro::01_safetynet and Perl::Teacher::Course::EN::PerlIntro::02_strictures and so on.

    I hope the above satisfies your Are users supposed to write their own modules? question.

    I presented my doubts about how to design this Perl::Teacher class and its interface in Module design for loadable external modules containing data and shown a brief example in Re^2: Module design for loadable external modules containing data

    That said you are right to challange my point of view, and you are right when saying that objects are the incarnations all correct but does not change the point, or at list my point of view.

    > Also, you seem to use scripts to store particular objects.

    Here I dont follow you: where this sentence comes from? If from my post I must have wrote something in the very wrong way.

    About OO frameworks:

    > You might fare better if you decide to embrace them as soon as they help to solve your problem. I am pretty sure that almost no one needs to use all the features of Perl itself, yet many of us are Perl fans, and quite happy with it.

    Well.. you turned the example in a nice way :) and yes, erase the all word from my sentence and will be the same of your. I will embrace them with happines when they help me in some way. Read above posts: I dont see any gain using roles.

    I hope the above clarify your doubts, hoping now you can clarify mines :)

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      I had a glance at the other articles when they appeared and re-read them before answering. First of all it is a bit of a misnomer: Your goal is not to actually teach: you want to present exercises and evaluate responses. Teaching needs a storyline, a concept of independent modules doesn't help with that.

      Your second article contains 460 lines of code but not a single line of POD - sorry, I didn't spend time to walk through that. It doesn't give the impression of No one line of code has stil been wrote.

      I almost suspected that you aren't aware of the technical decisions you already made. I don't mind PPI - that's what I'd call an "internal affair". But there are others:

      • You define courses and lessons as Perl modules. This is weird. Both courses and lessons are mostly data, in particular text, and not code. I don't believe that Perl modules are the best format to write lessons and exercises.
      • You have each course to be a separate class, inheriting from your base class. Why? Why not different objects of a class you're providing?
        For this particular decision, I might be able to hallucinate the problem which you actually want to solve: You want authors of courses and lessons to be able to distribute their work. I don't know whether that is what brought you to the idea to use modules and CPAN, but CPAN would allow to "install" different courses by their name, therefore offering some method for distribution. As far as I'm concerned, I'm out: I don't have a CPAN account.
      • You claim that you don't need to separate logic from presentation because you have mainly Perl data. Well, that's a direct consequence of the previous decision, isn't it? You surely know that web applications usually mix static data (templates) with database data, XML documents, and other dynamic data. The value comes with these dynamic data, not unlike to your situation.
      • You dislike the idea to have external, yaml or json, files containing the data to be served. That's a decision against technical solutions, but with a rather lame reasoning. It isn't you who writes the courses, right? Do you have enough authors who share your preferences?

      So, how did I guess that you use scripts to store objects? You wrote: I have designed it to have incarnations (game scenarios in this case) as standalone scripts and this approach lead me to shell out when changing the current scenario. If you can't get a scenario's attributes without running a script, then I guessed the script stores this scenario's data. This may be wrong, or at least irrelevant.

      And finally, about OO frameworks: I didn't mention roles, and I didn't even have them in mind. All problems can be solved just fine without roles, but roles can bring elegance by avoiding boilerplate code. But Perl's OO frameworks have a lot more to offer. The issue is that there are too many of them :)

        "But Perl's OO frameworks have a lot more to offer. The issue is that there are too many of them :)"

        There are only three, and they play pretty nicely together.

        • Moose
        • Moo
        • Class::Tiny

        The others do not exist. Or we can pretend they don't anyway.

      A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11123899]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2021-01-21 08:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?