Re: [GOOS] Do objects need to know the environment they are running on?

[Daniel Wellman]

Hello, Samuel!  

From what I've learned, an object should only know about itself and it's relation with its neighbors and not more. What I'm confused about is I think that an object should need to know a little about the running environment. For example, when implementing MVC pattern in controller, the controller should be stateless because it is recreated every time a request comes in, and we can run the computation in a single thread, because we don't need to worry about UI responsiveness like GUI applications. In GUI applications, we can save the states in the controller and we can't do the execution in a single thread because it could make the UI non responsive. These considerations could make great difference in my design, especially because of the threading problem.

In the Ports and Adapters / Hexagonal Architecture style, I'd say that those objects you described (Web library/framework controller and GUI application controller) were adapters - responsible for taking inputs from the technical user interface and translating them into messages to be sent to your domain.  Viewed that way, it makes a lot of sense to me to think about threading when implementing that layer - if not, the code might end up doing lots of heavy calculation in the UI thread and create a non-responsive experience for the user.

I don't know the specifics of your situation, so my answer will be general - and so I may miss your point entirely.  In general, I would try to keep the domain code as unaware of the context in which it's run (desktop GUI or web Controller) as possible.  In your example, I think that's the "model.getSomething()" part of the code.  If model.getSomething() needs to be implemented differently in a GUI or web environment, (such as by starting threads or not) then I'd wonder if that model object was also handling some sort of external environment manipulation as well.  If that was the case, I'd wonder if there were some more ports that could be defined in terms of the business domain, and then those technical parts moved into an adapter implementation.

If I didn't answer your question, then can you help me understand your situation a little better?  Why would the domain/model code change in different technical environments?  What is the domain of the application?

In the GOOS book, the section on "Extracting the User Interface" has some information about this, as does the chapter "Teasing Apart Main".  

Cheers,

Dan

 

When I'm writing a web MVC that is a single threaded environment, I could do it like this:

class Controller{

    public void doSomething(){

        //retrieving data with slow internet connection, patiently wait until the model finished

        int something = model.getSomething();

        view.renderSomething(something);

    }

}

But in GUI applications, I don't think I can do the same. If the model talks to the database or the network, it could disturb the UI thread because of the long running operation. I think the controller needs to know that the model will take a long time to do his job, so my solution would be the controller telling the model to fetch some data asynchronously, and then doing another job until the model notifies the controller when it's done.

So, should I take the execution environment into considerations when designing? Is it possible to design the objects so that they could run in any kind of environment? I don't think that domain objects could be reusable in different kinds of environment since the design could be completely different to suit environment needs.

--
 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Giorgio Sironi]

On Fri, May 3, 2013 at 7:59 PM, Samuel Edwin <esa...@gmail.com> wrote:

So, should I take the execution environment into considerations when designing? Is it possible to design the objects so that they could run in any kind of environment? I don't think that domain objects could be reusable in different kinds of environment since the design could be completely different to suit environment needs.

My 2 cents: I think you have to design a model that is capable of supporting the interaction dictated by the most complex of your UIs, in this case the asynchronous one; still the model would have no dependency on the particular implementations of the controllers.

The simpler UI can then still use the model asynchronously, even if it could do it in a single thread.

--
Giorgio Sironi (@giorgiosironi)

http://giorgiosironi.com

[Samuel Edwin]

Hi Daniel, thank you for your response.

I'm not an experienced developer, so maybe the answer I'm looking for is the knowledge of something that I'm lacking of.

When I'm writing an application using a new framework that isn't familiar for me, I want to focus on building the features first. I think that I'll understand the framework later, learning a part of the framework when I really need to. Do I have to really understand the framework first? From what I understand, the business logic and the flow of application can be made reusable so that when I'm migrating to another framework, I'll just have to adjust a few parts that related only to the framework.

What's bothering me from doing this is the characteristic of the framework that could make my business logic and application flow need a lot of rework. For example: let's say that I need to save the states of my objects, and framework A gives me that functionality. Now when I need to migrate to framework B, for some reasons, I can't save any object states. This will make me do a major rework in my business logic. 

Another example: framework A is single threaded, so I don't need to think about concurrency in my code, object X will patiently wait until object Y finished doing its long running operation, and X finally can make a decision based on the data retrieved by Y like the 'model.getSomething()' example above. But in framework B, the work that object Y does can only be done in another thread so that object X cannot wait for object Y. X can only hope to be called back when Y has done its job.

