Small classes…

[clean_coder_student]

Hi,

‘keep classes small’ is the idea, how do you break down big classes?

I have a big class  with a rather large cohesion, I could break it down in a few smaller classes but they would still need each other often.

So I could either add the smaller classes inside one main (small) class or I could setup some kind of tracking of which object refers to which other object (which is an administrative nightmare)

Or alternatively you could think of a wrapper class (for 3th party hardware, or DB, etc). Sure you can only wrap the functionality you like or you could perhaps break it down in a  few smaller classes based on functionality but in the end… do you have classes inside classes or do your main objects have the various classes as their children and do you keep track on what is where elsewhere (hope you get my drift…)

Wondering how you do this/feedback…

[Dave Schinkel]

sign up for safariflow.com and read this http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

[Vlad GURDIGA]

It’s hard to give a specific advice without seeing the code at hand, but one nice tactic I’ve heard people use to find out the smaller classes that “hide” inside a large one is to try to describe what that class does, and if you find yourself using “and” or “or” in the description, those often happen to be separators of different responsibilities, and so, good candidates to extract as separate classes. :)

[clean_coder_student]

Hi Guys,

Thank for the book tip Dave, i ordered it (the old fashioned way).

I don’t really have a hard time to extract smaller classes from bigger ones, but I wonder what the best way would be (after you extract them) to have them work together.

Since some classes/data simply have a strong coupling (which was the reason it was in 1 big class to start with).

 

You may end up with one class owning multiple smaller classes which is more or less the same, or you may end up splitting the (highly coupled data) in  multiple classes but then you have to keep track on which data belongs to what…

 

Think of the example of a piece of hardware.

Or think of a simple control like the windows button or listbox, etc, both are not exactly small classes, if you look at the properties alone…

So how would you break down a standard (MS) button class in smaller classes???

 

Regards.

[James Green]

Sounds like you need to identify individual use-cases for the class. I presume that class is used by multiple other parts of the application or is itself using a lot of other classes?

Rather than look at the class as a big ball of mud, try to identify individual types within it that are analogous to the real world your application is mimicking. Those types may form an inheritance hierarchy or may not. The individual types can then be controlled by use-cases.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Łukasz Duda]

Lately I've split every user interface control in my library in 3 classes: model, behavior and renderer.
And I like it :-P

[clean_coder_student]

>I presume that class is used by multiple other parts of the application or is itself using a lot of other classes?

both.
if i split my big class in smaller ones it will be using a lot of other classes.
and yes its being used by a lot of other classes.


Op dinsdag 10 juni 2014 16:31:35 UTC+2 schreef James Green:

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[James Green]

Is this big class and it's client covered by tests?

If so, go ahead and split things up by parting the tests up first into more focused editions.

If not, add focused tests in start extracting the bits being tests slowly.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[clean_coder_student]

@Łukasz Duda:

>Lately I've split every user interface control in my library in 3 classes: model, behavior and renderer.

I can see that work but that would meen that you have to do more adminstation  (your gui object needs to know your model object and behaviour object etc..)
especially if you have multilpe of each (100 or so), this can get messy (at least with my code ;-)

[clean_coder_student]

@James Green:

>If not, add focused tests in start extracting the bits being tests slowly.

thanks, but no tests yet, but will add like you said.

ok so bottom line, is you are saying (correct me if i'm wrong), put that big fat mama (the big class) on a diet (hmm, force a child birth) and this new skinny mama will have (own) multiple smaller child classes, correct? ;-)

other (related) toppic but what are your thougts on Ian Coopers presentation? (see here http://vimeo.com/68375232 ) basically in this case you wouldn't have to change your tests (if i had any to start with) since the 'skinny mama' would still have the same interface, so that would make sense...

[James Green]

I think the interfaces are absolutely critical to any refactoring.

There are vast numbers of developers on StackOverflow who are asking how to test non-visible class members. What they haven't "got" mentally yet is that the tests are intended to exercise the behaviour of the class as described by it's interface (or public methods) not it's implementation.

If I write a test for a calculator, I really don't care if the Calculator's subtract(double amount) method actually goes off to some web service or database or does some mathematics internally. The test uses subtract and expects the object to hold the result.

Think of the clients of your big class and separate them into roles. Each role is akin to a use case. The use case needs to see the objects and methods it requires, no more. That's how to minimise coupling a huge amount.

I built a cryptography class that acted on multiple types, input (encrypt) and output (decrypt). As I tested it become clear I actually wanted cryptography interfaces that were specific to those types, and from there I was able to separate the implementation class into multiple ones without disrupting the rest of the application, because of the use-case focused interfaces.

If you extract to interfaces as a first pass you should find dependency injection as a valuable tool to proceed with. Tests will automatically follow too.

[clean_coder_student]

@James Green:
thanks.
i have only looked into TDD/clean code for some months now and although i like it, it was nice to run into that presentation of Ian who addressed the issues i had been walking around with.
Good to hear that you share the same philosophy.

I'll start splitting the big mama and move from there...
regards

[Łukasz Duda]

The controls are put together inside control factory (for example field factory) which is then used by http://knockoutjs.com custom binding (MVVM).
View model knows nothing about renderer and behavior. Here you have the example of view:
<div data-bind="field: { type: 'lookup', valuePropertyName:'id', label: 'Contact', value: selectedContact, showLink: true, onLinkClick: showContactDetails, lookUpName: 'Contact', readonly: contactReadonly }"></div>

Greetings

[Jakob Holderbaum]

Hey Student!

I would start with smaller inner classes first. You don't break any
outer interfaces and you could even testdrive some of these inner
components.

Probably, the cohesion is just so strong, because of the large amount of
dependencies through the many consumers? By splitting it up, you could
identify consumers, that rely on one of your new smaller components
instead of the big old one.

By replacing the references one by one, you will decouple the big class
from the its exterior.

I could imagine, that the cohesion will be less strong after resolving
these dependencies. What do you think?

Cheers
Jakob

--
Jakob Holderbaum, B.Sc
- Systems Engineer -
phon 0176 637 297 71
mail h...@jakob.io
page http://jakob.io

[Terence McGhee]

Yo @Student (nice name... lol)

So to goal is to achieve and master the SRP (single responsibility principle). We're not really after small classes just for the sake of being able to say we have small classes. Rather, what we're really after is to ensure that our classes have a single responsibility.

If your big class serves one actor and one actor alone, then it might make sense in your case for that class to be that big. 

In my experience, I don't recall ever seeing a class that follows the SRP ending up being so big, but I guess it is technically possible.

Without seeing the code, it'd be tough to address the specifics of your particular scenario, but the rule you want to use for guidance is the SRP.

Btw, most everyone on stack exchange has a fundamental misunderstanding of the SRP. They think it literally means "has a single responsibility" or "does one thing" and neither of those phrases are specific enough to explain it. The SRP means that a class (or module) only has one reason to change. Check out episode 9 for a more thorough explanation.

On Monday, June 9, 2014 10:01:39 AM UTC-5, clean_coder_student wrote:

[Tristan Mills]

That's exactly what I've been doing for the last couple of days.
Making inner classes to group closely related code together and then promoting them to top level classes.

Coupled with aggressively extracting methods I've cleaned up the code a lot and found one major bug.

And this is new code to replace the legacy code... I wish the rest of my team did TDD and cared about clean code...  But that's another story...

Tristan

--
The only way to go fast is to go well.
--- You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
To post to this group, send email to clean-code-discussion@googlegroups.com.