If that's the case, is it unavoidable to rewrite my controller from handling single threaded to multi threaded model?  The controller I made has no assumption about the environment it is running on. If it's really unavoidable, then I need to rewrite the flow of my application.

According to ports and adapters pattern, can my application layer be completely free of rewrites when I migrate to arbitrarily different environment? Let's say that my boss decided to change the system from using Swing GUI to Java EE web application.

I'm sorry if I can't make myself clear due to my lack of experience, I still have much to learn.

Thank you,

Samuel

Hello, Samuel!  

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[Samuel Edwin]

Hi Giorgio, thank you for your advice.

I don't know yet what level of complexity I'm facing right now, I hope that I can find a good solution that suits my needs.

[Stefano Zanella]

Daniel,
I think there's a major misunderstanding in your last considerations (but I'm not an experienced developer too, so I might be wrong - perhaps someone else will correct me).

The most important thing I learned since I approached TDD methodology in general, is that overthinking and overengineering your code is a useless practice (we might discuss how we  define something is overdone, but that's another story). In particular, the worry that you might one day need to swap a framework with something different can produce effects (in terms of productivity/positive feedback) that are not much better than not caring about that, for many reasons:

- following the "fear", you're going to introduce complexity in your system that you don't need ATM, that don't produce any business value and that could even be completely wrong (you aren't testing your app with different frameworks, are you?)

- even if this fear materializes in a near future, it should be possible for you to refactor your code so that it can at some point fit the new framework: I guess the time you would spend refactoring would be less than the time it could take to "follow the fear" upfront

Obviously, this doesn't mean you should write your code carelessly; that's why we do (or try to do) TDD. I think following the advices in GOOS could lead to code that can be "framework agnostic"; yet, I also think there's no proof about that, nor that it's the point of the ports and adapters pattern (note also that whatever the case, you'd need to rewrite your adapters anyway). I like to think more in term of protecting code from subtle changes in the supporting frameworks (like new features or API changes) and - more importantly - in terms of differences in the domain language, rather than complete independence between the domain logic and those frameworks.

Let me also say that what I'm stating here comes from being used to think the same way you expressed in your latest email; so I'm not talking about blind faith here, but rather about firm belief supported by experience.

Last, to recap and to try to actually answer your original question, I think that if you carefully follow the advices in GOOS without worrying about future (likely and unlikely) needs, you'll end up with code that will encapsulate running environment in the right objects, since it's almost the only way to maintain your domain code at the right level of abstraction. You can have a clear example of this if you look at the parts where all XMPP logic gets nicely bundled up to be hidden from auction sniping logic.

Again, please take my words "cum grano salis" and take your time to embrace the coding process; in my case, it took me three readings of the whole book and an actual application to develop to just start being able to figure out what I was doing. Don't be bogged down by this though, I think effort is more than repaid in terms of fun and mental sanity later.

Regards,

    Stefano

--

 
---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Samuel Edwin]

Thank you for your advice Stefano. I'm often stuck not doing anything, worrying that someday my code base will need so many adjustments due to the framework and changes of features. Perhaps the only way to clear my doubt is by doing and learning from my mistakes. I hope the efforts and confusions will pay off soon.

Regards,

Samuel

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[Stefano Zanella]

Ah, only God knows how often I (still) feel like that...yes, the mantra for me is to stop speculating and start doing (not always easy to accomplish, but at least I know I HAVE to do that). At least, when you're unsure if you're going in the right direction, making a little step further can help deciding if a trajectory adjustment is needed. Also, more often than not, even if my assumptions were wrong, I surprisingly discover that:

- the effort for changing direction is not that big, given that

- having actual code that I can read and modify makes the overall picture clearer, pitfalls end errors included

I hope you can get over that fear soon; satisfaction will be huge. If you're in need, don't hesitate to ask :)

Sincerely,

    Stefano

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

[Samuel Edwin]

That's a big relief for me, I feel encouraged to make more mistakes, thank you again Stefano :)

[Rick Mugridge]

That's where modularity and minimal dependencies is key. I find that a change to the "architecture" or a framework will change the way the pieces are wired together, but most of the code is unaffected.

Cheers, Rick

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.